| Autor |
Mensagem |
|
|
victorcosta wrote:Liga para as pessoas que estão lhe desencorajando não. Tenta fazer mesmo, vc vai se divertir e aprender um bocado. Pode ser que o negócio tome forma e outras pessoas comecem a se interessar em ajudar também. O Linus quando começou o Linux não reuniu uma equipe do tamanho da Microsoft, ele foi lá e começou o projeto, hoje é o Linux que todo mundo conhece
Eu mesmo comecei a umas semanas atrás projetos "avançados" (IDEs, bancos, linguagens de programação, toolkits gráficos). To nem aí se acreditam que é impossível fazer, que to reinventando a roda. To me divertindo, aprendendo coisas novas e praticando arquitetura de softwares que fogem do padrão de sempre (MVC Web)
Vocês não tem noção do que estão falando. Primeiro que o Linus usou um kernel unix como modelo totalmente funcional, e contou com uma equipe grande de voluntários da usenet.
http://pt.wikipedia.org/wiki/Linux_(núcleo)
Comecem a desenvolver um software em assembly para microcontroladores simples como o 8051 e vão ver o parto que é ter que mapear toda a memória ram que se vai usar.
Além de só mapear 8 bits em área de memória na ram, para fazer cálulos com números maiores de 8 bits você precisa se desdobrar para fazer todo o mesmo cálculo nessa única área.
É tarefa árdua e não trivial como citaram mais acima.
Em um sistema operacional algoritmos complexos gerenciam processos para mantê-los organizados. Criar um sistema de arquivos para esses novos hds também é muito trabalho, e há dezenas de outros pontos de mesma ou maior complexidade.
Criar um bootloader não é complicado, e com ele você pode jogar um programa escrito em c ou outro compilador compatível com o processador que você tenha disponível. Agora desenvolver um "SO" é um trabalho completamente diferente do que alguns estão pensando.
não é questão de querer desanimar alguém, mas imagino que se possa aproveitar o tempo aprendendo os algoritmos usados nesse tipo de sistema do que tentar colocar uma máquina java em um kernel sem saber como tudo funciona primeiramente.
O artigo acima já é um bom ponto de partida.
|
 |
