Tópico: Sobre Linux...

[Buckaroo Banzai]

multicd.tuxfamily.org

multicd.sh is a shell script designed to build a multiboot CD image containing many different Linux distributions and/or utilities.
The advantages to making a CD with this script are:

You don't need to burn multiple CDs for small distributions.

If you already have the ISO images, it is not necessary to download them again.

When a new version of one of the distributions is released, you can simply download the new version and run the script again to build a new multiboot image.



Acho especialmente bom para se ter coisas como o SystemRescueCD, parted magic e coisas parecidas sempre que sobrar espaço num CD ou DVD. Aí o CD/DVD continua com utilidade mesmo depois que a(s) distribuição(ões) estiver(em) um pouco datada(s).

[3libras]

é eu ainda tenho usado o dual boot com o seven e o ubuntu.

os dois são bem importantes pra mim, o seven roda jogos muito bem mas é meio pesado (não que seja um grande problema pro meu pc). já o ubuntu voa, mas infelizmente até hoje naõ achei como fazer ele reconhecer meu som como 5.1 e só posso usa-lo quando estou com headphones

uma coisa curiosa, aquele monte de atualização que exigia reiniciar, que era uma marca do windows no seven muito raramente acontece (para não dizer nunca, acho que só o daemon tools exigiu isso) no ubuntu tá cada vez mais frequente, além de por semana eu ter uqe baixar uns 80mb de update contra menos de 5 do seven.

[Fernando Silva]

uma coisa curiosa, aquele monte de atualização que exigia reiniciar, que era uma marca do windows no seven muito raramente acontece (para não dizer nunca, acho que só o daemon tools exigiu isso) no ubuntu tá cada vez mais frequente, além de por semana eu ter uqe baixar uns 80mb de update contra menos de 5 do seven.

Atualizações grandes que exigem reboot em geral são do kernel. Os aplicativos normalmente não exigem.

[3libras]

uma coisa curiosa, aquele monte de atualização que exigia reiniciar, que era uma marca do windows no seven muito raramente acontece (para não dizer nunca, acho que só o daemon tools exigiu isso) no ubuntu tá cada vez mais frequente, além de por semana eu ter uqe baixar uns 80mb de update contra menos de 5 do seven.

Atualizações grandes que exigem reboot em geral são do kernel. Os aplicativos normalmente não exigem.

Sim mas esse era um dos principais argumentos dos "windows haters". que eles usavam um sistema onde não precisavam reinicar pra fazer nada e o windows pra atualizar o java tinha que reiniciar. pra ver com o mundo muda rs.

[Fernando Silva]

uma coisa curiosa, aquele monte de atualização que exigia reiniciar, que era uma marca do windows no seven muito raramente acontece (para não dizer nunca, acho que só o daemon tools exigiu isso) no ubuntu tá cada vez mais frequente, além de por semana eu ter uqe baixar uns 80mb de update contra menos de 5 do seven.

Atualizações grandes que exigem reboot em geral são do kernel. Os aplicativos normalmente não exigem.

Sim mas esse era um dos principais argumentos dos "windows haters". que eles usavam um sistema onde não precisavam reinicar pra fazer nada e o windows pra atualizar o java tinha que reiniciar. pra ver com o mundo muda rs.

Sempre precisou reiniciar no caso do kernel. A diferença é que, antigamente, atualizar o kernel era um processo tão complicado que ninguém fazia. Hoje, vem misturado com as outras atualizações.

[Eremita]

...sou só eu que simplesmente tô cagando e andando pras atualizações do Ubuntu? Eu só atualizo uma vez: depois de instalar.
Especialmente do quernel, já que tenho compilado à mão e NÃO VOU COMPILAR OUTRO. Nem vou usar aquela lerdice que vem "de fábrica".
[Pros curiosos, é um Omnislash-5]

E quando eu instalar um Debian/kFreeBSD, atualização de quernel vai ser só uma a cada dez anos.

[Unsichtbar]

Estou com um notebook novo e uso Win7/Ubuntu em dual boot como o 3libras. Também acho inconveniente as atualizações frequentes no Ubuntu. E até o tamanho delas, além pacotes extras. Por ex., pra quem quer usar LaTeX são quase 800MB de pacotes para baixar.
Só estou com a minha placa de vídeo GeForce morta no Linux, os drivers disponíveis não funcionam.

[Fernando Silva]

Só estou com a minha placa de vídeo GeForce morta no Linux, os drivers disponíveis não funcionam.

O que veio na distribuição não funcionou comigo. Usei o arquivo .RUN baixado do site da Nvidia.
Só há um problema: na versão 10.10 do Kubuntu, a cada atualização do kernel, ele descarta o driver e é preciso instalar de novo na linha de comando (o X não entra). Espero que consertem isto na 11.04.

