Windows дома
Да ну любому сигме понятно, что ты не должен этого хотеть.
Да ну любому сигме понятно, что ты не должен этого хотеть.Нужно больше смехуечек о том, кто чего хотеть не должен
Я думаю надо просто поотрывать руки тем кто сделал такой релиз. Хер с ним с превышением возможностей ФС, такие названия тупо не лезут ни в один видеопроигрыватель и чо там за номер серии приходится гадать.
А ты уверен, что не путаешь длину имени файла с длиной полного пути?
и чо там за номер серии приходится гадатьда ладно? по мне всё замечательно видно
по мне всё замечательно видноИ сами видюшки ты тоже смотришь в консольном плеере, сконвертированными в псевдографику.
Нужно больше смехуечек о том, кто чего хотеть не долженКак можешь видетьвыше - никсы отлично файл показывают прямо с подключенной NTFS системы. И да, проблема тут не в слишком длинном имени файла.
Этому "релизу" не хватает тега "fuck.the.rules..no.fuck.you_plz.leave.scene".
не опасаешься взятия за жопу за пользование торрентами?
сконвертированными в псевдографику.зачем конвертить? он и сам умеет. Юзай -vo matrixview
2015 год блин, нтфс блин, 64-битная винда блин - попробовал кино посмотретьНе используй для этого explorer )
Хотя video-player скорее всего тоже длинные имена не держит ))
И да, проблема тут не в слишком длинном имени файла.Проблема в длинном пути - оно больше 255 символов. NTFS и WinApi умеют больше (до 32к), но большинство прикладных программ (включая explorer) ориентируются до сих пор на максимум в 256 символов.
Один из workaround-ов - замапить директорию на диск, тогда прикладные программы заработают.
Как они с такими ограничениями ещё от идеи библиотек, которые расположены глубоко в профайле не ушли... или... да, я понял! Они именно по-этому переименовали Documents and Settings в Users, чтобы проблема была у меньшего числа пользователей и приоритет у бага можно было бы поменьше поставить.
библиотек, которые расположены глубоко в профайлеВ библиотеки ты сам можешь собрать какие угодно папки.
большинство никогда не воспользуется этой функцией
При вызове проводника из таскбара по умолчанию открываются библиотеки, поэтому да, эта функция будет и есть востребована. По крайней мере я сразу организовал разрозненные папки со сходным содержимым в библиотеки для удобства. А всякие неосиляторы новых фич винды могут продолжать дрочить на 15-летнюю икспи.
При вызове проводника из таскбара по умолчанию открываются библиотеки, поэтому да, эта функция будет и есть востребована. По крайней мере я сразу организовал разрозненные папки со сходным содержимым в библиотеки для удобства. А всякие неосиляторы новых фич винды могут продолжать дрочить на 15-летнюю икспи.ты не понял посыл - большинству пользователей винды совершенно похуй эти фичи, особенно тем, кто не застал XP и ранее
И ты так уверенно говоришь за большинство виндопользователей потому, что...?
например потому, что насмотрелся на таких ты хуй
То есть ты тупо слаернул. 
открываются библиотеки, поэтому да, эта функция будет и есть востребована.Ну, предположим, у меня есть личная статистика пользователям по 200 — никто не использует.
Сейчас спросил у коллег, которые поддерживают 500 пользователей — они тоже не видили, чтобы кто-нибудь этим пользовался. Пользователи — "офисные" и дизайнеры.
А зря.
кря кря
да, я понял! Они именно по-этому переименовали Documents and Settings в UsersДа, так оно и есть. При корпоративном использовании пути, вообще, получаются офигенские - из-за появления папок Roaming в глубинах пользовательского окружения. Появление коротких имен у стандартных папок и использование hard link-ов здорово проблему упростило.
В XP похоже они надеялись перейти на длинные имена, но, в итоге, сделать это не получилось - из-за того, что long path api не обеспечивает прозрачного перехода с short path api, а также из-за того, что оказалось дофига людей и кода, привязанных к старому виду имен.
ps
short path api - это пути вида D:\\bla\bla\file.txt и/или не-unicode-ная версия вызовов WinApi
long path api - это пути вида и unicode-ная версия вызовов WinApi
А зря.А как у windows с поддержкой этой штуки? Она поддерживается как ОС (монтированием или перехватом вызовов open, не важно) или прикладные программы должны специально учитывать существование библиотек?
да никак, это приблуда только для эксплорера
А зачем она тогда нужна? Есть куча катологизаторов не хуже.
1. идёт искаропки
2. искаропки во всех стандартных контролах типа "открыть файл" / "сохранить файл".
2. искаропки во всех стандартных контролах типа "открыть файл" / "сохранить файл".
2. искаропки во всех стандартных контролах типа "открыть файл" / "сохранить файл".В swing, javafx, tcl/tk тоже идёт? Или "все стандартные контролы" - это windows forms и .net?
В swing, javafx, tcl/tk тоже идёт?Если они вызывают стандартный виндовый диалог для выбора файла - то да, иначе - нет.
А, вспомнил, винда считает графику частью API операционной системы. Давно уже виндой не пользовался. В никсах есть что-то похожее, переменные окружения для вызова программы. Можно для открытия файлов вызывать любой понравившийся софт. В винде по идее тоже должна быть возможность подменять системные диалоги открытия файлов, не?
В винде по идее тоже должна быть возможность подменять системные диалоги открытия файлов, не?Для произвольного приложения?
Зачатки в XP были, но хз насколько они остались и насколько их можно использовать в production-е.
винда считает графику частью API операционной системыСтрого говорят нет. Сильно зависит от того, где проводить грань между ОС и не ОС.
Для произвольного приложения?для всех сразу.
Common Items Dialogs это COM объекты, так что никто не мешает их поменять.
То есть, теоретически сторонняя программа может столь же успешно браузить свои коллекции по кнопке "открыть"
Теоретически можно все, но ты почему-то сразу начинаешь думать с точки зрения программиста, тогда как пользователю удобнее единая система диалоговых окон.
Ты имеешь в виду создание своих библиотек? Это и без своих диалогов куча про умеет (dropbox, tortoise, etc...). Да и пользователи их могут руками создавать.
Ps а что в линуксах у каждой программы свои диалоговые окна?
Ps а что в линуксах у каждой программы свои диалоговые окна?
Ps а что в линуксах у каждой программы свои диалоговые окна?Должно было бы быть так. Но поскольку до недавнего времени утилиты линукса следовали концепции unix-way, они часто перепоручали диалоговые окна сторонним библиотекам и программам. Поэтому возникла некоторая унификация в зависимости от используемого стороннего ПО. Ну и плюс к тому, пользователю обычно доступны настройки, позволяющие подставить вызов удобного ему файлового менеджера. Дефолтного-то, помимо командной строки, для линукса нет. Пользователи кед или гнома могут этого и не замечать, но стоит собрать себе десктоп с нуля и заметишь отсутствии каких-либо жёстко привязанных дефолтов, всё изменяется.
Поэтому всякие яндекс диски не диалоги подменяют, которые у каждого софта свои, а используют FUSE файловую систему. Вот с файловыми системами в линуксе унификация и общее API. Кстати, забавный факт, чтобы найти в системе все точки монтирования, не будучи рутом, необходим полный скан всех директорий. Вызова API для получения списка монтированных систем в линуксе не предусмотрено.
Кстати, забавный факт, чтобы найти в системе все точки монтирования, не будучи рутом, необходим полный скан всех директорий.cat /proc/mounts
> Вызова API для получения списка монтированных систем в линуксе
> не предусмотрено.
О, да, когда они изобретут getmntinfo(3), это наверняка будет
что-то своё и весьма жуткое.
---
A26: я с самого начала считал её неудачным схемным реЩением!
да и не юзал никогда. мамой клянусь!
> не предусмотрено.
О, да, когда они изобретут getmntinfo(3), это наверняка будет
что-то своё и весьма жуткое.
---
A26: я с самого начала считал её неудачным схемным реЩением!
да и не юзал никогда. мамой клянусь!
О, да, когда они изобретут getmntinfo(3), это наверняка будетТогда уж говорил бы про getfsstat(3), потому что getmntinfo тоже страшноват.
что-то своё и весьма жуткое.
cat /proc/mountsВот поэтому я и вставил оговорку про рута. Рут может примонтировать procfs в какую-нибудь директорию и посмотреть на список маунтов. А простому пользователю таки придётся перебирать все директории, чтобы посмотреть, не примонтирован ли туда proc, а он может быть не примонтирован вовсе. Нахождение procfs в /proc - это всего лишь дефолтные настройки некоторых дистрибутивов, на которые нельзя полагаться в общем случае. Я ведь говорил про линукс, который ядро, а не про линукс, который убунту.
Кстати, даже если ты доберёшься до /proc/mounts, не факт, что системная корневая директория совпадает с твоей собственной. Впрочем, в том же proc можно подсмотреть свою корневую директорию и учесть разницу.
getfsstat(3)Вообще это getfsstat(2). Не путай API вызовы и обёртки к ним. Ну и тут уместно вспомнить глеба, который два года твердил, что фрибсд - это не линукс.
В линуксе вообще так цирк. Обёртка есть, а API вызова нет, обёртка просто читает файл /etc/mtab, в который, во-первых, никто не обязан писать, хотя стандартная утилита mount и делает это, во-вторых, даже она имеет опции для того, чтобы этот файл игнорировать, в-третьих, частенько бывают ситуации, когда файловую систему монтировать надо, а /etc/mtab не доступен для записи, в-четвёртых непривилегированный пользователь вполне себе может монтировать файловые системы через fuse, а писать в /etc/mtab у него прав нет.
Нахождение procfs в /proc - это всего лишь дефолтные настройки некоторых дистрибутивов, на которые нельзя полагаться в общем случае. Я ведь говорил про линукс, который ядро, а не про линукс, который убунту.Я не знаю, как в вашем бездбасовом эльфятнике с пони и бабочками, а в современном реальном мире любой линукс просто не будет работоспособен без смонтированного /proc.
Ядро работоспособно само по себе. Даже если у него в качестве init циклический hello world запущен. А остальное - уже не линукс, а надстройки. И я обсуждаю именно операционную систему и её недостатки, к которым причисляю невозможность получить список точек монтирования. Как ты понимаешь, если надстройка вообще откажется от монтирования куда-либо кроме предустановленных директорий, и будет неработоспособна иначе, то это тоже поможет спрятать проблему. Но создаст недостаток функциональности. Кому нужен fuse для ftp, если нестандартное монтирование запрещено?
современном реальном мире любой линуксПоэтому можно презреть терминологию? Определить операционную систему как способ отражения веб-страничек, например, потому что в реальном мире все современные операционные системы... И выкинуть нафиг таненбаума, потому что он скучен со своими определениями.
потому что он скучен со своими определениямиИ потому что он упарывается по миниксу!
ти так пишешь, как будто это только под никсами можно
Униксоеды ещё и греп на винду перенесли.
---
"Рот фронт, группенфюрер..."
---
"Рот фронт, группенфюрер..."
Поэтому можно презреть терминологию?Хз что там у Таненбаума, но вики с твоим определением совершенно не согласна.
но вики с твоим определением совершенно не согласна.
Операцио́нная систе́ма, сокр. ОС (англ. operating system, OS) — комплекс взаимосвязанных программ, предназначенных для управления ресурсами вычислительного устройства и организации взаимодействия с пользователем.Ну и что здесь противоречит моему определению? Прибитое гвоздями /proc относится к абстракции над железом? Является ли API? Подсказка: API лежит во втором разделе мана (не в третьем, как в этом топике один раз уже спутали). Операционной системой назван Linux, а не GNU/Linux, то есть всю гнутую обёртку, включая mount и прочие базовые утилиты, и даже sysvinit, вики признаёт не обязательной частью, не принадлежащей операционной системе вовсе.
В логической структуре типичной вычислительной системы операционная система занимает положение между устройствами с их микроархитектурой, машинным языком и, возможно, собственными (встроенными) микропрограммами (драйверами) — с одной стороны — и прикладными программами с другой.
Разработчикам программного обеспечения операционная система позволяет абстрагироваться от деталей реализации и функционирования устройств, предоставляя минимально необходимый набор функций (см.: интерфейс программирования приложений).
В большинстве вычислительных систем операционная система является основной, наиболее важной (а иногда и единственной) частью системного программного обеспечения. С 1990-х годов наиболее распространёнными операционными системами являются системы семейства Windows, UNIX и UNIX-подобные системы, в особенности Linux и Mac OS.
Прибитое гвоздями /proc относится к абстракции над железом?Где в приведенном тобой определеннии встречаются слова "абстракция над железом"?
Является ли API?Является.
Там есть слова "комплекс взаимосвязанных программ, предназначенных для управления ресурсами вычислительного устройства и организации взаимодействия с пользователем" и прибытыми гвоздями "/proc" вполне в это укладывается.
Даже виндовый стандартный диалог для выбора файлов в это укладывается.
Где в приведенном тобой определеннии встречаются слова "абстракция над железом"?
В логической структуре типичной вычислительной системы операционная система занимает положение между устройствами с их микроархитектурой, машинным языком и, возможно, собственными (встроенными) микропрограммами (драйверами) — с одной стороны — и прикладными программами с другой.В логической структуре такие прослойки называются абстракциями. Абстракция над железом - это кратко, понятно и общепринято.
Является.Прибитое гвоздями - нет. В качестве API линукс предлагает лишь саму procfs, но не конкретное местоположение её точки монтирования.
комплекс взаимосвязанных программ,В случае линукса, этими программами является монолитное ядро, модули к нему и файлы firmware для драйверов. Всё остальное - это пространство пользователя.
В любом случае определения вики далеки от "совершенного" несогласия с моей позицией.
Правильно я понимаю, что все, что обеспечивает взаимодействие с пользователем, не является часть ОС?
Правильно я понимаю, что все, что обеспечивает взаимодействие с пользователем, не является часть ОС?По крайней мере не должно. Не все программные продукты умеют разграничивать области ответственности и следовать модульной схеме. Поэтому возможно существование такой компьютерной системы, где взаимодействие с пользователем реализовано неделимым программным комплексом, который также отвечает и за функции операционной системы.
Очевидно, что в случае с линуксом это не так, понятия операционной системы и дистрибутива там разделены, как в теории, так и на практике. Более того, существует даже два разных имени, обозначающих разные продукты - Linux и GNU/Linux.
На мой вкус:
Linux - ядро
GNU/Linux - ОС
Redhat Linux (например) - дистрибутив
Linux - ядро
GNU/Linux - ОС
Redhat Linux (например) - дистрибутив
А чем ты видишь андроид?
upd: а бизибокс?
upd: а бизибокс?
Линупсоеды, валите в свой альт!
Вантузоиды, валите в свой альт!
Абстракция над железом - это кратко, понятно и общепринято.Это всегда было драйвером железки.
ОС - это посредник, арбитр и т.д. между программами: как между драйверами, так и между прикладными, так и между прикладными и системными.
Нахождение procfs в /proc - это всего лишь дефолтные настройки некоторых дистрибутивов, на которые нельзя полагаться в общем случае.А что на счёт /dev?
А что на счёт /dev?Ну я застал ещё статический /dev, тогда было всё иначе. Сейчас вроде /dev монтируется самим ядром, поэтому может считаться прибитым на уровне ОС.
Ну я застал ещё статический /dev, тогда было всё иначе.Аналогично.
Сейчас вроде /dev монтируется самим ядромВ линуксе - может быть, не ковырял. Во фряхе точно нет.
В линухе вроде недавно за счёт ядра избавились от зависимости от udev.
По-моему статический dev в линуксе никогда не переставал работать, во всяком случае у меня не возникало с ним никаких проблем, когда мне хотелось жить без udev.
сейчас ядро научилось какой-то простой devfs самостоятельно поддерживать. Судя по опциям. Сам не пробовал.
На мой вкус:Такой подход можно понять, но возникает куча сложностей с определением среднего пункта. Это же не единая программа, это сотни мелких утилит, большую часть которых реально переписать пользователю, настолько они малы. Тот же инит с чтением конфига можно заменить на статический бинарь. Заменить один сервис другим, при том новый будет распространяться не под GNU лицензией, а под какой-нибудь MIT. Да и границы ответственности между ОС и дистрибутивом очень трудно провести. Какую программу отнести к ОС, а какую к дистрибутиву? Ведь это, в принципе, одинаковые эльфятники. Поэтому, столкнувшись со сложностью определений, я предпочёл ограничить ОС тем, что ты называешь ядром, а всё остальное считать прикладным софтом. Из-за его необязательности и взаимозаменяемости.
Linux - ядро
GNU/Linux - ОС
Redhat Linux (например) - дистрибутив
Да и границы ответственности между ОС и дистрибутивом очень трудно провести. Какую программу отнести к ОС, а какую к дистрибутиву? Ведь это, в принципе, одинаковые эльфятники. Поэтому, столкнувшись со сложностью определений, я предпочёл ограничить ОС тем, что ты называешь ядром, а всё остальное считать прикладным софтом. Из-за его необязательности и взаимозаменяемости.LFS чем не угодил?
Ещё можно сюда какие-то части POSIX нафантазировать.
Это всяко ближе к общепринятой терминологии, чем твой вариант.
POSIX - это стандарт. При этом бывает не только линуксовая реализация, но даже в винде есть прослойка совместимости. Соответственно, говоря "у меня стоит POSIX ОС", ты указываешь прискорбно мало. Даже посикс-совместимым линуксом можно быть по-разному. Можно сидеть на гнутых утилитах, а можно утянуть из фрибсди их утилиты.
А если ты говоришь, у меня стоит Linux ОС, это тоже значит немного. С ядром, понятное дело, всё определено. Но со всем остальным будет плохо. Могут быть разные системы инициализации, на каком-то линуксе может отсутствовать половина POSIX команд, но он останется линуксом. Я видел вариант линукса, где в качестве init системы использовался common lisp, и сценарии запуска сервисов и шелл тоже были написаны на лиспе. Он был убог, но был линуксом. Вариантов слишком много, чтобы описать их одним словом. Понятие линукса оказывается неопределённым. Поэтому я и предпочитаю определять линукс в узком смысле как ядро линукса.
Если у тебя есть другое определение линукса с чётким списком программ, которые в него входят помимо собственно ядра, я хотел бы его услышать.
А если ты говоришь, у меня стоит Linux ОС, это тоже значит немного. С ядром, понятное дело, всё определено. Но со всем остальным будет плохо. Могут быть разные системы инициализации, на каком-то линуксе может отсутствовать половина POSIX команд, но он останется линуксом. Я видел вариант линукса, где в качестве init системы использовался common lisp, и сценарии запуска сервисов и шелл тоже были написаны на лиспе. Он был убог, но был линуксом. Вариантов слишком много, чтобы описать их одним словом. Понятие линукса оказывается неопределённым. Поэтому я и предпочитаю определять линукс в узком смысле как ядро линукса.
Если у тебя есть другое определение линукса с чётким списком программ, которые в него входят помимо собственно ядра, я хотел бы его услышать.
Можно сидеть на гнутых утилитах, а можно утянуть из фрибсди их утилиты.Ну так это и будет, например, GNU/Linux — как это называют Столлман и Дебиан, и что все остальные сокращают просто до "линукс" в силу повсеместности этого "GNU". Можно сделать какой-то BSD/Linux или CommonList/Linux, почему бы нет. Вот как в дебиане сделали GNU/kFreeBSD, только наоборот.
Могут быть разные системы инициализации, на каком-то линуксе может отсутствовать половина POSIX команд, но он останется линуксом. Я видел вариант линукса, где в качестве init системы использовался common lisp, и сценарии запуска сервисов и шелл тоже были написаны на лиспе. Он был убог, но был линуксом. Вариантов слишком много, чтобы описать их одним словом. Понятие линукса оказывается неопределённым. Поэтому я и предпочитаю определять линукс в узком смысле как ядро линукса.Ты говоришь «но он был линуксом», исходя как раз из собственного определения.
Ну так приведи своё собственное определение. Что является каноничной ОС линукса, которое больше чем ядро.
Каноничное ядро - это содержимое kernel.org, скомпиленное в виде монолитного ядра и пачки модулей. Возможны патчи и дополнительные модули, которые делают ядро кастомным.
Каноничный убунту - это минимально необходимый набор пакетов, куда очевидно включен пакетный менеджер, система инициализации и ещё почуть системных пакетов, плюс возможность доставить любой пакет из репозитория, а также возможность любой настройки, предусмотренной самой убунтой. Каноничный генту - это тоже минимальный набор пакетов + все возможные комбинации установки прочих пакетов, допустимые пакетным менеджером. Очевидно, бывает неканоничный генту и убунту, когда используются собственные репозитории пакетов. Но в общем и целом каждый дистрибутив представляет стандарт ad-hoc, который даёт некоторые намёки пользователю и программисту, на что они могут рассчитывать, работая под этой системой.
А ещё есть андроид, есть Nix, который ставит приложения в одну папку, а не размазывает по системе как это обычно делается, есть openwrt, и все они утверждают, что они дистрибутивы линукса.
Покажи мне аналогичный канон для того, что ты назыавешь ОС Linux. Где можно узнать, что в него входит гарантировано и потенциально?
Каноничное ядро - это содержимое kernel.org, скомпиленное в виде монолитного ядра и пачки модулей. Возможны патчи и дополнительные модули, которые делают ядро кастомным.
Каноничный убунту - это минимально необходимый набор пакетов, куда очевидно включен пакетный менеджер, система инициализации и ещё почуть системных пакетов, плюс возможность доставить любой пакет из репозитория, а также возможность любой настройки, предусмотренной самой убунтой. Каноничный генту - это тоже минимальный набор пакетов + все возможные комбинации установки прочих пакетов, допустимые пакетным менеджером. Очевидно, бывает неканоничный генту и убунту, когда используются собственные репозитории пакетов. Но в общем и целом каждый дистрибутив представляет стандарт ad-hoc, который даёт некоторые намёки пользователю и программисту, на что они могут рассчитывать, работая под этой системой.
А ещё есть андроид, есть Nix, который ставит приложения в одну папку, а не размазывает по системе как это обычно делается, есть openwrt, и все они утверждают, что они дистрибутивы линукса.
Покажи мне аналогичный канон для того, что ты назыавешь ОС Linux. Где можно узнать, что в него входит гарантировано и потенциально?
Вот бесит эта манера сумасшедших линуксоидов говорить, что "в линуксе есть всё" и иметь в виду дистрибутивы (и андроид заодно), но как только где-то есть баг/неудобство, линукс мгновенно становится ядром. Вы уж определитесь, а?
ps: в windows нет ошибки описанной деметром в первом посте. В windows server core, да.
ps: в windows нет ошибки описанной деметром в первом посте. В windows server core, да.
Давай проще:
1. Linux - это ядро.
2. Linux ОС - это любая операционная система, основанная на ядре Linux.
3. GNU/Linux - это ОС с ядром Linux и окружением GNU.
1. Linux - это ядро.
2. Linux ОС - это любая операционная система, основанная на ядре Linux.
3. GNU/Linux - это ОС с ядром Linux и окружением GNU.
А ещё есть андроид, есть Nix, который ставит приложения в одну папку, а не размазывает по системе как это обычно делается, есть openwrt, и все они утверждают, что они дистрибутивы линукса.Никто из них не говорит, что он является дистрибутивом Linux. Сборкой на основе ядра Linux - да, но не дистрибутивом.
в windows нет ошибки описанной деметром в первом посте. В windows server core, да.А что, можно заменить в винде windows server core на аналог?
как только где-то есть баг/неудобство, линукс мгновенно становится ядром.Ядро - единственная вещь, которая незаменима в линуксе. Поэтому, если ошибка есть в ядре, то она есть в любом линуксе. Если ошибка есть в какой-то другой программе, нельзя сказать, что она есть в любой сборке линукса, только в той, что где используется эта программа. В мире свободного софта принято найденные ошибки репортить автору. Поэтому понимание, чей именно косяк - хорошая идея.
Вы уж определитесь, а?Всё очень просто. Если ошибка присутствует всегда - это ошибка системы. Если ошибка присутствует только в некоторой конфигурации, которую можно избегать - это не ошибка системы. И наоборот, если функциональность присутствует хоть где-то, она есть в системе, если присутствует хотя бы в одной программе. Инвертируется не определение линукса, а кванторы общности. Поэтому разнообразие, даруемое модульностью, так прекрасно - ты можешь выбирать лучшие элементы с подходящей функциональностью, при этом избегать элементов, где обнаружились ошибки.
Виндовс этого преимущества лишён. Это один сплошной безальтернативный кусок.
Впрочем, если речь идёт о пользовательских приложениях, то обе системы позволяют устанавливать произвольный софт. И пользователи виндовса тоже не испытывают проблем с кванторами общности и разделения зон ответственности майкрософта и поставщика дополнительного софта.
Если ошибка присутствует только в некоторых условиях, которые можно избегать - это не ошибка системыЭто как это? То есть если в системе где-то, к примеру, не эскейпится SQL-запрос, то это не ошибка, потому что я могу ее избегать, составляя запросы, которые эскейпить не нужно?
Виндовс этого преимущества лишён. Это один сплошной безальтернативный кусок.Что именно нельзя заменить в Windows? Это, конечно, реже используется и хуже документировано, чем в linux-е, но всё кроме ядра ровно так же заменяется.
Никто из них не говорить, что он является дистрибутивом Linux. Сборкой на основе ядра Linux - да, но не дистрибутивом.А в чём разница между дистрибутивом и сборкой? Я не цепляюсь, я просто хочу понять эту тонкость.
2. Linux ОС - это любая операционная система, основанная на ядре Linux.А такие операционные системы водятся в живой природе отдельно от дистрибутивов? Каждый дистрибутив фактически порождает свою операционку (если считать её за нечто большее чем ядро). В таком случае зачем вводить дополнительный термин Linux ОС, когда уже есть дистрибутив?
3. GNU/Linux - это ОС с ядром Linux и окружением GNU.http://www.gnu.org/software/coreutils/ - вот это? Годное и понятное определение, я его принимаю.
А теперь самое интересное, с чего всё и начиналось - монтирование /proc. Исходя из твоих определений, выходит, что
1. Linux ОС не обязательно монтирует procfs в /proc. Потому что они сильно разные, это веерный термин.
2. GNU/Linux не обязательно монтирует procfs в /proc. Потому что это набор утилит, а не их настройки и скрипты инициализации.
Ну и до кучи, ещё и POSIX не имеет никаких стандартов на /proc, потому что procfs - это зависимая от конкретного ядра штука, а POSIX независимый стандарт для разных операционок, включая винду.
Это как это? То есть если в системе где-то, к примеру, не эскейпится SQL-запрос, то это не ошибка, потому что я могу ее избегать, составляя запросы, которые эскейпить не нужно?Запросы - это внешняя функциональность по отношению к СУБД, ты не можешь её контролировать. Но если у тебя есть опция "включать автоматический эскейп" для запросов - то это не ошибка, настроив его, ты избавляешься от ошибки. Либо ты можешь выбрать другой модуль, который эскейпит запросы и поставить на место старого. Либо поставить модуль-прокси, который забирает все запросы, фильтрует и выдаёт только корректные.
А теперь представь, что ты это сказал секретарше, которая этой системой просто пользуется.
Все равно не ошибка?
Все равно не ошибка?
Если ошибка присутствует только в некоторых условиях, которые можно избегать - это не ошибка системы.Следует ли из этого, что ситуация, которую описал ТС в начальном сообщениии - не является ошибкой? т.к. для нее всё это выполняется - проблема возникает только при условии, что для доступа к файлам используется explorer.
Что именно нельзя заменить в Windows? Это, конечно, реже используется и хуже документировано, чем в linux-е, но всё кроме ядра ровно так же заменяется.Не вопрос. Если мне в ответ на жалобу в поведении винды скажут, замени XXX и поставь YYY, я не обижусь и посчитаю это конструктивным ответом. Разумеется, если YYY уже существует, а не предлагается мне написать самому (дольше чем за час). Но что-то я давно уже таких предложений не встречал. Обычно, если в виндовсе что-то не работает, и это действительно проблема виндовса а не тайная настройка где-нибудь в реестре, то не починить это никак. Вот об этом обычно я и говорю.
Вот в обсуждении линукса может быть сказано "это проблемы пакетного менеджера убунты". Подразумевая, что можно заменить его редхатовским, арчевским или гентушным. Что является справедливой отповедью на "в этом вашем линуксе ничего не работает". И очевидно глупой отмазкой в ответ на "ваша убунту гавно, в ней не работает ..." Потому что если обозначена область видимости "Убунту", то для неё альтернатив нет.
Все равно не ошибка?Это не ошибка системы. Это ошибка модуля или настройки. Я поправлю, скажу что виндовс/линукс здесь не при чём, что причём такая-то программа, и что она работает в соответствии с заданными настройками, которые надо сменить.
Но обычно секретарши не пытаются наезжать на систему, они просто просят починить неисправность или добавить функциональности.
Разумеется, если YYY уже существует, а не предлагается мне написать самому (дольше чем за час).Имхо, здесь где-то появляется предвзятость.
Когда ты обсуждаешь монтирование /proc ты не используешь это условие, что уже должно быть разработано ПО, которое корректно работает с несмонтированным /proc
Следует ли из этого, что ситуация, которую описал ТС в начальном сообщениии - не является ошибкой? т.к. для нее всё это выполняется - проблема возникает только при условии, что для доступа к файлам используется explorer.А ты уверен, что только эксплорер? Что, скажем, из командной строки всё заработает? Я не проверял, но допустим ты прав.
Это означает, что нет ошибки в системе, а лишь в одном из блоков, поставляемых из каробки. То есть, ты можешь заявить, что винда из каробки не работает. С линуксом это бывает сплошь и рядом. Отличие только в том, что линукс редко претендует на изкаробочность (кроме убунту шутов), а виндовс заявляет это своим преимуществом. Возникает ситуация "а зачем тогда платить больше"?
Плюс возникает вопрос, а чем можно заменить эксплорер и как? Когда я сидел на XP, я так и не смог его искоренить, хотя много разных экспериментов проводил. Сейчас это стало возможным?
Когда ты обсуждаешь монтирование /proc ты не используешь это условие, что уже должно быть разработано ПО, которое корректно работает с несмонтированным /procЯ обсуждаю, как должно быть, а не как есть. Большая часть ПО прекрасно живёт, не имея представления о том, что куда смонтировано, абстракции файловой системы позволяют, это ПО проблемы /proc не волнует, оно живёт в предположении, что его не существует и что оно вообще запущено из chroot, и его собственный корень может отличаться от системного. Дефолтные предположения для пользовательского софта.
Если заведётся какое-то ПО, которое внезапно требует нестандартных вещей (и не настраиваемых), я его просто пошлю в топку. Как послал пользовательское ПО, которое вообразило себя системным и зачем-то требует udev. Если выйдет так, что любая система для работы с монтированием пойдёт в топку, я напишу большой гневный пост на форум "как охренели утилитописатели отклоняться от стандарта", то есть публично признаю несовершенство экосистемы линукса, и навелосипежу своё.
А ты уверен, что только эксплорер? Что, скажем, из командной строки всё заработает? Я не проверял, но допустим ты прав.Из cmd не заработает. Из командной строки заработает.
Возникает ситуация "а зачем тогда платить больше"?Это уже какое-то другое утверждение. Имеющее малое отношение к ошибкам в ОС. И ответы на этот вопрос возможны разные, например, что деньги берутся не за безбажную коробку, а за возможность использования такого же окружения как и у других миллионов пользователей.
Плюс возникает вопрос, а чем можно заменить эксплорер и как?Использовать вместо explorer-а другую программу и выкорчевать explorer - это совершенно две разные задачи. Explorer не хорошо выкорчевывать, потому что на него завязаны большое кол-во других прикладных программ. Но ведь это не имеет никакого отношения к ОС, если под ОС подразумевается ядро - не так ли?
я напишу большой гневный пост на форум "как охренели утилитописатели отклонятся от стандарта", то есть публично признаю несовершенство экосистемы линукса
а также...Но ведь это не имеет никакого отношения к ОС, если под ОСЭто имеет отношений к тому, что продаётся как майкрософт виндовс и называется виндой. Если спросишь, почему я для винды и для линукса использую разные градации разграничения ответственности, где лежит ядро, операционка и прикладной софт, то я готов привести сравнение со стеками tcp/ip и OSI. Это разные способы добиться одного и того же, но из-за того, что они разные, у них разное количество логических уровней, у одного четыре, у второго - семь.
Из cmd не заработает. Из командной строки заработает.В чём разница в случае винды?
Это уже какое-то утверждение. Имеющее малое отношение к ошибкам в ОС.Так топикстартер и не делал утверждений об ошибках в ОС виндовс. Он указывал на хреновый юзерэкспириенс в дефолтной поставке винды. И никто даже не удосужился подсказать ему, что ошибка не в ОС, а в чём-то исправимом, как это обычно делают в похожих тредах про юзерэкспириенс в линукс. Пока ты не завёл эту тему, она вообще не обсуждалась. Если захотим продолжить - я сцежу в обсуждении немного яда, который у меня заготовлен для вещей, который заявляют функциональность (работа из каробки) и не выполняют обещания. Обычно я посылаю лучи поноса в убунту, но могу переключиться и на винду.
Explorer не хорошо выкорчевывать, потому что на него завязаны большое кол-во других прикладных программИ вот тут я благодарен федечке за его вопрос о SQL эскейпах. То, что предлагаешь ты - попросить пользователя не вводить неправильный запрос (не использовать встроенный в программы эксплорер). И я говорил, что это не является ошибкой, только если возможна полная замена на том уровне, где ошибка находится. То есть на уровне эксплорера. Если ты наложишь патч на эксплорер, или заменишь его на другую прогу во всех местах применения, или запихнёшь туда какой-нибудь хук для корректной обработки сложных ситуаций - то это исправимая ошибка системы, где экплорер является частью. Если система не позволяет эксплорер заменить или пропатчить, то значит ошибка эксплорера распространяется за его пределы до всей системы или более крупной части, которую можно сменить целиком.
В чём разница в случае винды?Какой-нибудь повершел что ли, или же bash из сигвина - чем не консоль?
А в чём разница между дистрибутивом и сборкой? Я не цепляюсь, я просто хочу понять эту тонкость.В том контексте под сборкой я понимал "Linux ОС". Неудачно подобрал термин.
Есть отдельное понятие "GNU/Linux дистрибутив" и "GNU/Linux сборка". Принципиальное отличие в том, что у дистрибутива есть полная экосистема - мэинтейнеры, репозитории, сборку всех пакетов ведут сами, поддерживают всё сами и т.д. Сборка же основывается на каком-то дистрибутиве и использует его репозитории как основные (хотя дополнительно может иметь и свои, для отсутствующих в основных репозиториях пакетов).
Ага, понятно, сборка - это замороженный дистрибутив. Например, "убунту из каробки" - это сборка, тогда как просто убунту с пакетными менеджером и набором пакетов - дистрибутив. Помимо этого, команда поддерживает ещё несколько сборок - kubuntu, lubuntu, xubuntu и прочие *ubuntu.
Так вот, nix - это пакетный менеджер и отдельный дистрибутив в твоём понятии. Крайней нестандартный.
Так вот, nix - это пакетный менеджер и отдельный дистрибутив в твоём понятии. Крайней нестандартный.
ps: в windows нет ошибки описанной деметром в первом посте. В windows server core, да.В какой версии? Как проверял?
А теперь самое интересное, с чего всё и начиналось - монтирование /proc. Исходя из твоих определений, выходит, что
1. Linux ОС не обязательно монтирует procfs в /proc. Потому что они сильно разные, это веерный термин.
2. GNU/Linux не обязательно монтирует procfs в /proc. Потому что это набор утилит, а не их настройки и скрипты инициализации.
coreutils-8.23$ grep -R '/proc/'
...
lib/openat-proc.c:#define PROC_SELF_FD_FORMAT "/proc/self/fd/%d/%s"
lib/openat-proc.c: int proc_self_fd = open ("/proc/self/fd",
src/stdbuf.c: char *path = xreadlink ("/proc/self/exe");
src/uptime.c: fp = fopen ("/proc/uptime", "r");
Т.о. GNU/Linux обязательно монтирует procfs в /proc, иначе его утилиты становятся неработоспособны.
ну вот такие плохие утилиты.
в любой - там проводника нет (так что это был привет айвенго). В вообще стоит сходить сюда и проголосовать за фичу.
я уже начинаю сомневаться, а графические приложения там есть?
ты гуглом, яндексом и бингом не пользуешься из идеологических соображений, а на duckduckgo тебя забанили, да?
если дашь мне поисковую строку, я введу, не побрезгаю. Но пока я что-то не догадался о чём именно ты говоришь.
Windows server core
http://msdn.microsoft.com/en-us/library/dd184075.aspx
http://msdn.microsoft.com/en-us/library/dd184075.aspx
А что будет, когда туда установишь какой-нибудь mpc? Что он будет делать, когда пользователь нажимает на кнопку "открыть"? Открывать эксплорер, который якобы не установлен в системе, выдавать эксепшн, игнорировать нажатие клавиши, предлагать доставить эксплорер с установочного диска?
Что он будет делать, когда пользователь нажимает на кнопку "открыть"?Что в mpc написано, то и будет происходить.
Первый вариант.
Mpc использует либу common dialogs (которая находится в папке explorer) и explorer снесен.
При нажатию на кнопку, вызов функции из этой либы сгенерит ошибку. Mpc либо выдаст эту ошибку, либо упадет (в зависимости от того, как написан)
Второй вариант
Mpc использует либу common dialogs, explorer снесен, бинарники необходимые для работы common dialogs перенесены в папку mpc.
При нажатии на кнопку всё заработает.
Третий вариант
Mpc не использует common dialogs, а отрисовывает диалог выбора файлов самостоятельно.
Всё будет работать в независимости от наличия explorer-а.
Четвертый вариант
Mpc использует common dialogs, exporer снесен, в систему установлена и настроена другая реализация common dialogs, совместимая с родной.
При нажатии на кнопку всё заработает.
ps
В windows большая часть кода взаимодействует между собой как библиотеки (через COM), а не как вызов другой программы. Соответственно, здесь есть только два варианта: либо либа есть и подгружается, либо либы нет - тогда возвращается код ошибки.
Между либами exception-ы не ходят, а ходят только коды возврата. Соответственно, способ обработки этого кода возврата целиком лежит на самой программе.
Если ошибка присутствует только в некоторой конфигурации, которую можно избегать - это не ошибка системы.Если ошибка находится в системе и ее можно избежать, но уже есть куча софта, который написан так, что на эту ошибку напарывается, то это ошибка системы или нет?
Оставить комментарий
schipuchka1
К сожалению сползла в архив, но не поделиться этим я не могу...2015 год блин, нтфс блин, 64-битная винда блин - попробовал кино посмотреть