Eu pretendia baixar o release preview antes de comprar, mas eu precisava da ajuda de alguém muito entendido do assunto. Pois meu note é um SOny Vaio, e ele tem aquela partição separada com o "CD" do windows e os drivers do note. Se eu isntalar o Windows 8 tenho medo de não conseguir dar recover por essa partição :/

É só durante a instalação ir nas opções avançadas e escolher a partição do Windows (é a maior). E mesmo se der galho, há vários programas para recuperar o acesso à partição. A partição de recover funciona independente do que acontece na outra.

Outra opção é instalar em uma máquina virtual (VirtualBox é free), e só substituir o 7 se/quando funcionarem os programas.

De fato o Ubuntu melhorou bastante o panorama, mas ainda é insuficiente. O problema é que os drivers que faltam são um parto de instalar, e nem sempre o método dos fóruns funciona. Aliás, eu não gosto do esquema de instalar coisas que não têm prontos na "loja" do Ubuntu. Apt-get, make install da vida, que baixa trocentas dependências e não costuma funcionar direito depois, fora quando não funciona justo na distribuição de Linux que você está usando. Pelo que você diz agora melhorou para nVidia, antes era um horror.
Outro ponto é a compatibilidade (ou existência) dos programas. Pra mim um essencial é o MATLAB, que tem uma versão livre mas é bem mais fraca.

Instalação de drivers também tende a ser problemático em Windows, e em qualquer Sistema Operacional (notória exceção do OS X e do Chrome OS, pois vêm em máquinas preparadas para recebê-los).

Se você precisa recorrer ao make, está fazendo algo errado. Geralmente o APT deve ser mais que o suficiente. Mas de qualquer forma, nunca mais vi necessidade verdadeira em usá-lo diretamente. Só o que não está na central de programas são drivers, que agora têm um programa de configuração em específico para gerenciar.

Quanto à "compatibilidade", você está encarando ao contrário: o Windows é que é do contra. Quase todos os sistemas operacionais seguem o padrão POSIX, o que inclui Linux, FreeBSD, netBSD, OpenBSD, Minix, Mac OS X, UNIX, Solaris, Open Solaris, GNU Hurd, entre outros. Quando você faz um programa para um, é mais tranquilo portar para outro.

O Windows e o DOS estão entre os únicos Sistemas Operacionais que não seguem esse padrão. Como eles são os que recebem mais atenção, os desenvolvedores focam esforços em fazer programas compatíveis com esse padrão proprietário que ninguém mais usa.

Por isso os programas que você quer não rodam. Não é o Linux que é incompatível com eles, é o Windows que monopoliza a compatibilidade.

Mas como, para o usuário médio, não adianta só buscar quais são as causas do problema, e mais as soluções, te sugiro manter-se com o Windows.

Aliás, melhorou a emulação do Office, ou ao menos a compatibilidade do LibreOffice? Tinha problemas com equações ao converter, e também na formatação em geral.

A Microsoft já disse que as versões novas do Office são compatíveis com ODF (que é um padrão aberto, então qualquer um pode fazer um programa que faça uso dele, inclusive a Microsoft). O LibreOffice e o OpenOffice fazem milagre para serem compatíveis com o formato do Office, que não é totalmente aberto. Se o Office não pode abrir ODF, reclame com a Microsoft.

Mas me atendo à pergunta: não tenho certeza, não uso nenhum dos dois. Uso emacs + LaTeX para edição de documentos e emacs para spreadsheets. Dizem que a compatibilidade do OpenOffice com relação ao formato Office é mais completa, mas o LibreOffice tem mais funcionalidades e é atualizado com mais frequência.

Citação de: VA em Outubro 23, 2012, 05:22:15 pm

Instalação de drivers também tende a ser problemático em Windows

Não.

Então eu sou a única pessoa aqui que já teve problema instalando driver em Windows? Teve um laptop que eu nunca consegui instalar o driver da ATI. E era Windows 7.

Ok, então vou citar problemas claros de driver encontrados em Windows que geralmente não se encontra em Linux:

Dispositivos antigos. Especialmente periféricos, como impressoras e scanners.

As fabricantes geralmente deixam de dar suporte a versões mais novas do Windows, e a Microsoft não tem poder sobre desenvolvimento de drivers.

O mesmo problema não acontece no Linux porque quando um driver funciona numa versão, vai funcionar para sempre a partir daí. Linus Torvalds NUNCA deixa alterarem as interfaces externas do kernel, então toda comunicação que um driver precisa, se funcionou um dia, vai continuar funcionando no futuro.

Qualquer usuário de Ubuntu ou outros Linux "prontos para uso" vão dizer que não têm trabalho com periféricos. É conectar a impressora e usar.

Eu gostava desse argumento uns 10 anos atrás. Hoje em dia, hardware está tão barato que tu abre uma caixa de cereal e vem um laptop dentro. Suporte a equipamentos obsoletos já deixou de ser um atrativo substancial há muito tempo.