[Unsichtbar]

Pra mim nem os drivers oficiais da nVidia resolveram. Pesquisando descobri que meu notebook usa uma tecnologia nova, sem suporte para Linux pela nVidia, que usa GeForce e a placa de vídeo da Intel em conjunto. Por enquanto, só que o há é uma tentativa de criar algo opensource que suporte isso: Hybrid-Graphics-Linux

Só estou com a minha placa de vídeo GeForce morta no Linux, os drivers disponíveis não funcionam.

O que veio na distribuição não funcionou comigo. Usei o arquivo .RUN baixado do site da Nvidia.
Só há um problema: na versão 10.10 do Kubuntu, a cada atualização do kernel, ele descarta o driver e é preciso instalar de novo na linha de comando (o X não entra). Espero que consertem isto na 11.04.

[SnowRaptor]

Eu desisti da nVidia quando surgiu o suporte pra KMS pra ATi e Intel.

[Buckaroo Banzai]

Pergunta besta: com a apple abandonando o PPC e partindo para os PCs "normais", isso vai de alguma forma beneficiar colateralmente o linux? A proximidade dos sistemas poderia permitir rodar "mais nativamente" do que com WINE softwares proprietários do apple que não existem em linux, bem como usar drivers quando o hardware for o mesmo?

[SnowRaptor]

O hardware já é o mesmo.

E o que está acontecendo é de certa forma o oposto do que você falou. Como o OS X é UNIX, é trivial compialr um programa pra linux num Mac, então muito software livre já está saindo com versão pra linux e pra Mac.

Nunca vi ninguém reclamando que nãop conseguia rodar programa X de mac no Linux, principalmente porque quem roda programa de mac compra mac.

[Buckaroo Banzai]

Bem, isso talvez o contrário fosse até meio óbvio, uma vez que já existia linux para mac mesmo antes... ...mas e na direção oposta, a especificidade do programa ser compilado para mac/OSX já basta para inviabilizar que seja rodado em linux, sendo irrelevante que seja o mesmo hardware, ou existe a possibilidade de ser criada uma gambiarra meio como um "OS-XINE" mais eficiente que o WINE pela proximidade entre os sistemas?


Se houver essa chance, espero que a apple não incentive as companhias que desenvolvem a bolar qualquer tipo de "trava de software", uma tentativa de detectar se é mesmo OSX que tenta rodar o programa.

[SnowRaptor]

Só precisa traduzir as chamadas do kernel, que nem são tão diferentes assim, por causa do POSIX e colcoar as bibliotecas da apple, se não me engano.

[Buckaroo Banzai]

http://unix.stackexchange.com/questions/3322/what-makes-osx-programs-not-runnable-on-linux

[...]

The whole ABI is different, not just the binary format (Mach-O versus ELF) as sepp2k mentioned.

For example, while both Linux and Darwin/XNU (the kernel of OS X) use sc on PowerPC and int 0x80/sysenter/syscall on x86 for syscall entry, there's not much more in common from there on.

Darwin directs negative syscall numbers at the Mach microkernel and positive syscall numbers at the BSD monolithic kernel — see xnu/osfmk/mach/syscall_sw.h and xnu/bsd/kern/syscalls.master. Linux's syscall numbers vary by architecture — see linux/arch/powerpc/include/asm/unistd.h, linux/arch/x86/include/asm/unistd_32.h, and linux/arch/x86/include/asm/unistd_64.h — but are all nonnegative. So obviously syscall numbers, syscall arguments, and even which syscalls exist are different.

The standard C runtime libraries are different too; Darwin mostly inherits FreeBSD's libc, while Linux typically uses glibc (but there are alternatives, like eglibc and dietlibc and uclibc and Bionic).

Not to mention that the whole graphics stack is different; ignoring the whole Cocoa Objective-C libraries, GUI programs on OS X talk to WindowServer over Mach ports, while on Linux, GUI programs usually talk to the X server over UNIX domain sockets using the X11 protocol. Of course there are exceptions; you can run X on Darwin, and you can bypass X on Linux, but OS X applications definitely do not talk X.

Like Wine, if somebody put the work into

implementing a binary loader for Mach-O
trapping every XNU syscall and converting it to appropriate Linux syscalls
writing replacements for OS X libraries like CoreFoundation as needed
writing replacements for OS X services like WindowServer as needed
then running an OS X program "natively" on Linux could be possible. Years ago, Kyle Moffet did some work on the first item, creating a prototype binfmt_mach-o for Linux, but it was never completed, and I know of no other similar projects.

(In theory this is quite possible, and similar efforts have been done many times; in addition to Wine, Linux itself has support for running binaries from other UNIXes like HP-UX and Tru64, and the Glendix project aims to bring Plan 9 compatiblity to Linux.)

