Можно поставить принудительный запуск с правами администратора. Свойства ярлыка > Совместимость > Выполнять эту программу от имени администратора. Еще загляните в «параметры для всех пользователей», там в том же окне есть. Должно помочь, думаю.
В семерке UAC есть (более гибкий даже чем в Висте), действует почти также как и использование «ущербного» юзера. Как раз в таких случаях он и должен спрашивать права на выполнение программы. Так что если не разрешать всем подряд доступ ко всем что только есть, то проблем не должно возникнуть.
Я знаю то, что любой удаленный файл — лишняя трата времени на его восстановление, даже в том случае если он был «не из важных» (как ты написал). И даже если эта команда будет запрещена, то существует бесконечный набор других команд, которые навредить могут еще и похуже.
Просто я хотел сказать, что дело не в операционной системе, а в том, кто её использует. Элементарные меры безопасности, такие как работа в пользователе с пониженными правами, антивирь и недоверие к файлом из ненадежных источников — избавляет от подобных казусов в 99% случаях.
Если также из под рута (или админа) открывать все файлы подряд, то не спасет ни одна ось. Помнится очень популярная темка на ЛОРе, где казалось бы безобидная строчка на перле выполняет команду «rm -rf /». Против такого уж вряд ли выстоит любая *nix
Еще посмотрите eZ Publish — довольна неплохая CMS для таких целей. Удовлетворяет как раз все эти пункты. Поначалу покажется тормозной, возможно, но при грамотной настройке кэширования — летает шустро. Есть конечно минусы некоторые, но они в любой CMS есть…
Самый правильный подход, который не допустит подобных дыр в системе фильтрации, это оставлять только то, что явно разрешено, а всё остальное вырезать подчистую.
Я и не говорю что нужно плевать и писать кривой код :) Я ни в коем случае не оправдываю нарушения структуры языка, его синтаксиса. Просто в данном случае, когда нужно всего лишь расширить язык можно и не обращать внимания на гневные сообщения валидатора. Вот и всё.
Речь как раз и идет о тегах и атрибутах, которые никто кроме моего кода (кода Яндекса/кода автора статьи) не поддерживает. Ну невалидный он, этот код, ну черт с ним. Свет ведь не сошелся клином на этом валидаторе.
К тому же я уже предлагал выше легитимный способ расширения стандарта XHTML. Это стандартом самого языка XHTML предусмотрено. И любой XML-валидатор должен отпарсить этот код без ошибок.
Кстати, погоню за супервалидным кодом, всегда считал каким-то комплексом у веб-разработчиков :) По-моему, проще писать правильный код, но не обязательно 100% валидный. Даже Яндекс, к примеру, не стесняется такого «некошерного» тега, как
Если не ошибаюсь, если принтер поддерживает Postscript, то он сам всё вычисляет исходя из dpi. Но в целом да, именно от софта (или драйверов) зависит как будет использоваться значение dpi и масштабироваться изображение.
50x50 пикселей (при 50 dpi) на печати даст ровно дюйм
1000x1000 пикселей (при 1000 dpi) на печати даст ровно дюйм
500x500 пикселей (при 1000 dpi) на печати даст полдюйма.
К тому же я уже предлагал выше легитимный способ расширения стандарта XHTML. Это стандартом самого языка XHTML предусмотрено. И любой XML-валидатор должен отпарсить этот код без ошибок.
Ох, нападут сейчас на меня…
Ведь вроде бы XHTML задумывался именно как eXtensible.
Вот так должно быть:
50x50 пикселей (при 50 dpi) на печати даст ровно дюйм
1000x1000 пикселей (при 1000 dpi) на печати даст ровно дюйм
500x500 пикселей (при 1000 dpi) на печати даст полдюйма.
Улавливаете связь?