После 18 месяцев разработки представлен (http://www.citi.umich.edu/projects/nfsv4/windows/readme.html) открытый драйвер ms-nfs41-client, предназначенный для обеспечения работы Windows в качестве NFSv4.1-клиента. Код драйвера доступен для загрузки из Git-репозитория проекта ("git clone git://citi.umich.edu/projects/ms-nfs41-client.git").
Windows-драйвер основан (http://www.citi.umich.edu/projects/nfsv4/) на оригинальной эталонной реализации для Linux и полностью совместим с ней как по степени поддержки спецификации NFSv4.1 (http://www.citi.umich.edu/projects/nfsv4/rfc/rfc3530.txt), так и по реализованным возможностям. Драйвер поддерживает работу в Windows Vista, Windows Server 2008 и более поздних версиях. Ранее для Windows была доступна только поддержка NFSv3.
NFSv4.1 позволяет (http://www.opennet.me/opennews/art.shtml?num=15015) организовать высокоскоростной обмен данными между машинами сети за счет возможности распараллеливания обращения к данным на нескольких хранилищах, а...URL: http://www.h-online.com/open/news/item/Open-source-Windows-d...
Новость: http://www.opennet.me/opennews/art.shtml?num=28221
расскажите пожалуйста для нубов: NFS круче самбы (в плане скорости работы с файлами по сети) и если да то на сколько и чем ?
Ничем не круче.
Наоборот, хуже самбы гораздо, практически во всём.
За исключением возможности с NFS грузиться.
К прочтению: https://encrypted.google.com/search?hl=en&source=hp&q=why�...
Бред. Самба - разжиревший FTP, NFS - полноценная сетевая ФС. Документ, про который вы говорите был написан под влиянием неслабого butthurt'а, и для nfsv2 который умер когда вас еще в проекте не было. И да, NFS быстрее.
> Бред. Самба - разжиревший FTP, NFS - полноценная сетевая ФС. Документ, про
> который вы говорите был написан под влиянием неслабого butthurt'а, и для
> nfsv2 который умер когда вас еще в проекте не было. И
> да, NFS быстрее.ИМХО -- NFS редкое говно -- не смотря на то, что подпорками и кастылями многое исправили.
взять те-же pvfs/afs/lustre и на худой конец cifs и нахер не сдался этот nfs с его гребанутым rpc
IMHO, некорректно сравнивать распределенные ФС с сетевыми
> IMHO, некорректно сравнивать распределенные ФС с сетевымитаки имеенно 4.1 nfs позиционируется как distributed
таки мымросовт какбы dfs пытается позиционировать как distibuted, хотя она такой не является и cifs соответственно
таки любая distributed устроена сложнее чем не distributed -- от чего-жиии тогда с nfs такая жопаepic fail!
ну если вы это всё знаете, то зачем сравнивать?
пусть себе позиционируют.
зы:
адназначна я не буду поднимать люстру на своём роутере, чтобы посмотреть что там торрент накачал.
а там нфс быстрее смб.
> ну если вы это всё знаете, то зачем сравнивать?
> пусть себе позиционируют.
> зы:
> адназначна я не буду поднимать люстру на своём роутере, чтобы посмотреть что
> там торрент накачал.
> а там нфс быстрее смб.а tftp ещё быстрее -- загвоздка есть, неудобно немного -- но а настоящему индейцу....
а обычным вынь-до-усерам почему-то проще с cifs
да чтож такое то!
ок. ещё раз.
>а tftp ещё быстрее -- загвоздка есть, неудобно немного -- но а настоящему индейцу....а nfs вполне себе удобна.
>а обычным вынь-до-усерам почему-то проще с cifsа этим вообще пох как протокол называется.
лишь бы в 2-а клика мышкой хоть как-то работало.
>а nfs вполне себе удобна.Вот не факт. С nfs версией 3 точно были проблемы кодировки имен файлов. И скорость... Ты пишешь, что с NFS нет проблем, так напиши, где и как ты ее использовал и насколько человек.
> ИМХО -- NFS редкое говноSMB не лучше. Извините, а вы видели как работают по SMB разные системы от MS между собой, хотя-бы? Бывает все, вплоть до взвиса системы где-то в ядре при работе с шарой и появления неубиваемого процесса. Особенно при потугах юзания SMB2, зачем-то по дефолту активного в новых осях, что вызывает жуткий батхерт у тех кто этим пользуется. Т.к. не прикольно когда программа работавшая с сетью повисает и вообще не убивается из манагера процессов никак, и та же участь постигает все программы пытавшиеся работать с сетевыми шарами. После этого даже ОС корректно перезагрузить уже не светит. А если не дай боже в такой зоопарк еще и линуксы добавить... уй, это для мазохистов. SMB - Sado-Maso-Bullsh*t. Судя по тому как все это в сумме работает.
Нормально дружит Win7 с WinXP, как когда-то нормально дружили WinXP с Win98. Я даже и не знаю что нужно сделать, чтобы получить ваши симптомы. Вот линукс с 7 да, плохо дружит у меня - большой файл невозможно передать т.к. связь прерывается до перезагрузки fusesmb/smbnetfs.
>Ничем не круче.
>Наоборот, хуже самбы гораздо, практически во всём.NFS значительно круче, если что. Куда быстрее и надежнее. Плюс кеширование на стороне клиента, плюс значительно более быстрая работа NFS4 на гигабитных сетях.
>>Ничем не круче.
>>Наоборот, хуже самбы гораздо, практически во всём.
> NFS значительно круче, если что. Куда быстрее и надежнее. Плюс
> кеширование на стороне клиента, плюс значительно более быстрая работа NFS4 на
> гигабитных сетях.Конкретный пример из собственного опыта, пожалуйста. Что делал и на сколько человек оказалось быстрее.
на гигабитных говоришь ?? она уже теперь больше 40мбит стала передавать ?.
Или может пример приведешь реально работающей (даже при нативных ххх-никс системах на обеих концах)?
> на гигабитных говоришь ?? она уже теперь больше 40мбит стала передавать ?.
> Или может пример приведешь реально работающей (даже при нативных ххх-никс системах на
> обеих концах)?Да, стала. С добрым утром. Почитай спецификацию и проверь сам, если не веришь.
>> на гигабитных говоришь ?? она уже теперь больше 40мбит стала передавать ?.
>> Или может пример приведешь реально работающей (даже при нативных ххх-никс системах на
>> обеих концах)?
> Да, стала. С добрым утром. Почитай спецификацию и проверь сам,
> если не веришь.Ну может в спеках (на бумаге оно и так) а вот на практике - совсем по другому.
На больших файлах наблюдается стабильная регрессия скорости передачи от времени.
А обрыв связи между узлами до сих пор воспринимается как бесконечно-малая скорость ?
> Ну может в спеках (на бумаге оно и так) а вот на
> практике - совсем по другому.
> На больших файлах наблюдается стабильная регрессия скорости передачи от времени.
> А обрыв связи между узлами до сих пор воспринимается как бесконечно-малая скорость
> ?На моем опыте все реально работает значительно быстрее. Почитав спецификацию, я понял почему. Короче, пробуйте сами господа. NFS юзаю много лет на разных задачах и очень доволен.
Самба (CIFS) в данном случае удобней только глючным браузером сети, у NFS браузера вообще нет.
>Самба (CIFS) в данном случае удобней только глючным браузером сети, у NFS браузера вообще нет.С командной строки уже немодно? :-)
Я про конкретную функцию.
В Самбе эта функция есть, хоть и криво реализована (причём самим МС). В NFS этой функции нет. Командная строка нивелирует это единственное преимущество.
Опять же, юзверям очень неудобно использовать командную строку, особенно, когда количество шар в сети больше одной.
> расскажите пожалуйста для нубов: NFS круче самбы (в плане скорости работы с
> файлами по сети) и если да то на сколько и чем
> ?Скажем так.
В 100мегабитной локалке на нормальном оборудовании вы и там, и там увидите скорость 10-12 метров/с.
Но если вы глянете на хавание проца...К тому же.
Если вы используете только *nix, вам оказывается не нужен огромный пласт функционала самбы.
Плюс, если для "тупо файлов покачать", настройка nfs проще.Но, если есть шанс, что к вам зайдет блондинка с ноутбуком (без админских прав на этот ноутбук), то... только CIFS.
>[оверквотинг удален]
> Скажем так.
> В 100мегабитной локалке на нормальном оборудовании вы и там, и там увидите
> скорость 10-12 метров/с.
> Но если вы глянете на хавание проца...
> К тому же.
> Если вы используете только *nix, вам оказывается не нужен огромный пласт функционала
> самбы.
> Плюс, если для "тупо файлов покачать", настройка nfs проще.
> Но, если есть шанс, что к вам зайдет блондинка с ноутбуком (без
> админских прав на этот ноутбук), то... только CIFS.это к тому что nfs ядрёный а самба не очень?
если не секрет то какая будет разница?
> это к тому что nfs ядрёный а самба не очень?Да нет, про это не думал.
> если не секрет то какая будет разница?
Цифр не приведу.
Лениво бенчмарчать.
А вы сами можете посмотреть загрузку проца при 12 метрах в секунду через CIFS =)
Сдаётся мне, это несколько разные вещи NFS использовал дома, для nix-компов. Работает отлично, для системы полностью прозрачно - просто сетевые ресурсы, без особых настроек. Если в гетерогенной среде, то, конечно, самба.
Хотя, если это будет работать нормально...
Заставить ядро Linux брать корень по SAMBA и то проще чем вроде как более родной NFS... NFS - сложная неудобная штука ИМХО, реализация можети хорошая, но уинтерфейс запуска и настройки ужасен.
Что ??? Отсыпь конфигов.
Про тонкие клиенты на NFS слышал, про тонкие на TFTP слышал, а про тонкие на SAMBA это как-то толсто.
> Чо чо чо??? Отсыпь конфигов.
> Про тонкие клиенты на NFS слышал, про тонкие на TFTP слышал, а
> про тонкие на SAMBA это как-то толсто.чё? "Чо" -- по tftp kernel+initrd -- остальное по CIFS -- отсыпал, наелся?
>> Чо чо чо??? Отсыпь конфигов.
>> Про тонкие клиенты на NFS слышал, про тонкие на TFTP слышал, а
>> про тонкие на SAMBA это как-то толсто.
> чё? "Чо" -- по tftp kernel+initrd -- остальное по CIFS -- отсыпал,
> наелся?Вот это самое
> остальное по CIFSи интересует.
Я бы с радостью свалил с NFS, если бы была возможность загружать GNU/Linux с root over CIFS. Вас выше попросили поделиться конфигами. В ответ от вас какой-то троллинг, в связи с чем вопрос, Вы на практике это применяли, или так, теоретик?
>[оверквотинг удален]
>>> про тонкие на SAMBA это как-то толсто.
>> чё? "Чо" -- по tftp kernel+initrd -- остальное по CIFS -- отсыпал,
>> наелся?
> Вот это самое
>> остальное по CIFS
> и интересует.
> Я бы с радостью свалил с NFS, если бы была возможность загружать
> GNU/Linux с root over CIFS. Вас выше попросили поделиться конфигами. В
> ответ от вас какой-то троллинг, в связи с чем вопрос, Вы
> на практике это применяли, или так, теоретик?вас гуглом пользоваться научили или так, троллинг?
http://lmgtfy.com/?q=debian+live+net+cifs
--------
Today netboot supports both NFSv3 and Samba CIFS 3.0.23c+ as the root filesystem for the clients. Administrators may chroot in to the client environment and performs system related administration tasks to affect the client experience or may alternatively use some clever chroot+DISPLAY tricks to actually run the system customization tools like Kiosktool, Pessulus, Sabayon or Alacarte. The beauty of the live-initramfs system is that it turns a "normal" Debian init system in to a Live environment so no special care needs to be taken when upgrading client system services. Because of Linux disk caching, one server with a cheap CPU, 2 GB of RAM and 1 GB NIC card can serve 50 clients - that's a lot smaller than a typical server-side-computing-based thin client server.
--------
Аможно подробнее на тему "Заставить ядро Linux брать корень по SAMBA и то проще чем вроде как более родной NFS". Это как целую самбу запихать в initrd? И где тут проще если ядро умеет брать корень с NFS без танцев? И что самое главное в чем сложности? Я знаю одну почти не решаемую проблему для коня на NFS но она актуальна для специфичных случаев и держу парчи что вы с ними не сталкивались.
А я не очень понимаю: "безопасность" реализована не с помощью логинов/паролей, а с помощью uid/gid ?
Ага. Если я правильно понимаю, можно настроить аутентификацию через керберос, например. И пока не договоришься с керберосом, твой uid будет отображаться на nobody, грубо говоря.
NFS сильно круче первой самбы в плане оптимальности загрузки, которая с трудом работает на скоростях выше 100 мегабит - с NFS можно по гигабитному линку получать и запись, и чтение на уровне 90-110 мегабайт в секунду (я настраивал несколько таких конфигураций). SMB1 в таких условиях выдает скорости в несколько раз меньше - она почти не масштабируется дальше 20-30 мб/с из-за изначального проектирования под 10 Мбит сети, оверхеда, маленьких блоков и других проблем. Но вроде это исправлено в SMB2, но это требует клиентов не младше висты + непонятно какого сервера.
Имел как-то дома связанные гигабитным линком Windows XP + Solaris 10 + собранная руками Samba 3. До настройки размеров сетевых буферов и rfc1323 имел скорость чтения не больше 20 МБайт/с, после настройки скорость чтения повысилась до 79-83 МБайт/c. Замеры делал на больших файлах.
> Драйвер поддерживает работу в Windows Vista,
> Windows Server 2008 и более поздних версиях.То-то я думаю, чего он для ХР не собирается? Попутно вопрос - для Windows XP имеется клиент NFSv4 с поддержкой kerberos?
Хм, у меня дома что-то типа NAS на OpenSolaris + Гигабитный линк на рабочую станцию. Вполне себе выдавало 80-100 Мб/c на запись с Windows 7
по SMB с копированием прав 60-80 метров максимально у меня по SMB/ NFS от майкрософт. Но тут многое зависит от мусора в оперативной памяти.
2-а момента:
1. если действительно там осёл, то какой конкретно смб - самба или солярная смбшара?
2. смб1 или смб2? а то в самбе эксперементально смб2 только с 3.5 появилась.
без всех этих уточнений одни говорят про фому, другие про ерёму, а результат - "а у меня длиннее"
а лицензия какая?
> а лицензия какая?Обычная - мучайся сам, мы ни при чем.
А что, лицензия на ПО как-то связанна с поставляемыми вместе с ПО услугами?.. То есть когда Вы покупаете поддержку у Canonical у Вас какая-то отличная лицензия?
А теперь можно будет использовать NFS вместо CIFS для 1C8 в гетерогенной среде? Кто пробовал?
> А теперь можно будет использовать NFS вместо CIFS для 1C8 в гетерогенной
> среде? Кто пробовал?1с8 файловая это тот ещё изврат. В сущности какая разница как она файлы-то находит ?
Разница в том, что etersoft в документации на wine однозначно указывает на то, что работа в гетерогенной среде должна происходить ТОЛЬКО по cifs. У стандартного nfs client for windows от microsoft'a были какие-то проблеммы с блокировками.
> Разница в том, что etersoft в документации на wine однозначно указывает на
> то, что работа в гетерогенной среде должна происходить ТОЛЬКО по cifs.
> У стандартного nfs client for windows от microsoft'aбыли и всегда отстануться -- потому что так _нужно_
>какие-то проблеммы
> с блокировками.
То же интересен этот момент. Как там дела с блокировками обстоят?
Без поддержки перекодирования имён файлов в соответствии с локалью он не юзабелен :(
> Без поддержки перекодирования имён файлов в соответствии с локалью он не юзабелен
> :(Никакая перекодировки имён файлов не нужна. Мир давно на utf8.
Объясните это windows. Подсказка: windows использует UTF16
Некрасиво - согласен. Но чего же неюзабален? Или сейчас у кого-то в пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно, им utf-16 больше подходит
> пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно,
> им utf-16 больше подходитЭто ещё почему?
> Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character set
>> пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно,
>> им utf-16 больше подходит
> Это ещё почему?
>> Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character setпросто кто-то тупит и не понимает что uft-8 это по максимуму аж 6 баиииитов -- а туды все китайские и японские и какие хош можна
>>> пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно,
>>> им utf-16 больше подходит
>> Это ещё почему?
>>> Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character set
> просто кто-то тупит и не понимает что uft-8 это по максимуму аж
> 6 баиииитов -- а туды все китайские и японские и какие
> хош можнаНу да - только для иероглифов utf-16 компактнее, а utf-32 хорошо для интенсивной обработки
>uft-8 это по максимуму аж 6 баиииитовСам же и написал. Китайцам придётся по 6 байт на символ тратить вместо 2-х или 4-ёх.
>> пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно,
>> им utf-16 больше подходит
> Это ещё почему?
>> Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character setПотому что места меньше жрёт и меньше мороки с перекодированием в in-memory представление, если у тебя иероглифы
>>> пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно,
>>> им utf-16 больше подходит
>> Это ещё почему?
>>> Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character set
> Потому что места меньше жрёт и меньше мороки с перекодированием в in-memory
> представление, если у тебя иероглифывсё -- уговорил -- выбрасываю uft8 -- выпиливаю из браузеров и ставлю перекодировщик из utf8 в utf-16 для web -- будет очень эффективно -- особенно учитывая то, сколько текста написанного иероглифами я смогу осилить
оптимист учит английский
пессимист - китайский
реалист -- автомат калашникова
>[оверквотинг удален]
>>> Это ещё почему?
>>>> Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character set
>> Потому что места меньше жрёт и меньше мороки с перекодированием в in-memory
>> представление, если у тебя иероглифы
> всё -- уговорил -- выбрасываю uft8 -- выпиливаю из браузеров и ставлю
> перекодировщик из utf8 в utf-16 для web -- будет очень эффективно
> -- особенно учитывая то, сколько текста написанного иероглифами я смогу осилить
> оптимист учит английский
> пессимист - китайский
> реалист -- автомат калашниковаВот именно - для ВАС (как русскоязычного/англоязычного пользователя) utf-8 оптимален. Для пользующихся иероглифами - пригоден, но не оптимален. Если драйвер нацеливать в том числе и на азиатский сегмент - есть смысл добавить работу с кодировками. Плюс это в принципе хорошо - не зацикливаться на одной кодировке как едиственно верной.
Браузеры, кстати, поддерживают все варианты уникода - и не зря, так как в разных частях мира (и интернета) оптимальны разные кодировки.
> Вот именно - для ВАС (как русскоязычного/англоязычного пользователя) utf-8 оптимален.
> Для пользующихся иероглифами - пригоден, но не оптимален.Вы видимо просто ещё не поняли до конца, насколько это здорово, когда во всём мире - одна кодировка, способная передать текст на всех языках. Так вот - настолько, что нет никакого смысла гнаться за "оптимальностью", т.к. выигрывая в... (чём там? процентиках занимаемого текстом объёма на диске? используйте сжатие, диск не MFM на 20 мегабайт, и каналы не на 300 бод) сильно проигрываем в универсальности и совместимости всех со всеми.
>> Вот именно - для ВАС (как русскоязычного/англоязычного пользователя) utf-8 оптимален.
>> Для пользующихся иероглифами - пригоден, но не оптимален.
> Вы видимо просто ещё не поняли до конца, насколько это здорово, когда
> во всём мире - одна кодировка, способная передать текст на всех
> языках. Так вот - настолько, что нет никакого смысла гнаться за
> "оптимальностью", т.к. выигрывая в... (чём там? процентиках занимаемого текстом объёма
> на диске? используйте сжатие, диск не MFM на 20 мегабайт, и
> каналы не на 300 бод) сильно проигрываем в универсальности и совместимости
> всех со всеми.Это вы не поняли, насколько чревато молчаливо предполагать, что у всех всё одинаково сейчас и на вечные времена. Особенно если это даже текущему моменту не соотвествует. Ну вот реально сидят китайцы на UTF-16. И в винде реально UTF-16. И совершенно не факт, что завтра не будет придумано что-то ещё. Если есть несколько живых вариантов, то надо делать абстракцию, которая поддержит и их, и, возможно, что-то новое. То, как сейчас многие воспринимают UTF-8, напоминает попытки писать, скажем, только вод винду или только x86 - мол, всё равно она доминирует.
Что же касается кодировок - полагаю, через несколько лет дружно съедем на UTF-32, где никакой переменной длины нет - количество текста со временем особо не растёт, в отличие от объёмов памяти, а обрабатывать много удобнее.
> Что же касается кодировок - полагаю, через несколько лет дружно съедем на
> UTF-32, где никакой переменной длины нет - количество текста со временем
> особо не растёт, в отличие от объёмов памяти, а обрабатывать много
> удобнее.Не съедем, нету переменной длины - зато нету совместимости с ASCII (надо в /etc/somesoftware.conf прописать одной из констант значение в национальном алфавите, чего будете делать? весь файл в UTF-32 перегонять?), а также проблемы с определением LE оно или BE (таскаться с этими дурацкими BOM'ами всюду?), что "by design" беспроблемно в UTF-8.
>> Что же касается кодировок - полагаю, через несколько лет дружно съедем на
>> UTF-32, где никакой переменной длины нет - количество текста со временем
>> особо не растёт, в отличие от объёмов памяти, а обрабатывать много
>> удобнее.
> Не съедем, нету переменной длины - зато нету совместимости с ASCII (надо
> в /etc/somesoftware.conf прописать одной из констант значение в национальном алфавите,
> чего будете делать? весь файл в UTF-32 перегонять?), а также проблемы
> с определением LE оно или BE (таскаться с этими дурацкими BOM'ами
> всюду?), что "by design" беспроблемно в UTF-8.У utf-8 тоже совместимости нет для всего, что больше кода 127 - всё же как-то переехали. И в чём проблема весь файл перегнать, если места не жалко? (а на текст - не жалко, его сущие копейки по сравнению с мультимедиа). Насчёт endianness не скажу - не изучал вопрос, но учитывая, что распределена только малая часть 32-битного пространства, думаю, проблем с эвристикой быть не должно. Что-нибудь вроде "берём 4 байта и смотрим, с какой стороны у них нули". Да и BOM ничуть не более неудобная система, чем требование к текстовому файлу иметь в конце перевод строки. Определённо более удобно, чем перекодировка на вводе/выводе или переменная длина символов при обработке и связанная с ней возросшая сложность алгоритмов.
И, кстати, именно несколько представлений UTF никаких особых проблем не создают. Только необходимость с текстом тащить еще один атрибут - "кодировка". А при любых обработках всё равно есть смысл импортировать в UTF-32 и потом экспортировать в любую желаемую кодировку, что полностью прозрачно для внутренних алгоритмов, а затрагивает только чтение/запись.
enca спасёт отца русской демократии.
> enca спасёт отца русской демократии.Да причём здесь enca. Надо просто чётко понимать, что данных без метаданных не существует. разница только в том, зашитые метаданные жестко в программный код или тянутся вместе с данными и, соответственно, могут влиять на обработку данных. В частности - у текста существуют свойства "кодировка" (unicode, latin-1 или EBCDIC какой)и "представление" (вот здесь как раз utf-8, utf-16 и т.д.), часто - "язык", "mime-type" и т.д. И либо мы тащим вместе с текстом эту метаинформацию, либо определяем эвристически, либо честно говорим: "на входе предполагаю вот такое подмножество, на выходе отдаю вот такое". А считать, что у всех вокруг те же кодировки, языки и т.д. - это эгоцентризм пополам с кривым дизайном.
>А считать, что у всех вокруг те же кодировки, языки и т.д. - это эгоцентризм пополам с кривым дизайном.Зачем считать? Написать в спецификации, что текст должен быть представлен в UTF-8(любом другом юникоде) без бомов, ну и все остальное конкретно расписать, включая, endianess возвраты кареток и другие спецсимволы и эскейп последовательности. И внутри может быть все что угодно, пока все соблюдают спецификацию интерфейса.
>[оверквотинг удален]
> Да причём здесь enca. Надо просто чётко понимать, что данных без метаданных
> не существует. разница только в том, зашитые метаданные жестко в программный
> код или тянутся вместе с данными и, соответственно, могут влиять на
> обработку данных. В частности - у текста существуют свойства "кодировка" (unicode,
> latin-1 или EBCDIC какой)и "представление" (вот здесь как раз utf-8, utf-16
> и т.д.), часто - "язык", "mime-type" и т.д. И либо мы
> тащим вместе с текстом эту метаинформацию, либо определяем эвристически, либо честно
> говорим: "на входе предполагаю вот такое подмножество, на выходе отдаю вот
> такое". А считать, что у всех вокруг те же кодировки, языки
> и т.д. - это эгоцентризм пополам с кривым дизайном.ну правильно -- стандарты не нужны -- давайте придумывать колёса постоянно
--нет -- на самом деле то, что utf-8 плавает по длине и в этом ничего хорошего нет -- лично я согласен полностью -- только вот критикуя - предлагай -- и получается что альтернативные варианты (существующие) имеют свои приколы -- а шило на мыло менять, при том что не ясно что _на самом деле_ лучше.быстрее.оптимальнее обрабатывается смысла не имеет.
японо-китайского трафика я почему-то думаю много меньше чем всего остального текстового -- да и эта мета информация....ох -- ну не нужно из текста делать xml если есть более лёгкие пути
> Некрасиво - согласен. Но чего же неюзабален? Или сейчас у кого-то в
> пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно,
> им utf-16 больше подходитДа какая разница какая локаль у конкретного юзера на сервере? Общесистемной локали в *NIX'е нет, у каждого пользователя может быть своя кодировка, а open в *NIX'ах ничего никуда не перекодирует и соответственно как пользователь пишет, в такой кодировке и будут имена файлов. А в винде — вообще своя кодировка для UNICODE (UTF16) и что во что перекодировать?
>> Некрасиво - согласен. Но чего же неюзабален? Или сейчас у кого-то в
>> пределах досягаемости еще жива не-utf8 локаль? Хотя китайцам - да, неудобно,
>> им utf-16 больше подходит
> Да какая разница какая локаль у конкретного юзера на сервере?Вернитесь на 10 лет назад.
Когда была чехарда с кодировками страниц.
Русский apache не от хорошей жизни делался.
А лучше на 12.
Когда windows был non-utf.
И вы такое название файла могли получить... можно было тупо не смочь открыть файл.Вот тогда и узнаете, какая разница =)
utf все это сгладил.
Но, unix, как всегда не будет мешать вам, если вы решите прострелить себе ногу.
Или поставить себе веселую локаль.
Но может не стоит экспериментировать так жестко и остановиться на ноге? =)
Free NFS Client for windows 1.7 (Pure .NET, XP/2003/Vista/7 x64 compatible)