О публикации и речи нет, ни в статье, ни в моем предположении. Допустим, фото попало в общий доступ третьим путем (украдено?) и при наличии копирайта (или авторского права, не силен в терминах?) реально добиться его удаления. Если прав нет — наблюдай и плачь в тряпочку.
О Литресе мы друг-друга не поняли. Книги принадлежат автору и его наследникам, и сейчас их продажа без отчислений не законна и есть шанс, что их прищучат, но когда они попадут в public domain, то продавать будут точно так же, ничего не нарушая. Т.е. некоторые личности будут тупо обогащаться за счет других, как и писали чуть выше — приторговывая ценностями из public domain.
Это напоминает ситуацию, когда в домах раззорившихся аристократов делают музеи, но разрешают им там жить, мирясь с посетителями и вообще выставлением своей жизни и истории на показ. Никому не пожелал бы такой судьбы.
Неужели сейчас нет градации ценностей и сроков? Например, если речь об изобретении вечной свечи ДВС или таки лекарства, то срок копирайта это разумное время, когда технология приносит доход автору, а потом идет в Public Domain и улучшает мир.
Но если мой прадед сделал ню фото моей прабабки, наврядли я буду счастлив, что через N лет она станет достоянием общественности, ее будут печатать в журналах и оформлять ей обложки порно-сайтов. Или, например, Litres получит право продавать тексты Берроуза и обогащаться на них?
Эксперимент с jsfiddle показателен и интересен, но меня (как и владельца баннерки) больше волнует практическая часть: почему в Chrome, Safari и в IE 10, да и в других браузерах и WebView, отображается как надо? И, в конце-концов, как сделать универсально без скрипта?
Окей, зайдем с другой стороны.
Я далеко не эксперт в HTML, потому мог допустить ошибку при уменьшении большой проблемы до малой.
Итого, есть страница с фул-скрин изображением. Она отображается отлично в любом браузере, в т.ч. оттестировано в WebView на iOS 5-6, Android 2.2. В W8 основной div с картинкой «схлопывается».
Вот код: paste2.org/p/3359007
Решить получается только скриптом, который при загрузке делает document.getElementById('placeholder').style.height = window.innerHeight + 'px';
Буду благодарен помощи или подсказке, что я (вернее, стороняя фулл-скрин баннерная система, существующая уже лет 5) делаю не так.
Рекоммендация #0: используйте любой, подходящий вам и команде стиль, но в рамках одного проекта других стилей быть не должно и придерживаться его надо обязательно.
Посмотрите пример по ссылке, высота задана у div. В моем случае код чуть сложнее и высота в 100% задана еще у body, но все-равно он работает отлично в любом браузере, в т.ч. и IE, но не в WebView в W8.
Не знаю, как на WP8, но на W8 есть проблемы, которые никто не фиксит и не собирается фиксить. Например, в WebView не работает height:100% для div и iframe, «схлопываются» как с 0% вокруг контента. Причем, зарепортили еще в сентябре.
> для винды, насколько я знаю, рекомендуют все же устанавливать ограничения на размер свопа.
начнем с того, что для винды рекомендуют его не отключать никогда и оставлять System managed size.
> А виртуальная адресация — это тоже «из контекста»? Или вот это:
Виртуальная адресация это сложнейший механизм, который в любом случае выигрывает, когда для каждой страницы из 4гб выделенной памяти не надо хранить отдельный адрес 4096-байтной страницы. Простой подсчет говорит, что при максимальной фрагментации таблица преобразования (Page address table по Таннербауму) будет иметь миллион элементов.
Непрерывная область памяти повышает быстродействие в одном случае: если в целях увеличения скорости кэш-памяти процессора Memory Manager использует механизм page coloring для назначения страниц, выделяемых процессам из списков свободных или обнуленных страниц.
Тоже «из контекста» и не о том?
Конечно, ведь именно это предложение говорит о том, что Memory Manager ОС как раз имеет возможность получать бенефит от последовательного расположения страниц, пусть и польза этого не сказочно велика. А «из контекста» как раз потому, что за этим следует предложение с пропущенным вами основным выводом:
Однако негативные последствия удаления из памяти ценных программ и данных значительно перевешивают выигрыш, который можно извлечь из непрерывного пространства физической памяти.
Еще раз повторю, в этой статье Марк рассказывает, почему нельзя позволять другим программам вмешиваться в работу менеджера памяти.
> И тем не менее. Не «сколько попросит», а сколько есть
если Windows и стоит авто режим, то будет выделять столько, насколько хватит винчестера.
> Автора подсказать, или сами найдете?
вырвано из контекста, где Марк объяснял, почему нельзя доверять подобную задачу сторонней программе, оставляя это ОС, одним из инструментов которой является, как ни странно, пейджинг.
на этом, наверное, закончим, а то так можно и дойти до советов отключения свопа на серверах, дабы там один процесс с утечкой не мог рости до позеленения, а крашился :)
p.s. такой совет действительно существует и в описанной сферически-вакуумной ситуации помогает.
Запросить-то она запросит, но дадут ей не более, чем объем виртуальной памяти, которая ограничивается ram+swap
Именно для этого в Windows есть пункт «System managed page file size». В других ОС выделяют 1.5-2x RAM под swap раздел, иногда и больше.
При скорости работы RAM любая дефрагментация будет влиять на работу очень и очень мало. Гораздо быстрее, чем сбрасывание в своп и обратно.
Речь не о том, что сбрасывание в своп медленее, это и так ясно. Речь о том, что есть механизм, придуманный для решения многих проблем (в т.ч. и фрагментации) и с ним система работает быстрее, чем без него.
Для примера, ознакомьтесь с отличной статьей тов. amirul: habrahabr.ru/post/107607/
В целом — не убедили
Я бы удивился, если бы было так. Всего лишь озвучивал свое мнение, основанное на общедоступных исследованиях и документациях.
В современных ОС виртуальная память позволяет запрашивать для нужд программы буквально любой объем, не задумываясь, обеспечен он физической RAM или как-либо еще. Я опущу разницу между commited и reserved памятью, об этом читайте статьи. Часто бывает, что объем используемой commited виртуальной памяти запущенных программ превышает объем ОЗУ в разы. Для примера, вот скрин top на Mac OS X:
картинка
Такая память backed by swap, т.е. гарантированно, что программа получит нужный объем физической памяти, когда ей это будет надо. При отсутствии swap/paging, программам запрашиваемый объем просто не будет выдаваться и резервироваться. Рано или поздно начнутся ошибки и краши:
Или даже так:
картинка
Конечно, если переделать Windows в однозадачную среду (запускать без Explorer или выполнять одну программу одновременно, н-р. только одна игра), то можно самому отлично выполнять работу менеджера памяти и следить за ее потреблением. :) Например, в Windows Embedded paging file по-умолчанию выключен, правда, это инструмент и не для обычного пользователя. Такой режим работы называется Monoprogramming (в противоположеность Multiprogramming = многозадачности).
В Linux, кроме всего прочего, swap раздел используется swsusp для hibernate.
Если хочется детальнее, то ищем
A. Tanenbaum, Modern Operating Systems 3 e, 0-13-6006639
Но на самом деле, есть еще одна сторона медали, о которой не задумываются апологеты отключения свопа. При частом использовании десятками программ (а в многозадачных ОС происходит именно так), физическая память становится все больше похожа на решето — сотня страниц принадлежит одной программе, сотня другой, потом свободный блок и так далее. В масштабах программы это лишь проблема программы, в масштабах системы это приводит к потерям производительности. При высокой фрагментации памяти, менеджер может попробовать решить эту проблему:
Once free physical memory becomes fragmented, an operating system can consolidate free memory into a single, unfragmented block by moving code and data to new physical addresses (Figure 2). In this case, the three blocks of free memory were consolidated into one larger block by moving system memory upward and application 1 downward in physical memory.
В зависимости от ситуации, память становится либо все более фрагментированной, либо происходит постоянная ее дефрагментация, что тоже и не дешево. Как раз в этой задаче на помощь приходит свопинг — сбрасывание памяти фоновых программ в своп:
When not needed by the processor, code and data can be saved temporarily on a hard disk (or other device with abundant storage). This frees physical memory for use by other code and data that the processor needs to access. The process of temporarily transferring code and data to and from the hard disk to make room in physical memory is called swapping.
За счет свопинга происходит реорганизация памяти и не используемые, но запущенные приложения не занимают физическую ОЗУ. Это позволяет бороться с фрагментацией и абстрактно можно сказать, что если компьютер некоторое время не использовать, то физическая память будет полностью дефрагментирована. На деле это не всегда так, но без использования свопа сходный уровень дефрагментации памяти достигается только выключением :)
Опережая стандартный ответ «все это фигня, у меня 16гб памяти без свопа и ничего не тормозит» я скажу, что ремни безопасности тоже нужны один раз из тысячи поездок, но пренебрегать ими как минимум глупо.
О Литресе мы друг-друга не поняли. Книги принадлежат автору и его наследникам, и сейчас их продажа без отчислений не законна и есть шанс, что их прищучат, но когда они попадут в public domain, то продавать будут точно так же, ничего не нарушая. Т.е. некоторые личности будут тупо обогащаться за счет других, как и писали чуть выше — приторговывая ценностями из public domain.
Это напоминает ситуацию, когда в домах раззорившихся аристократов делают музеи, но разрешают им там жить, мирясь с посетителями и вообще выставлением своей жизни и истории на показ. Никому не пожелал бы такой судьбы.
Но если мой прадед сделал ню фото моей прабабки, наврядли я буду счастлив, что через N лет она станет достоянием общественности, ее будут печатать в журналах и оформлять ей обложки порно-сайтов. Или, например, Litres получит право продавать тексты Берроуза и обогащаться на них?
Я далеко не эксперт в HTML, потому мог допустить ошибку при уменьшении большой проблемы до малой.
Итого, есть страница с фул-скрин изображением. Она отображается отлично в любом браузере, в т.ч. оттестировано в WebView на iOS 5-6, Android 2.2. В W8 основной div с картинкой «схлопывается».
Вот код:
paste2.org/p/3359007
Решить получается только скриптом, который при загрузке делает
document.getElementById('placeholder').style.height = window.innerHeight + 'px';
Буду благодарен помощи или подсказке, что я (вернее, стороняя фулл-скрин баннерная система, существующая уже лет 5) делаю не так.
NT 3.1 — 3.1
NT 3.5 — 3.5
NT 4.0 — 4.0
2000 — 5.0
XP — 5.1
Vista/2008 Server — 6.0
7/2008 Server R2 — 6.1
8/2012 Server — 6.2
9-Blue? — 6.3
Логично предположить, что таки 6.3 будет новым витком, а не сервис-паком, а значит изменения есть и мы просто их не видим.
Но я соглашусь, что
P.S. Всмотрелся в скрины, увидел NT 6.3, вот это уже как раз говорит об изменении ОС, а не просто GUI.
т.е. на деле, нужен был повод провести масштабный рефакторинг, а что может быть масштабнее перехода на другой язык? =)
P.S. Чтобы создатьтопик в 11:11 сидели с часами? =)
и, кстати, такая операция уже во второй раз!
начнем с того, что для винды рекомендуют его не отключать никогда и оставлять System managed size.
> А виртуальная адресация — это тоже «из контекста»? Или вот это:
Виртуальная адресация это сложнейший механизм, который в любом случае выигрывает, когда для каждой страницы из 4гб выделенной памяти не надо хранить отдельный адрес 4096-байтной страницы. Простой подсчет говорит, что при максимальной фрагментации таблица преобразования (Page address table по Таннербауму) будет иметь миллион элементов.
Конечно, ведь именно это предложение говорит о том, что Memory Manager ОС как раз имеет возможность получать бенефит от последовательного расположения страниц, пусть и польза этого не сказочно велика. А «из контекста» как раз потому, что за этим следует предложение с пропущенным вами основным выводом:
Еще раз повторю, в этой статье Марк рассказывает, почему нельзя позволять другим программам вмешиваться в работу менеджера памяти.
если Windows и стоит авто режим, то будет выделять столько, насколько хватит винчестера.
> Автора подсказать, или сами найдете?
вырвано из контекста, где Марк объяснял, почему нельзя доверять подобную задачу сторонней программе, оставляя это ОС, одним из инструментов которой является, как ни странно, пейджинг.
на этом, наверное, закончим, а то так можно и дойти до советов отключения свопа на серверах, дабы там один процесс с утечкой не мог рости до позеленения, а крашился :)
p.s. такой совет действительно существует и в описанной сферически-вакуумной ситуации помогает.
Именно для этого в Windows есть пункт «System managed page file size». В других ОС выделяют 1.5-2x RAM под swap раздел, иногда и больше.
Речь не о том, что сбрасывание в своп медленее, это и так ясно. Речь о том, что есть механизм, придуманный для решения многих проблем (в т.ч. и фрагментации) и с ним система работает быстрее, чем без него.
Для примера, ознакомьтесь с отличной статьей тов. amirul: habrahabr.ru/post/107607/
Я бы удивился, если бы было так. Всего лишь озвучивал свое мнение, основанное на общедоступных исследованиях и документациях.
В современных ОС виртуальная память позволяет запрашивать для нужд программы буквально любой объем, не задумываясь, обеспечен он физической RAM или как-либо еще. Я опущу разницу между commited и reserved памятью, об этом читайте статьи. Часто бывает, что объем используемой commited виртуальной памяти запущенных программ превышает объем ОЗУ в разы. Для примера, вот скрин top на Mac OS X:
Такая память backed by swap, т.е. гарантированно, что программа получит нужный объем физической памяти, когда ей это будет надо. При отсутствии swap/paging, программам запрашиваемый объем просто не будет выдаваться и резервироваться. Рано или поздно начнутся ошибки и краши:
Или даже так:
Конечно, если переделать Windows в однозадачную среду (запускать без Explorer или выполнять одну программу одновременно, н-р. только одна игра), то можно самому отлично выполнять работу менеджера памяти и следить за ее потреблением. :) Например, в Windows Embedded paging file по-умолчанию выключен, правда, это инструмент и не для обычного пользователя. Такой режим работы называется Monoprogramming (в противоположеность Multiprogramming = многозадачности).
В Linux, кроме всего прочего, swap раздел используется swsusp для hibernate.
Хорошо виртуальная память описана в статье Марка Руссиновича:
blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
Если хочется детальнее, то ищем
A. Tanenbaum, Modern Operating Systems 3 e, 0-13-6006639
Но на самом деле, есть еще одна сторона медали, о которой не задумываются апологеты отключения свопа. При частом использовании десятками программ (а в многозадачных ОС происходит именно так), физическая память становится все больше похожа на решето — сотня страниц принадлежит одной программе, сотня другой, потом свободный блок и так далее. В масштабах программы это лишь проблема программы, в масштабах системы это приводит к потерям производительности. При высокой фрагментации памяти, менеджер может попробовать решить эту проблему:
В зависимости от ситуации, память становится либо все более фрагментированной, либо происходит постоянная ее дефрагментация, что тоже и не дешево. Как раз в этой задаче на помощь приходит свопинг — сбрасывание памяти фоновых программ в своп:
За счет свопинга происходит реорганизация памяти и не используемые, но запущенные приложения не занимают физическую ОЗУ. Это позволяет бороться с фрагментацией и абстрактно можно сказать, что если компьютер некоторое время не использовать, то физическая память будет полностью дефрагментирована. На деле это не всегда так, но без использования свопа сходный уровень дефрагментации памяти достигается только выключением :)
Опережая стандартный ответ «все это фигня, у меня 16гб памяти без свопа и ничего не тормозит» я скажу, что ремни безопасности тоже нужны один раз из тысячи поездок, но пренебрегать ими как минимум глупо.
(последние две цитаты из technet.microsoft.com/en-us/library/cc767886.aspx)