|
|
mcirqueira wrote:
luistiagos wrote:boa sorte... e não esqueça de passar seu projeto para seus filhos e dizer a eles passarem para seus netos quem sabe daqui a uns 200 anos seus tataranetos estarão finalizando o mesmo...
A esperança é a utima que morre...
Só não vou pegar o kernel do linux porque é quase um 500 MB, iria ficar pesado demais, acho que vou pegar o fonte do kernel do JNode e aí fica mais fácil e rápido.
Valeu galera!
Se eu terminar antes de 200 anos eu posto pra vocês verem como ficou...
De onde você tirou isso? Existem kernels linux que podem rodar em microcontroladores pic e ocupam menos de 50mb.
Esse é apenas um deles. Existem outros. As empresas utilizam linux em produtos embarcados porque possuem várias vantagens. Essa é uma delas.
http://www.minix3.org/
|
|
|
|
matheuslmota wrote:
juliocbq wrote:
Já pesquisou sobre a equipe por traz do jnode? http://www.jnode.org/node/48 Com certeza possui mais de uma pessoa que sabe com certeza o que está fazendo.
Estava vendo como é que eles comunicaram o Java com o Kernel, eles têm um compilador nativo que converte bytecodes pra linguagem de máquina. Nem sabia que tal compilador existia.
Existe o gcj do set da gnu que compila bytecode pra assembly.
http://gcc.gnu.org/java/
É muito mais prático pegar um kernel linux pronto e embarcar uma jvm como é mais ou menos o caso do android. Bootar um programa na memória ram é fácil e não tem nada a ver com sistemas operacionais. Para desenvolver um sistema desses precisa ter noção de escalonamento de processos, mapeamento de ram e flash, sistemas de arquivos e uma infinidade de outras coisas que um "sistema operacional" deve fazer.
Acho que é muita tarefa para apenas uma pessoa fazer.
|
|
|
|
Já pesquisou sobre a equipe por traz do jnode?
http://www.jnode.org/node/48
Com certeza possui mais de uma pessoa que sabe com certeza o que está fazendo.
|
|
|
|
Back Berry 10 suportará Framework Qt
http://www.theverge.com/2012/2/7/2781826/blackberry-playbook-now-supports-qt-in-bid-to-lure-disgruntled-nokia
http://www.xatakamovil.com/blackberry/blackberry-10-soportara-qt-desarrolladores-de-nokia-rim-os-tiende-la-mano
|
|
|
|
sozinho você iria levar no mínimo uns 100 anos para fazer isso. A equipe da microsoft no singularity é enorme, e o projeto tá na prancheta desde 2000. Para você ver como essa idéia não é muito viável.
http://research.microsoft.com/apps/pubs/default.aspx?id=52716
http://research.microsoft.com/en-us/projects/singularity/
Só diferenciando o android do singularity - O primeiro é um kernel escrito em linguagem c trocando mensagens com uma máquina virtual. O segundo é um kernel escrito em c#, onde até os módulos também são escritos nessa linguagem.
|
|
|
|
Não tem jeito por um simples motivo. Computadores de bordo não são sistemas operacionais, são máquinas de estado. Eles não executam nem gerenciam programas. É apenas um software embarcado.
No dia em que um computador de bordo começar a rodar linux ou win, symbian, android etc.. até pode ser. Mas por razões de segurança imagino que nenhum desses serão utilizados em setores automotivos(em computadores de bordo claro);
|
|
|
|
AbelBueno wrote:
juliocbq wrote:
Eles também precisam levar em questão a qualidade do compilador. Não creio que seja possível criar um bom compilador para assembly com uma linguagem inteiramente funcional. Seria talvez preciso uma gramatica muito extensa. Posso estar enganado.
Se não estou enganado Haskell pode ser chamado de puramente funcional e possui aparentemente um ótimo compilador.
Geralmente dizem que a performance é próxima a C++.
(Apesar da maioria das linguagens se dizerem próximas de C++).
Comparando o ghc(gnu haskell) com o gcc(gnu c), o código gerado pelo primeiro ainda está atrás do segundo.
Imagino que o g++ ainda consiga bater esses dois.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=gcc&lang2=ghc
Em árvores o compilador de c chega ser 4x melhor que o de haskell
binary-trees
C GNU gcc 13.09 5.44 150,720 850 94% 46% 66% 34%
Haskell GHC 67.80 21.30 781,940 612 73% 90% 84% 74%
Esses compiladores são os do set da gnu. Podem haver outros compiladores de haskell mais otimizados.
|
|
|
|
johnny quest wrote:
Engraçado, eu estava lendo sobre isso ontem a noite. Eu imagino que essas linguagens modernas serão um misto entre as duas, mas somente funcional creio que não.
A lâmbda simplifica por demais um bloco de código. A primeira vista pode parecer estranho mas é questão de costume.
Fiquei impressionado com o que dá para fazer com esse linq. Até comecei a estudar o Entity Framework.
Pelo grande avanço do conhecimento do paradigma OO, e por causa de muito código legado, pelo jeito as linguagens mais modernas serão hibridas mesmo.
Mas o que mais me impressinou no paradigma funcional, foi a forma elegante que foi resolvida o problema da execução de softwares em ambiente multithreads, sem precisar de Locks e jamais gerando dead locks ou race conditions. Com toda certeza essa seria uma feature que gostaria de ver no java.
Eles também precisam levar em questão a qualidade do compilador. Não creio que seja possível criar um bom compilador para assembly com uma linguagem inteiramente funcional. Seria talvez preciso uma gramatica muito extensa. Posso estar enganado.
|
|
|
|
ViniGodoy wrote:Um dos problemas é que geralmente quem não conhece usa um lambda como uma espécie de "inner class anônima fácil de digitar". Isso é tão verdade que parte da propaganda do lambda no Java (e no C++ também) é baseada exclusivamente nisso. E isso não é exatamente usar o paradigma funcional.
Já vi alguns códigos em LINQ que fazem um uso sério de lambda. Mas realmente, é muito legível para quem entende, mas pouco legível para quem não entende (a grande maioria dos programadores).
Engraçado, eu estava lendo sobre isso ontem a noite. Eu imagino que essas linguagens modernas serão um misto entre as duas, mas somente funcional creio que não.
A lâmbda simplifica por demais um bloco de código. A primeira vista pode parecer estranho mas é questão de costume.
Fiquei impressionado com o que dá para fazer com esse linq. Até comecei a estudar o Entity Framework.
|
|
|
|
edson25BA wrote:Rapz eu to trabalhando num projeto Android. Partindo das respostas que eu li aqui. Entao é possivel reutilizar uma DLL num projeto Android né?
Se tiver a mesma dll compilada para um ARM rodando linux funciona sim "entre aspas". O android não suporta jni mas pode usar o ndk para programar compilar as mesmas.
|
|
|
|
mauricioadl wrote:Obrigado!
Alguem pode ajudar?
O projeto do sharpdevelop anda meio parado. Aconselho você a usar o visual studio express.
|
|
|
|
XBRAVE wrote:É para Desktop. Sério cara, não compensa mesmo?? Na net vi muita coisa relacionado a PYTHON, C/C++. Nos arquivos do proprio opencv temos PATTERNS para C++. Embora todos estão rodando em Linux. O que me diz sobre Python? Mas sobre este erro:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\JavaTar\AppData\Local\Temp\jniopencv_core2314364841202532321.dll: Can't find dependent libraries
O que poderia estar fazendo?
Nunca usei opencv com python, então não sei dizer se é uma boa solução.
No próprio site da javacv eles dizem que o desempenho é muito aquém do que usar opencv diretamente.
http://code.google.com/p/javacv/wiki/SpeedComparisons
Se quiser usar uma linguagem mais moderna aconselho o c# e a biblioteca aforgenet( é escrita em c# mesmo). É tão boa quanto a opencv(em questão de recursos). Existem muitos artigos lá.
http://www.aforgenet.com/
|
|
|
|
cara, não faça essa misturança não. Seu projeto vai ter um runtime enorme(duas vms e dois mapeamentos para as dlls da opencv); Não compensa.
c# já não é suficiente para servidor ou desktop?
Se for somente para desktop faça em c++ mesmo.
|
|
|
|
Longino wrote:Olá,
Estou começando a aprender as plataformas da Apple e a minha dúvida é a seguinte: posso desenvolver em C++ tranquilamente ou precisarei usar Objective C caso deseje tirar o máximo proveito?
Não estava afim de ter que aprender Objective C, mas também não quero usar uma tecnologia que seja um "cidadão de segunda classe" na plataforma, assim como Java.
Pode usar c++ sem problemas com Qt. Aliás, sua aplicação será multiplataforma.
http://qt.nokia.com/downloads/sdk-mac-os-cpp-offline
http://qt.nokia.com/downloads
http://qt.nokia.com/
|
|
|
|