linkeditflag
edited Oct 21 '10 at 5:49

answered Oct 21 '10 at 5:44
ephemient

[Fernando Silva]

Draftsight
Programa de CAD para Linux, Windows e Mac OS X.

Testei no Linux e funcionou bem. Não faz desenhos 3D, mas abriu um que eu tinha.

Ele requer:

libdirectfb-extra >= 1.2.7.2
libxcb-render-util0 >= 0.3.6-1

mas elas estão no repertório do Ubuntu e instalaram na hora com o apt-get.

Free CAD software * for your DWG files: DraftSight - Dassault Systèmes

Free CAD software * for your DWG files: Your software. Your vision. Your community. A new 2D CAD product that provides professional CAD users, students and educators with a better way to read, write and share DWG files.

http://www.3ds.com/products/draftsight/free-cad-software/

[Unknown]

Hmm, isso muito me interessa.

[SnowRaptor]

Finalmente!

[uiliníli]

Vários programas científicos comerciais já têm versões para Linux, como Matlab, LabVIEW, Maple, Mathematica...
Acho que é questão de tempo até o AutoCAD e outros chegarem também.

Mas tem uma novidade sobre o AutoCAD no Linux para vocês: http://www.vivaolinux.com.br/topico/Multimidia/AutoCAD-no-Linux-Este-dia-chegou

[Fernando Silva]

Finalmente!

Há o VariCAD e o BricsCAD, mas são pagos.

[Fernando Silva]

http://www.guiadeti.com.br/anuario/fundacao.2006-06-22.6373580365/solucao.2006-06-23.9511201504/

http://brlcad.org/


BRL-CAD®

Sumário:

Sistema CAD avançado de modelagem sólida, desenvolvido pelo Laboratório de Pesquisas do Exército dos EUA.

Descrição:

O BRL-CAD® é um sistema CAD avançado de modelagem sólida que vem sendo desenvolvido desde 1979 pelo Laboratório de Pesquisa do Exército dos EUA (conhecido anteriormente por Laboratório de Pesquisas de Balística, no inglês Ballistic Research Laboratory, BRL). Atualmente, com mais de um milhão de linhas de código (em sua grande maioria na linguagem de programação C), o sistema dispõe, entre outros, dos seguintes recursos:

    Dois editores de formas geométricas interativos: MGED, o editor original, multiplataforma, e Archer o   
    novo editor, mais avançado e rico em recursos disponível atualmente (junho de 2006) apenas para
    Linux e Windows® (embora facilmente portável para outras arquiteturas);

    Biblioteca de ray tracing com suporte à renderização e à análise geométrica;
    Suporte a framebuffer distribuído em rede;
    Linguagem de script embarcada;
    Ferramentas de processamento de imagens e sinais,
    Grande número de utilitários de apoio.

O programa suporta uma variedade de representações geométricas, incluindo primitivas de geometria sólida combinatória tradicional (CSG), sólidos feitos de coleções fechadas de superfícies uniformes do tipo B-spline, bem como de superfícies NURBS, geometria facetada e geometria múltipla-de-n (NMG).


Modelo Comercial:

O software é livre e gratuito. Serviços, como consultoria, suporte e treinamento, são pagos.

[Vito]

Finalmente!

Há o VariCAD e o BricsCAD, mas são pagos.

Por mim não importa são pagos, o engenheiro está disposto para pagar o software muito bem documentado e funcional.

[Rhyan]

Por que é tão complicado instalar/desistalar um programa no Ubuntu? O Firefox 4.0 e o Chrome por ex.?

[uiliníli]

O jeito mais fácil é adicionando os repositórios do Mozilla ou do Google. O chato é achar esses endereços. Quando eu usava OpenSUSE eu achava mais fácil, os endereços dos repositórios mais importantes estavam todos no site oficial da distro.

Mas relaxa por enquanto, que daqui a uma semana sai a versão nova do Ubuntu e vai ser tudo atualizado.

[Buckaroo Banzai]

Você instala uma versão nova a cada release?

...

sobre a complicação... bem, me parece que quando não é mais simples do que o "padrão" (windows), instalar por apt-get/synaptic/etc, é igual: encontrar e baixar o programa. Desinstalar pode ser um pouco diferente, uma vez que no windows não costuma haver compilação, e menos comumente programas que se roda direto, sem instalar.

Nesses casos, eu prefiro deixar o programa dentro da minha pasta de usuário mesmo (/home/usuário/.opt em vez de /opt), só para não precisar usar como administrador para isso. No caso de ter que compilar, eu prefiro concluir com checkinstall, em vez do "make install", que cria e instala um pacote normal a partir do que foi compilado. Só pela conveniência de desinstalar com o synaptic quando for o caso, em vez de ter que ir ao diretório e mandar desinstalar.