E mesmo assim não é todo esse mar de rosas no Linux, não. Lembro que, quando a gente teve uma conversa semelhante a essa no chat, eu te passei um link de um cara que estava tentando instalar o Linux pra transformar o laptop velho e teve que desistir depois de uns 3 dias de sofrimento. Isso que ele era um usuário bem tech-savvy.

Isso me lembra da época em que eu estava tentando usar Debian num laptop bem velho. Não foi uma experiência boa, porque me foi recomendado usar xfce, que apesar de ser um desktop environment bem leve, é muito pesado em relação a windows managers puras.

Se eu tivesse passado pelo mesmo processo depois de conhecer o Arch Linux e windows managers acho que teria sido menos doloroso.

Mas acho que a discussão está se prolongando por demais. Acaba que é questão de costume, eu não domino nem um pouco o Windows, e sinto dificuldade com uma porção de coisas dele que pra outros usuários seriam normais, e por outro lado entendo bem a linha de comando do Linux (e quando não entendo, é só recorrer às man pages).

---

Oh, lembrei de uma coisa. Tem um motivo, sim, para o suporte ao hardware no Linux não ser tão bom quanto poderia (apesar de ser melhor do que geralmente é dito por aí). Não é nem mercado, nem qualidade de código.

É problema de licença.

Linux é GPL. Para fazer um driver para Linux, você precisaria linkar algumas bibliotecas dele. De acordo com a GPL, linkagem é derivação, e toda derivação deve ser, também, GPL. Então, de acordo com a GPL, todo driver para Linux deveria ser GPL.

Para evitar isso, o Torvalds fez com que algumas chamadas de funções NÃO fossem cobertas pela GPL. Então você poderia fazer essas chamadas no driver e ter uma licença própria (é o que toda empresa que faz driver fechado faz, inclusive a NVidia).

Isso até deu problemas um dia desses. A NVidia precisava de uma chamada de função GPL para o seu driver, e pediu para a Linux Foundation tirar essa função da GPL, para que o driver continuasse fechado. A Linux Foundation se manifestou dizendo que o código é de seus respectivos autores (como a própria GPL deixa claro), então para poder fazer isso, a NVidia deveria ter permissão dos autores.

Os autores não concordaram, claro. Essa confusão ainda vai se manter por um tempinho antes de chegarem a uma conclusão.

Programas feitos em Java misteriosamente rodam muito mal em sistemas base Unix.

Talvez você tivesse OpenJDK no unix e Oracle Java no Windows. OpenJDK é bom para casos específicos (desenvolvimento de android), mas geralmente o Oracle Java é melhor.

Não que eu queria insinuar que Java seja bom, claro...

Mas não me chama de usuário médio não... Preguiçoso eu aceito haha.

Não estava me referindo especificamente a você. Apesar de dar vontade de mostrar coisas que só são possíveis em linha de comando.

E porque não é?
Não quero desvirtuar o tópico demais, mas isso é do meu interesse, já que estou começando programar em Java e não tenho muito conhecimento de suas deficiências... (sei que fica bem mais pesado que a mesma  coisa em C, mas estou achando muito mais agradável de programar nele)

Java é bom, especialmente no meio comercial, eu é que tenho um ranço forte com a linguagem:

1 - Ela é uma chupadora de memória. Não sei se é problema do Garbage Collector, mas a memória ocupada por um programa Java é muito grande.

2 - A linguagem tem poucas funcionalidades que tornam o código mais flexível. É uma linguagem muito "dura". Funções anônimas (que podem ser "emuladas" com classes anônimas, mas não é a mesma coisa) é o melhor exemplo pra mim. Pra uma comparação justa, procure funcionalidades que existem no C# mas não no Java.

3 - É bem burocrática. Por exemplo, uma função para pegar os bytes de um arquivo em Java:
public static byte[] getBytesFromFile(File file) throws IOException {
    InputStream is = new FileInputStream(file);

    long length = file.length();

    // You cannot create an array using a long type.
    // It needs to be an int type.
    // Before converting to an int type, check
    // to ensure that file is not larger than Integer.MAX_VALUE.
    if (length > Integer.MAX_VALUE) {
        // File is too large
    }

    byte[] bytes = new byte[(int)length];

    int offset = 0;
    int numRead = 0;
    while (offset < bytes.length
           && (numRead=is.read(bytes, offset, bytes.length-offset)) >= 0) {
        offset += numRead;
    }

    if (offset < bytes.length) {
        throw new IOException("Could not completely read file "+file.getName());
    }

    is.close();
    return bytes;
}
A mesma função em Ruby:
class File
  def get_bytes
    bytes = []
    self.each_byte { |b| bytes << b }
    return bytes
  end
end
(No Ruby eu estou adicionando o método à própria classe File, porque as classes em Ruby são abertas e podem ser modificadas em tempo de execução).

4 - É difícil programar em Java sem o auxílio de uma IDE (como Eclipse). Eu não gosto de IDE's, prefiro emacs.

Tem outros motivos menores, mas em resumo é isso.