Em 2008, Linus Torvalds disse famosa em uma entrevista que "o OS X, de certa forma, é pior do que o Windows para programar. O sistema de arquivos deles é completo e uma porcaria total, o que é assustador". Procurei mais detalhes sobre por que ele se sente assim sobre o sistema de arquivos OS X (HFS + presumivelmente), mas não consegui encontrar nada.
Linus certamente não gosta do modelo básico de sistema de arquivos Unix, e duvido que ele odeie o HFS + por não fazer distinção entre maiúsculas e minúsculas. E, apesar de quão provocador é o seu comentário, duvido que seja completamente sem mérito. Como o comentário foi no contexto de programação do OS X, suspeito que sua opinião possa ter sido baseada em desempenho, robustez, interface do sistema operacional ou algo do tipo. Alguém sabe que reclamações a Linus da era de 2008 poderia ter tido com a HFS + da era de 2008?
fonte
Respostas:
Está disponível uma transcrição da sessão de perguntas e respostas na qual Linus fez o comentário , mas parece que ele não foi convidado a elaborar. Não tenho certeza se uma análise mais aprofundada de sua opinião sobre o HFS + foi anotada em outro lugar.
Para a análise de outra pessoa, você pode dar uma olhada nas revisões do Mac OS X de John Siracusa. Em particular a do Mac OS X Lion, que possui uma seção intitulada " O que há de errado com o HFS + ". Acho que o mais importante é (ênfase minha):
O ponto importante aqui é que o Mac OS X está usando um sistema de arquivos que nem foi projetado para um sistema Unix, foi projetado para o Mac OS clássico e corrigido para implementar os recursos do Mac OS X 10.0, mantendo a compatibilidade com versões anteriores. A Apple implementou posteriormente os recursos adicionais que agora possui no Mac OS X 10.7 (registro no diário, metadados, eventos do sistema de arquivos ...) usando a mesma abordagem de correção em vez de uma abordagem de "design desde o início". Não sei como explicar isso de maneira não técnica, mas você poderia dizer que todos esses recursos adicionais estão baseados em uma base clássica do Mac OS que nunca foi projetada para dar suporte a eles. Isso significa que a solução não é tão boa quanto poderia ser. O exemplo que Siracusa continua discutindo é que a solução que a Apple teve que usar para links físicos enquanto trabalhava dentro das limitações do HFS + é muito sensível a falhas de hardware, o que é agravado pelo fato de que o HFS + também nunca foi projetado para se preocupar com dados integridade. Obviamente, manter a compatibilidade com o Mac OS clássico era uma limitação desejável no Mac OS X 10.0, mas não existe mais no Mac OS X 10.7.
fonte
bswap
instrução x86 é muito rápida. Isso torna o código maior e mais feio, mas manter a compatibilidade no disco é um grande problema. O Linux XFS ainda armazena todos os metadados big endian (exceto endian nativo no diário), devido à sua origem no SGI nas CPUs MIPS. Não é uma situação ideal, mas o XFS não é retido por ele.Embora eu não seja um especialista em sistemas operacionais e comecei a usar o OSX depois de vir do Windows, considero-me um PowerUser no Windows e bastante competente no Linux. Vindo desse contexto, fiquei surpreso que, em um sistema operacional bastante moderno como o OSX, o sistema de arquivos tenha peculiaridades como a maneira como os nomes dos arquivos são "misturados".
Entendo que os problemas de Linus com o HFS + decorrem do mesmo ponto: pelo que encontrei pesquisando o problema, o HFS + armazena os nomes dos arquivos usando Unicode, mas quando um arquivo usa caracteres "estendidos" ou NÃO ASCII (como á, é, í, ó, ú, ñ do espanhol ou coisas como o ü em alemão), para o qual o Unicode fornece 2 maneiras de codificar o nome, o OSX silenciosamente "normaliza" a codificação no tempo de armazenamento ... Não é um problema real quando o O arquivo foi criado e consumido no OSX, mas quando você compartilha informações com usuários de outros sistemas operacionais, o fato de o nome do arquivo ser alterado gera todos os tipos de comportamentos estranhos ...
Caso em questão: tenho acompanhado meus "artefatos" de trabalho (arquivos, documentos, etc.) no Subversion nos últimos 8 anos. Ao migrar para o Mac, obtive o cliente SVN para Mac e, depois de fazer um checkout dos meus diretórios relevantes, descobri que todos os arquivos com sotaque parecem estar ausentes e um novo arquivo com o mesmo nome aparece sem versão. Indo além, o problema é que o arquivo IN do sistema de arquivos é codificado por apple, enquanto os dados no repositório usam outra codificação Unicode (perfeitamente válida e legítima) ...
Acho que isso é uma "manipulação" grosseira dos meus dados. A Apple entende os dois formatos da codificação de nome de arquivo (acessar um compartilhamento no Windows ou usar um pendrive no Windows mostra os nomes de arquivos adequados etc.), mas no momento da criação do arquivo, é decidido que "ele conhece melhor" e apenas renomeou os arquivos. ..
Novamente, não é algo que a maioria dos usuários notará - até fazer uma cópia de um arquivo ou renomeá-lo e colocá-lo de volta onde estava o original e acabar com dois arquivos aparentemente iguais !!!)
fonte
John Siracusa e Dan Benjamin discutem algumas desvantagens do HFS + no Hypercritical # 56 .
Eles abordam a corrupção de dados no HFS + e consideram alguns dos recursos do ZFS.
fonte