| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | mono (Pontos:2, Interessante) |
| | Ja estive a ler mtas coisas sobre o mono, e penso que, logo que o windows forms estiver completo vamos ver muitas aplicacoes de windows a correr em linux.
Pessoalmente, penso que se um dia o mono chegar ao ponto de correr aplicacoes graficas em linux e windows pelo mesmo executavel (ja nao falta mto... e falo dos windows forms... porque isto já é possivel com o gtk#) vai ganhar muita popularidade, pois acaba com o problema de escolher um GUI toolkit que seja portável e tenha um look nativo para ambos os sistemas operativos (sim, sim, temos o QT mas é C++ exclusive e o GTK é feio em windows e não é propriamente simples de compilar em windows)
Já não sei onde, mas li um artigo onde perguntavam se era apropriado usar .NET para fazer um jogo... a resposta foi que se o objectivo fôr fazer um Diablo ou NWN serve perfeitamente... mas qq coisa do estilo DOOM III, nem vale a pena tentar :)
|
| | | | | | Essa promessa me parece familiar... Já não ouvi isso antes sobre o Java ?
Me desculpem, mas não vejo nada demais no C# do ponto de vista tecnológico que o Java não tenha. Interpretadores de bytecodes são interessantes mas o problema é sempre o desempenho.
E C++ não é tão difícil assim para justificar uma linguagem completamente nova. Se queriam algo multiplataforma, que fizessem uma biblioteca semelhante à Qt.
Me parece mais uma forma da M$ de tirar qualquer esperança de adoção do Java.
|
| | | | Tenho 'trabalhado' e brincado com c# mal saiu a .NET beta, e com mono desde que foi anunciado publicamente e seguido todo o seu desenvolvimento e até bug catching.
Acontece que a grande diferença entre o Java e o C# básicamente resume-se a velocidade, ´e espantosamente mais rápido (sim tenho tido muito contacto com java) que java tanto em windows como em linux.
E para não falar que sendo eu um programador auto-didacta que tudo aquilo que aprendeu foi ah força da leitura e experimentação, C# aprendi num dia, java ainda tenho muitas dificuldades.
C++ parafraseando o autor do C++ 'Com C pode-se dar um tiro num pé, com C++ também, a diferença é que se fica sem a perna!'.
Por isso tenho que dar a mão a torcer que a m$ inovou desta vez e parabens ao Miguel pelo Mono.
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | | A frase do C++ e C não é bem assim. É mais do estilo: com o C passas a vida a dar tiros nos pés, com C++ quando o fazes, rebentas a perna toda. Quando ao C# como linguagem de programação é mais dificil de aprender que o java. O java é mais limpo. O C# tem mais "features builtin" o torna a linguagem mais complexa, pelo menos do ponto de vista semântico. Se tens dúvidas sobre este assunto, basta comprar uma gramática (yacc like por exemplo) que faça o parse de C# com uma de java. De notar que não me estou a pronunciar sobre a bondade de uma em relação à outra. Apenas java é mais simples.
-- carlos |
| | | | Apenas me posso pronunciar em relação á minha experiencia e conhecimento!
Há que notar aqui uma coisa, cada qual é como é, eu pessoalmente (volto a frisar _eu_) acho java asqueroso, sim prefiro mil vezes c++ a java, não só pela questão de desempenho mas acima de tudo por achar intragável programar em java, a sua semântica, etc etc etc.
Em relação ao C# aprendi em 3 tempos, muito mais facil a curva de aprendizagem.
Quem me digam assim, "pois o c# é mais facil devido aos ide's da m$ (vs .net)" acredito que sim acho que existe uma relação directa, acontece que em java nunca encontrei um ide, simples de desenvolver, (jah usei forte, netbeans jbuilder etc) mas chamem-me o que quiserem, nunca me dei bem com nenhum, acabando sempre por fazer as coisas á mão com o emacs como companheiro.
Mas como disse e volto a dizer, todas estas opiniões, não passam disso, são pessoais e intransmissiveis, e quem as tentar impor apenas se torna um fundamentalista (islamico?) ignorante.
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | | Acontece que a grande diferença entre o Java e o C# básicamente resume-se a velocidade, ´e espantosamente mais rápido (sim tenho tido muito contacto com java) que java tanto em windows como em linux. Olha, AFAIK, esta velocidade tem um custo... Enquanto em java o interpretador é paranóico com segurança, fazendo avaliações dos bytecodes à frente (para evitar jumps não autorizados - usados para "escapar" das zonas de segurança), no MSIL o código roda "solto". Com isto, seria possível contornar as autorizações de execução, viabilizando a construção de virus e trojans...
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | "Será que faria sentido lançar um pacote "PME Suite" com todas estas particularidades (ambiente de desenvolvimento .Net Framework, XPde como WM e um ERP à escolha do freguês), cujo público alvo fossem as PME's nacionais que tanto sofrem com as contenções de custos?"
Se se conseguir apresentar uma solução fechada, seja ela de CRM, ERP ou outra sigla qualquer, desde que esta apresente claramente vais vantagens e menos custos que as suas concorrentes, os clientes acabarão por aparecer.
O que é necessário é haver integradores de sistemas que levem estas soluções aos clientes, sejam capazes de as adaptar às necessidades dos clientes, capazes de as instalar e acima de tudo, capazes de as manter de forma transparente para o cliente. Este não se importa de passar o cheque, desde que não o venham depois chatear com problemas. A coisa tem é de funcionar...
Cumps,
Miguel Albano
If Spam was Money...then I'd be filthy Rich... But I'm not, so why try to sell me anything ?!? |
| | | | O XPde e o Mono ainda são bebés, mas não tenho qualquer dúvida que quando estiverem estáveis, serão autênticas pérolas deste mundo maravilhoso que é o Linux. O XPde é uma brincadeira à qual não vislumbro grande futuro. Quando se fazem cópias fieis do Windows corre-se um grande risco de desiludir o utilizador final. É que uma coisa são screenshots, outra é depois abrir um Gimp e deparar com um interface inconsistente, visualmente pouco apelativo e de discutível usabilidade. É preferível fazer como o KDE: vai beber inspiração no Windows, mas não é uma cópia. Quanto à portabilidade do código, o Qt é a melhor coisa que existe. Mete dó ver tantos programadores por aí enterrados no MFC sem terem ainda visto a luz. Enquanro que o Mono é uma esperança, o Qt é uma realidade. Está aí, disponível para fazer programas que correm em Windows, Linux, Mac OS X, Solaris, IRIX, etc. praticamente sem alterações.
|
| | | | | | Vou-te ser sincero, ainda só tive contacto com IDE de programação Microsoft (Visual Studio e Visual Studio .Net), já procurei algo parecido para linux, tanto para QT como para GTK, e até agora ainda não tive contacto que estive-se ao nivel do visual Studio da microsoft, a não ser o Netbeans mas isso é para programação Java. E este é um ponto chave para as software houses, porque elas querem uma ferramenta que ajude o programador e que lhes facilite toda a programação.
Eu não quero dizer que a linguagem QT ou GTK sejam mais dificeis porque com os exemplos que já estudei até as considero bem simples e mais claras, mesmo até que VB ou VC++ da Microsoft.
--------------------------------------------------
Todas as coisas mudam, e nós mudamos com elas. Biografia (esta in |
| | | | Realmente tens razão, mas as coisas estão a mudar, o qt designer está cada vez melhor e o kdeveloper com a ajuda do qt designer, o qt assistant e o qt translator tornam-se numa ferramenta bastante boa para programação em qt/kde. No Gnome existe o Glade que é também uma boa ferramenta, uma altura vi uma apresentação do PyGnome que usando o glade deu para ver o significado de RAD (rapid application development).
Link :http://www. ukuug.org/events/linux2001/papers/html/CEgli/Gnome-Talk.html
Não esquecer também o Kylix.
|
| | | | Kylix 3 [borland.com].
- Da' para fazer "tudo".
- A portabilidade fica-se por Linux e Windows (x86)
- Sim, tambem e' a pagar como os titulos que referiste.
- Sim, tambem o uso para desenvolver produtos que introduzo no mercado.
Cheers.
^S^ |
| | | | Bem este ainda nao testei, obrigado pela referência.
--------------------------------------------------
Todas as coisas mudam, e nós mudamos com elas. Biografia (esta in |
| | | | QT ?!
E já viram wxWindows !? http://www.wxwindows.org
Sim, ambiente gráfico igual ao windows em windows e linux!
Em C++ tenho algumas coisas feitas em wxWindows, com uma velocidade de desenvolvimento extremamente rápida!
Desempenho excepcional e ide's/helper's não faltam desde Dev-CPP ao wxDesigner e outros!
Sistema de design via XRC (XML Resources) com alterações do GUI em real-time etc etc.
Ah e LGPL, por isso volto a perguntar, QT ?
Quanto a IDE's para C# GPL, existe o SharpDeveloper, também bébé, já em fase em que se pode utilizar com alguns bugs que conhecidos facilmente se dão 'a volta'. Aqui fica! http://www.icsharpcode.net/OpenSource/SD/
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | Qt é mais sofisticado do que wxWindows.
Por exemplo, no wxWindows sempre que queres seres notificado de um evento despoletado num widget pelo utilizador, tens que derivar um nova classe a partir da classe do widget e fazer override de um método virtual nessa classe. À partida parece ser um método elegante, muito object-oriented. Só que não escala bem para programas com interface grandes e complexos. O programador vê-se na obrigação de derivar novas classes a toda a hora por eventos tão simples como um clique sobre um botão.
O Qt usa o mecanismo signal-and-slot que é mais escalável e permite mais facilmente utilizar componentes de um programa noutro.
|
| | | | Acredito, não trabalho com o QT unica e simplesmente pela licença...
Acontece também que aqui caimos numa das enormes vantagens do Opensource e software livre etc (whatever u would like to call) que é a liberdade de escolha e a variedade, quem tiver necessidade de construir uma aplicação com envergadura tal que o wxwindows atrapalhe mais o desenvolvimento (segundo a perspectiva de quem desenvolve e conhece ambas as tecnologias) nesse caso que use Qt, apenas evidenciei o wxWindows pr achar mto maturo, gostei mto da logica OO dele e facilmente desenvolvi com ele algumas coisas, agora não o usei para projectos com grande envergadura, dai não poder comprovar/argumentar este teu cometário, mas a intenção era mesmo, 'Oh jobe!! n existe só Qt tb há wxWindows com uma licença bem mais amigável!!'
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | | e até agora ainda não tive contacto que estive-se ao nivel do visual Studio da microsoft, a não ser o Netbeans mas isso é para programação Java Tens o eclipse. Pensado para java, mas genérico (existem plugins para várias coisas, incluindo C#). Qualidade IBM.
-- carlos
|
| | | | Tinha-me esquecido do eclipse, já o testei mas para java continua a preferir o NetBeans, são gostos. O que gostei mais no eclipse foi a sua leveza comparando com o NetBeans.
--------------------------------------------------
Todas as coisas mudam, e nós mudamos com elas. Biografia (esta in |
| | | | O XPde é uma brincadeira à qual não vislumbro grande futuro. Quando se fazem cópias fieis do Windows corre-se um grande risco de desiludir o utilizador final.
· Why do you think this project will be a success? KDE and Gnome are out there and also can be customized to look like Windows XP.
I don't know if it will be a success, but let's imagine this scenario:
-You are a Windows developer
-You develop an accounting, payment and desktop application for Windows
-You would love to develop for Linux, but you can't because none of your customers run Linux
-You could tell them, "hey!, I'm going to change all your machines to Linux, it's cheaper, faster and safer! (and all the Linux propaganda you can eat)"
-Your customers would say "Why? Our system works, we know how to print, send mail, create documents, copy files and all we need, we don't want to change, this will mean we need to teach all my employees the new stuff and I'm not going to lose that time!"
This is a common scenario in the real world of development. There is not enough time and money to forget Windows and install Linux, so this project is just another piece of software that could help to reduce the learning curve of a normal user to use a Linux computer. The main goal is to create an "exact" copy of the Windows XP interface (without any registered logos or graphics). That way, a plain user can start to use new applications (StarOffice, Mozilla, etc) without being frightened by a new desktop.
em portugues nao soa tao bem, "mas ele tem um ponto" e um bom "ponto" por sinal :\
Basta ver os mAcoianos que com o sex appeal do AQUA no macOSX usam uma mistela de freebsd com openstep, claro com os devidos ajustes, cocoa e toolkits derivados, mas vejam la se eles se queixam?
Mas gostei da ref ao xpde, projecto interessante :\
Make World; Not War; |
| | | | e pra quem sabe C e nao sabe C++ ?
|
| | | | O melhor mesmo é aprender C++ pois qualquer projecto de software moderno com alguma dimensão e credibilidade não é programador em C.
Se não gostar mesmo de C++, há o Java e o Object Pascal como alternativas.
|
| | | | | | "o XPde, e caso este WM vá avante, irá certamente contribuir para a mais rápida adaptação dos recursos de uma empresa que durante anos trabalharam com o Windows ao Linux, coisa que muitos administradores (de sistemas e não só) iriam agradecer devido à estabilidade reconhecida do sistema operativo e ao seu impacto no TCO." Depois de ter trabalhado como "helpdesk", pergunto-me, mas porque raio se continua a cair sempre no mesmo erro??? será que ainda não perceberam que a maior parte das pessoas não lhes interessa minimamente se estão a usar o m$-win5000 ou outra coisa qualquer, as pessoas que trabalham numa empresa querem é chegar lá de manhã dar um click no ícone da aplicação que usam na empresa, quer um processador de texto ou uma folha de cáclculo e PRINCIPALMENTE querem que lhes expliquem como cada uma destas coisas funciona, independentemente de ser da empresa x/y/z ou da toda poderosa m$. a maior parte das pessoas que hoje trabalham com um qualquer m$-win, não o sabem usar eu diria minimamente, quantas pessoas numa determinada empresa que tenham passado de um m$-win95 para m$-winXP sabem usar este último como deve de ser??? muito poucas, e menos ainda se ninguém lhes explicou, como é hábito por cá. será que ainda não se aperceberam que de cada vez que a m$ lança um SO, os utilizadores têm de passar por um novo período de aprendizagem como seria para qualquer outro SO, logo não nos devemos colocar na posição idiota de fazer aquilo que a m$ quer, mas sim desenvolver novos Desktops, OS's etc, e não copiar algo que já existe e que muito poucos John Doe's usam como deve de ser. Não nos podemos esquecer que é muito maior o nº de pessoas que ainda não entraram em contacto com nenhum computador do que o contrário, porque haveriam os developers ficarem agarrados aos utilizadores actuais, em vez de avançarem para os utilizadores do futuro, aqueles milhões e milhões que ainda nunca mexerem num computador?? filesystem, kerberos, extensões aos standards da www, formatos dos files (*.doc,*xls, etc), XML etc e tal que eu nem sei. mas será tb aqui possível que ainda hajam pessoas as achar que o .NET vai funcionar fora da plataforma m$???? mas porque raio acham que eles estão a desenvolver um novo filesystem baseado no m$-SQL-server??? porque raio estão eles a criar um Palladium??? mas será que ainda se deixam iludir pelas aldrabices habituais dos srs dessa empresa??? se calhar deverias ler estes artigos...micro$oft limits XML in Office 2003; At Microsoft's Mercy e este...2003 And Beyond "Microsoft is squeezing ever more revenue from current fully saturated markets by raising costs to their customers, mostly by changing licensing terms. This is creating resentment in formerly docile customers, many of whom consider the new terms extortion, and has them seriously looking at alternatives for the first time. It is also generating resistance to Microsoft's .NET initiative, now seen by many as a "vendor tie-in", ripe for exploitation." "The most important feature of Longhorn is replacement of the familiar DOS/Windows filesystem with an object database (W0). You will no longer copy files to a floppy or CD-ROM or attach them to an email, because there will be no files. Database records will be copied from one database to another, probably through a .NET server. Large organizations will have their own .NET servers, but everyone else will use one of Microsoft's, a service for which you will pay a fee." "The Longhorn filesystem will be based on the technology of a re-thought and expanded SQL Server database (the project coded Yukon) (W8). Obviously, SQL Server being so tightly integrated with the filesystem (W19) will have a negative impact on publishers of other database engines for Windows. Not strange then that market leaders Oracle and IBM are heavily pushing the Linux platform and barely mention their products run on Windows any more." "Given Microsoft's enthusiasm for "rich data formats", I expect Longhorn is going to eat disk space at an alarming rate. Perhaps this is why Microsoft has suddenly taken a strong interest in storage technology and services (W9). It's also going to be a major backup problem, so watch for Microsoft to start offering .NET backup services (for which you will pay a fee). Others already offer ASP backup service, but expect incompatibilities with them that "assure security and data integrity" (unless, of course, they pay a large license fee to Microsoft)." "I find it probable Longhorn will largely end the use of reliable, low cost servers (Linux, NetWare) for Windows users. This will set the stage for serious increases in licensing costs for already costly Windows server software."
|
| | | | | | Talvez seja só impressão minha mas um filesystem transformado em base de dados vai consumir toneladas de recursos desnecessáriamente. Gostaria só que me explicassem quais são as vantagens de fazer uma coisa destas... é que eu sinceramente não estou a ver nenhuma...
-- Carlos Rodrigues
|
| | | | Pesquisas mais rápidas? Ordenamento de ficheiros por parâmetros até agora impossíveis? Ok, talvez 90% dos utilizadores não necessitem deste tipo de "features", mas eu consigo pensar em pelo menos uma situação onde as pesquisas rápidas davam muito jeito.. Um web developer que tem umas centenas de ficheiros php/asp/jsp/whatever e quer saber onde raio colocou o ficheiro que tem aquela função que ia dar tanto jeito. Falando em windows (porque um grep que demore mais ou menos segundos para mim serve), acho que ia ter inúmeras vantagens.
|
| | | | | Talvez seja só impressão minha mas um filesystem transformado em base de dados vai consumir toneladas de recursos desnecessáriamente. Gostaria só que me explicassem quais são as vantagens de fazer uma coisa destas... é que eu sinceramente não estou a ver nenhuma... Falta de visao... pesquisas muito mais rapidas, ordenamento mais eficiente dos dados, consistencia de interfaces, sistema de ficheiros distribuido (a la NFS) por defeito, etc, etc, etc.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Pesquisas mais rápidas? Ordenamento de ficheiros por parâmetros até agora impossíveis? Ok, talvez 90% dos utilizadores não necessitem deste tipo de "features", mas eu consigo pensar em pelo menos uma situação onde as pesquisas rápidas davam muito jeito.. Um web developer que tem umas centenas de ficheiros php/asp/jsp/whatever e quer saber onde raio colocou o ficheiro que tem aquela função que ia dar tanto jeito. Falando em windows (porque um grep que demore mais ou menos segundos para mim serve), acho que ia ter inúmeras vantagens.
Falta de visao... pesquisas muito mais rapidas, ordenamento mais eficiente dos dados, consistencia de interfaces, sistema de ficheiros distribuido (a la NFS) por defeito, etc, etc, etc.
Para poder fazer pesquisas mais rápidas o sistema vai ter de indexar os "ficheiros" de alguma forma, e que forma será essa? A que parâmetros vai recorrer? Além de que vai ter de conhecer todos os formatos possíveis e imagináveis caso contrário olhará para eles como simples blobs binários e ficamos na mesma.
Por outro lado, isto vai consumir recursos 100% do tempo para poupar numa meia dúzia de ocasiões (eu por exemplo uso o search do Windows uma vez por mês se tanto), o que me leva a pensar que uma indexação específica de cada aplicação acaba por ser mais eficiente.
Usar uma base de dados como filesystem não passa de uma negação ao principio KISS com vantagens duvidosas que não irão muito para além das aplicações da própria Microsoft.
Mais grave é dificultar por várias ordens de grandeza a interoperabilidade com outros sistemas, mas é claro que isto é algo que interessa à MS.
Isto é equivalente a matar uma formiga com uma bomba atómica. É como se eu agora passasse a usar o Oracle para guardar a minha agenda telefónica...
-- Carlos Rodrigues
|
| | | | | Para poder fazer pesquisas mais rápidas o sistema vai ter de indexar os "ficheiros" de alguma forma, e que forma será essa? A que parâmetros vai recorrer? Além de que vai ter de conhecer todos os formatos possíveis e imagináveis caso contrário olhará para eles como simples blobs binários e ficamos na mesma. Bzzzt! Wrong! Se tens um backend que e' uma base de dados, podes imediatamente armazenar todo o tipo de informacao na altura de criacao de ficheiro que te permitem ajudar nesta indexacao -- quanto a tipos de ficheiros, nao estou a ver o que e' que o cu tem a ver com as calcas. Usar uma base de dados como filesystem não passa de uma negação ao principio KISS com vantagens duvidosas que não irão muito para além das aplicações da própria Microsoft. Bzzzt! Wrong again! Ou as da Oracle (iFS), ou da IBM (DataLinks), ou de virtualmente qualquer outro vendor de RDBMS que estao a fornecer esta funcionalidade com os seus produtos. Mais grave é dificultar por várias ordens de grandeza a interoperabilidade com outros sistemas, mas é claro que isto é algo que interessa à MS. Bzzzt! Wrong yet again! Parece-me ser mais interoperavel uma camada de acesso comum (SQL) do que uma infinidade de filesystems incompativeis e muitas vezes com filosofias completamente diferentes (ext2 vs NTFS por exemplo). O KISS e' um principio muito bonito, mas se o seguisses provavelmente aindas estavamos todos a correr Vic's, Tandem's, Apple's II e Sinclair's.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | | Parece-me ser mais interoperavel uma camada de acesso comum (SQL) do que uma infinidade de filesystems incompativeis e muitas vezes com filosofias completamente diferentes (ext2 vs NTFS por exemplo). Pelo que li na altura em que saiu a primeira beta do longhorn, e que foi quando ouvi falar no assunto, é algo mais do que isso. Os planos da M$ passavam na altura por integrar completamente a base de dados ao nível do file syatem, criando algo novo que traria inúmeras vantagens quando se usasse uma base de dados M$ (vá-se lá saber porque). Não li nada sobre planos de ter uma camada de abstracção que permitisse a manipulação do file system em algo tipo SQL ou de outra forma qualquer.
|
| | | | O KISS e' um principio muito bonito, mas se o seguisses provavelmente aindas estavamos todos a correr Vic's, Tandem's, Apple's II e Sinclair's.
KISS = Keep It Simple Stupid não Keep It Stupid Stupid...
-- Carlos Rodrigues
|
| | | | | O KISS e' um principio muito bonito, mas se o seguisses provavelmente aindas estavamos todos a correr Vic's, Tandem's, Apple's II e Sinclair's. Nada te impede de teres programas altamente sofisticados e completos, yet, KISS. KISS não é sinónimo de básico.
|
| | | | Boas.
"Bzzzt! Wrong yet again! Parece-me ser mais interoperavel uma camada de acesso comum (SQL) do que uma infinidade de filesystems incompativeis e muitas vezes com filosofias completamente diferentes (ext2 vs NTFS por exemplo)."
Até parece que a Microsoft não possui (e usa!) a sua própria visão "embraced e extended" do SQL...
@212, Nbk
|
| | | | | Até parece que a Microsoft não possui (e usa!) a sua própria visão "embraced e extended" do SQL... Da ultima vez que vi, o SQL Server suportava ANSI SQL 92 -- o mesmo que o Oracle, Sybase/Informix, PostgreSQL, MySQL, etc. Extensoes teem todos -- a Microsoft, a Oracle, a Sybase, e ate' o MySQL.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Da ultima vez que vi, o SQL Server suportava ANSI SQL 92
Nop, o SQL server suporta POUCO melhor o SQL 92 que o MySQL.
A impossibilidade de querys nos checks é especialmente irritante...
|
| | | | | Para poder fazer pesquisas mais rápidas o sistema vai ter de indexar os "ficheiros" de alguma forma, e que forma será essa? A que parâmetros vai recorrer? Além de que vai ter de conhecer todos os formatos possíveis e imagináveis caso contrário olhará para eles como simples blobs binários e ficamos na mesma. Isso é verdade caso convertas um file system. Na altura da criação a "BD" vai estar vazia e a criação de um documento novo será um simples "insert". Da mesma forma na cópia de vários ficheiros para o file system. Não prevejo grande overhead. em relação aos tipos de ficheiros, qual é o problema? Não é para isso que as bases de dados são boas? Qual é o problema de ter uma "tabela", se é que se pode falar em tabelas em file systems, com diversos tipos de ficheiros. O próprio windows já o faz de ao guardar a informação dos programas para abrir determinadas extensões. Por outro lado, isto vai consumir recursos 100% do tempo para poupar numa meia dúzia de ocasiões (eu por exemplo uso o search do Windows uma vez por mês se tanto), o que me leva a pensar que uma indexação específica de cada aplicação acaba por ser mais eficiente. Não. Pelas razões já apontadas acima e pela resposta do Leitão acho que é sensato concluir que caso isto seja como estamos a pensar, não trará grande peso adicional. A não ser que queiras fazer uma optimização por um determinado campo, mas isso o defrag tb demora eternidades. Usar uma base de dados como filesystem não passa de uma negação ao principio KISS com vantagens duvidosas que não irão muito para além das aplicações da própria Microsoft. Não me parece que seja uma negação ao principio KISS. estamos a falar em ordenar dados, não é mais simples ter uma base de dados do que ter outro sistema qualquer, esse sim possívelmente mais complicado? Quanto a não ir para além de aplicações da M$, sim, tens razão. E acho que vai ser sempre assim... Mais grave é dificultar por várias ordens de grandeza a interoperabilidade com outros sistemas, mas é claro que isto é algo que interessa à MS. Again, sim, é perfeitamente normal. Fez isso quando adoptou NTFS e vai continuar a fazer. É algo que já estou habituado e nem ligo Isto é equivalente a matar uma formiga com uma bomba atómica. É como se eu agora passasse a usar o Oracle para guardar a minha agenda telefónica... Se tens uma lista telefónica de vários milhoes de pessoas com várias centenas de campos por pessoa, é a melhor solução que podes adoptar. Não esquecer que este fils system é feito a pensar em servidores, não utilizadores normais. Pelo menos era o que diziam. É possível que não impessam o utilizador normal de usar este file system, mas as vantagens são bem maiores para outro tipo de usos.
|
| | | | Boas.
"Não me parece que seja uma negação ao principio KISS. estamos a falar em ordenar dados, não é mais simples ter uma base de dados do que ter outro sistema qualquer, esse sim possívelmente mais complicado?"
Sempre tive a sensação que no meu sistema de ficheiros a classificação/categorização seria mais importante que a ordenação.
[...]
"Se tens uma lista telefónica de vários milhoes de pessoas com várias centenas de campos por pessoa, é a melhor solução que podes adoptar."
Pois, realmente essa solução só vai interessar a uma pequena parte.
@215, Nbk
|
| | | | Bom, se já deste suporte helpdesk então o XPde será mesmo para ti :)
Eu cá em casa mudei recentemente o 2o computador de Windows para Linux, nem queiras saber as vezes que tenho de lá ir para explicar à Maria onde estão as coisas.
Instalei o SuSE com o KDE 3.1 e até é girinho e tal, mas por exemplo, no Windows tens o Start Menu e o Programas, no KDE tens o KMenu (ou lá como se chama) e depois tens as aplicações do KMenu (e as respectivas directorias) no menu principal. Se uma aplicação não estiver no KMenu então deve estar no SuSE menu. Toca de ir ver ao SuSE menu onde pára a aplicação. Pior é quando não está num nem noutro.
Aí acrescenta-se um icone no Desktop para executar a aplicação.
Ora, na rede cá de casa são só dois computadores. Fazer este tipo de costumização até nem é muito chato, só um bocadinho.
Fazer este tipo de costumização em 10 computadores já se torna realmente chato. Já nem falo do que será fazê-la em 50 ;)
Por exemplo: no suporte que dou aos clientes da empresa para a qual trabalho, já é um bocado confuso porque o meu Windows está em inglês e regra geral o do cliente está em Português. Explicar passo a passo como chegar a uma aplicação já é confuso q.b.
-"vá ao Start Menu/Programs/ etc etc etc." e ouves do outro lado "mas o meu Windows está em Português!" e começas a magicar... "Vá ao menú Iniciar/Programas/ etc etc etc.".
Imagina agora que tens uma aplicação para ambos os sistemas operativos, o pesadelo que será indicar à pessoa que está no outro lado da linha como executar a aplicação "xpto".
Eu pessoalmente acho que o XPde não tarda muito vai receber um apoio financeiro a sério de uma qualquer empresa (quiçá até de uma distribuição), porque NMO vai ajudar e em muito a que a transição de Windows (a pagantes) para o Linux (borlix) seja feita suavemente pelos utilizadores. É certo que ainda será necessária alguma formação, mas certamente que eles já não te irão fazer tantas perguntas por telefone como iriam fazer com um KDE ou um Gnome (eu prefiro o KDE :) ).
Sobre o .Net: a framework *funciona* fora do Windows :) Tens um port para o FreeBSD (se não estou em erro) que pasme-se foi iniciado pelo pessoal da MS mas depois largaram o projecto e outros pegaram nele. Já tens um port para MacOSX oficial. O port para Linux está a caminho pela mão da Mono.
Tal como o Java é um industry standard, o .Net também o será e muito provávelmente irá ocupar o lugar do Java, não por ser distintivamente melhor mas pelo simples facto de poderes acoplar qualquer linguagem à framework.
Passo a citar as que eu tenho conhecimento de que funcionam:
APL
COBOL
Component Pascal
Delta Forth
Ei ffel#
Fortran e Fortran 95
Haskell
Mercury
Mondrian
Oberon
Perl
Python
RPG
Scheme SmallTalk
Standard ML
TMT Pascal
NOTA: estes links foram retirados do livro .Net Framework Essentials, podem ou não funcionar. A estes ainda acrescento o seguinte:
Delphi
onde diz o seguinte:
"Delphi 7 delivers fully integrated technologies for increased productivity and equips developers for the path to Microsoft® .NET with the included Delphi 7 Studio migration kit."
Com tanto suporte assim acho que não se vai sair nada mal mesmo :)
Nada do que foi escrito deve ser levado em consideração... |
| | | | Onde se lê KMenu, deve ler-se Kicker :D
|
| | | | Eu pessoalmente acho que o XPde não tarda muito vai receber um apoio financeiro a sério de uma qualquer empresa (quiçá até de uma distribuição), porque NMO vai ajudar e em muito a que a transição de Windows (a pagantes) para o Linux (borlix) seja feita suavemente pelos utilizadores.
Esta ideia de facilitar a transição para o Linux copiando o Windows cheira mesmo mal. Se os utilizadores vão mudar para Linux podem aprender a trabalhar com este, caso contrário, o Windows é um melhor Windows que o Linux.
Sobre o .Net: a framework *funciona* fora do Windows :) Tens um port para o FreeBSD (se não estou em erro) que pasme-se foi iniciado pelo pessoal da MS mas depois largaram o projecto e outros pegaram nele. Já tens um port para MacOSX oficial. O port para Linux está a caminho pela mão da Mono.
Ter o core do .NET fora do Windows não é sinónimo de funcionar porque o core é apenas uma infinitésima parte de todo o .NET, o port para FreeBSD é um bom exemplo disto porque na prática não serve para absolutamente nada. O Mono é o único que parece caminhar para ser o primeiro a ser um verdadeiro .NET fora dos SOs da Microsoft.
Tal como o Java é um industry standard, o .Net também o será e muito provávelmente irá ocupar o lugar do Java, não por ser distintivamente melhor mas pelo simples facto de poderes acoplar qualquer linguagem à framework.
A velha conversa... Pode acoplar toda a linguagem que seja massajada para se assemelhar ao C#. E já agora observa esta lista de linguagens que correm sobre a Java Virtual Machine: http://grunge.cs.tu-berlin.de/ ~tolk/vmlanguages.html. Tens coisas como o Lisp, Prolog, ML, Smalltalk, Eifell, COBOL, Ada, Ruby, ...
-- Carlos Rodrigues
|
| | | | Se ainda nao o fizeste experimenta o mandrake 9.1, os menus estão muito bem organizados, infelizmente não tenho o suse e nao posso comparar mas desde há algum tempo que o uso e estou extremamente satisfeito. Essencial também visitar o PCLinuxOnline para veres os pacotes mais recentes e noticias geralmente relacionadas com o Linux como Desktop.
|
| | | | Boas.
"Fazer este tipo de costumização em 10 computadores já se torna realmente chato. Já nem falo do que será fazê-la em 50 ;)"
Primeiro pensa-se nas necessidades, cria-se uma versão alpha/beta da coisa, e depois é que se passa a produção.
Ou seja, se a coisa for bem "pensada" basta-te customizar 1 computador, e replicar pelos outros 9 ou 49.
@218, Nbk
|
| | | | | 1) a existência da abstração de alto nível numa linguagem com o C# irá libertar os recursos da programação difícil em C++ para a implementação de novas funcionalidades que de outra forma poderiam ser relegadas para segundo plano; Hammm??? Ja' ouviste falar numa coisa chamada J2EE ? Faz hoje o que o .NET fara' amanha... Duh!
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | | | O problema é que o J2EE na mm mákina que o .Net, so tem o trabalho feito depois de amanha, quando o .Net, no fim do dia de amanhã já o tem feito.
Como disse num comentário acima, C# é o mm conceito de Java sim, a diferença é que é _muito_ mais rápido. (nota, o muito sublinhado!!!)
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | | Existem aqui duas questões distintas. Uma é a diferença das arquitecturas, principalmente a nível do bytecode. Não conheço o suficiente do bytecode .NET para saber se intrinsecamente pode ter um limite teórico mais rápido de executar que java. É capaz de ter vantagem em alguns aspectos run-time, como alocação de memória (structs usam o stack). Outra questão é a qualidade dos interpretadores. O java (distribuido pela Sun) tem tido optimizadores/interpretadores de bytecode de qualidade not-so-good, mas têm estado a melhorar. A ultima versão (1.4.1 com .2 em beta) é tida como 2x mais rapida que a 1.3.1. Penso que dentro de pouco tempo os JIT compilers estarão evoluidos ao ponto de não se notar grandes diferenças entre java/C# e linguagens compiladas ao nível do código gerado. A diferença vai residir em aspectos intrinsecos às linguagens. Por exemplo, java nunca vai poder ser tão rápido como C por faz sempre array-bounding-check e aloca toda a memória da heap, mesmo que só precise localmente de um espaço com tamanho pre-determinado.
-- carlos |
| |
|
