Libertonia || Comments || Pingüinos en Wall Street


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Pingüinos en Wall Street | 30 comentarios (30 temáticos, editoriales, 0 ocultos)

un día frío en el infierno (3.66 / 3) (#13)
por preage a las Thu May 8th, 2003 at 01:25:35 AM CET
(Información Usuario) http://geocities.com/dariapra

Pero es que ademas, es multiplataforma. Imaginate que el proximo Office lo hacen con C# (o VB.NET o Java.NET o Cobol.NET) y los del corel sacan el framework para Linux (lo van a sacar) y los de Mono terminan tambien.

Tienes MsOffice en Linux.

Dudo mucho qye C# sea multiplataforma por dos motivos.

Uno es que Microsoft nunca ha tenido voluntad "multiplataforma". Su objetivo (es lo que le interesa comercialmente), es Windows everywhere. Y sobre arquitecturas x86; Alpha lo dejaron en cuanto pudieron.

El segundo motivo es que sólo un parte de C# es standard, en el sentido de que ha sido enviada al ECMA; precisamente esa parte es la que está implementando el proyecto Mono. Apostaría una buena suma de dinero a que la primera versión de Office que esté programada en la plataforma .NET utilizará APIs y características de C# que no han sido enviadas al ECMA.

Por último, ¿crees que Microsoft va a tirar piedras contra sus propios SO? A la secretaria que trabaja en la empresa X, los responsables de compras no le han comprado Windows para que trabaje, le han comprado Office y le han tenido que comprar el SO Windows porque Office sólo se ejecuta sobre Windows. ¿Crees que Microsoft hará una versión de Office para Linux porque a Microsoft le interesa dejar de ganar dinero vendiendo licencias de Windows 2000 o XP? Then, there will be a cold day in hell.

[ Padre ]

Para musg0 y preage (3.00 / 3) (#16)
por thuban a las Thu May 8th, 2003 at 10:00:34 AM CET
(Información Usuario)

Vamos a ver, a las empresas les da absolutamente igual cual sea el estado de salud de Linux o si el programa que usan tiene todo bien documentadito en RFCs o similares. Lo unico que les importa es poder leer el fichero que les manda el cliente por correo, y les da igual que el documento este en xml o en un formato propietario, o que el programa de correo lo mande todo en base64 o en base47, porque para ellas la informatica es un instrumento, no un fin.

Entre todas las alternativas que les permitan eso, eligen la mas barata y la que mas seguridad les va a dar a la larga. Si OpenOffice GARANTIZA que puede abrir TODOS los ficheros que le manden, usara OpenOffice, pero si hay un unico fichero que no puede abrir nadie se va a arriesgar a perder una venta por no pagar una licencia.

Yo no hablo de usuarios particulares, si no de empresas, que son las que pagan las licencias.

Y en cuanto a si C# puede ser un estandar, pues todo lo que digamos es especulacion y el amigo Gates podria mearse de risa con nosotros (si supiera que existimos), pero ¿por que no iba a pasar todas esas librerias a otros SO? Al fin y al cabo, estaran escritas en C y portarlas llevara su tiempo, pero un strcmp es un strcmp. ¿Que estan escritas con las MFC? Mas facil. Se portan las MFC y se recompila. Hay unas MFC para Mac y hay un Office y un IE para Mac, casualmente.

Microsoft vende software y SO, y si esta perdiendo el mercado de SO porque cada vez mas empresas se tiran por linux, intentara salvar al menos el mercado de aplicaciones. Aparte de que si C# le quita mercado a Java entrara muy fuerte en el mercado de servidores web=>SO de servidor.

No importa que las librerias no esten en el ECMA, porque no creo que las MESA o las QT esten. Solo importa que funcionen.

Y microsoft tiene la ventaja sobre los chicos de wine de no tener que hacer ingenieria inversa de windows.

¿Es esto malo para Linux? No. Tendra automaticamente mas aplicaciones y sera mas atractivo para las empresas, asi que se instalara mas. Pero muchas de esas aplicaciones seran de pago y tendran el codigo oculto, aunque tu puedas instalar las que prefieras. Es una cuestion filosofica.

[ Padre ]

Por fastidiar: sí, hay MFC para Mac (4.66 / 3) (#21)
por jorginius ("jorginius" en Google Mail) a las Thu May 8th, 2003 at 11:34:31 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

¿Que estan escritas con las MFC? Mas facil. Se portan las MFC y se recompila. Hay unas MFC para Mac y hay un Office y un IE para Mac, casualmente.

... Peeeero no son las MFC de Mac ni por asomo a como las de PC. Es un sub-sub-sub-conjunto de las MFC en realidad. Puede verlo consultando el código de las MFC (se incluye como herramienta de depuración en el VisualC++ y, según tenga el día Microsoft y del ServicePack, se permite la distribución de versiones binarias modificadas).

Sin OLE, sin WinSock, sin RichEdit, sin OCX, sin soporte para bases de datos, etc. Poco más que los controles básicos, los contenedores y algunas clases de utilidad. No es trivial portar una aplicación escrita con las MFC a Mac: hay que reescribir grandes porciones de código.

De hecho, aunque no tenga mucho que ver, ese subconjunto tambien compila contra Wine y así tener unas MFC nativas en Linux. Yo lo estuve mirando hace un par de años para compilar mis prácticas de "Programación Visual" (Programación con Visual C++ y MFC). No sé si lo que escribí por aquel entonces sigue teniendo vigencia o no (Wine avanza y los errores de bulto que vi en las MFC a lo mejor ya fueron arreglados), pero por si acaso, hay va un link.

... Y ya que lo mencionas, el caso del MS IE de Mac es aún más sangrante que el de las MFC. Prácticamente no comparte nada con el de PC salvo el nombre. Ni usan el mismo código, ni ha sido programado por las mismas personas. Del MS Office me faltan referencias, pero supongo que ocurrirá 3/4 de lo mismo.

Por otro lado, lo que dices sobre si Microsoft podría portar o no su framework a Linux...

Y en cuanto a si C# puede ser un estandar, pues todo lo que digamos es especulacion y el amigo Gates podria mearse de risa con nosotros (si supiera que existimos), pero ¿por que no iba a pasar todas esas librerias a otros SO?

Bueno, hay bastantes cosas que rechinan: sin pensar mucho, se me ocurre que en los Winforms uno tiene acceso directo al Handle (bajo nivel) de Windows (HWND) del control. Eso no pega ni con cola en un framework multiplataforma. Hay muchos más ejemplos... En realidad, la mayoría de las bibliotecas de Microsoft de .NET tienen pinta de no ser más que wrappers elaborados de apis de Windows, así que para portarlas casi tienes primero que portar el Windows entero :-).

Ojo, que la gente de Mono están trabajando duro para portarlo "todo" (Winforms y otras "winbibliotecas" incluidas) pero creo que al final para escribir con c# una aplicación multiplataforma, tendrás que tirar de gtk#, de qt# y de otras "gnubibliotecas#" (que existirán seguro, porque en c#, con PInvoke, esta chupado hacer wrappers de bibliotecas).

[ Padre ]

mcf#, gtk#, winforms (3.50 / 2) (#22)
por ridiculum a las Fri May 9th, 2003 at 01:59:42 AM CET
(Información Usuario)

Ahora mismo no recuerdo donde lo lei, quizas slashdot o quizas gnomedesktop, pero si recuerdo quien lo habia escrito: Icaza.

Preguntaban sobre cual era la mejor opcion para poder hacer GUI's multiplataformas usando C#. Yo pensaba que el API para hacer gui's en c# iba a ser comun a todas las plataformas asi que pensaba que seria winforms la respuesta, pero no. Icaza recomendaba gtk#. Por lo visto, winforms va via wine .

En la lista de mono-winforms tenemos un mensaje bastante interesante.

En la web de mono-winforms tenemos un resumen de los diversos API's que tenemos para poder hacer un GUI con c#

[ Padre ]

Puede ser dificil (3.00 / 1) (#23)
por thuban a las Fri May 9th, 2003 at 10:24:48 AM CET
(Información Usuario)

Pero con la cantidad de pasta que tiene microsoft puede contratar gente que haga todo ese esfuerzo.

Lo que desde luego no creo es que hayan montado todo este pollo (¿poyo?) del .NET para quedarse donde estan, sobre todo con la que se les viene encima.

A ver:
* empresas muy serias estan plantando (¡y recomendando!) linux en servidores. Ya no son unos hippies desarrapados que quieren cambiar el mundo con el software libre, si no que es IBM.

* empresas muy serias estan poniendo linux como cliente, como las de arriba, por ejemplo.

* el Java empuja muy fuerte en el servidor. El Coldfusion o el php en el fondo no son mas que anomalias de pocas empresas (cfm) o de los mismos hippies desarrapados de antes (php), pero los Servlets/JSPs son cosas que estan usando miles de empresas, entre ellas las mas grandes y las que mas invierten.

* el java empuja fuerte en el cliente, porque si antes era lento de angustia usar el JEdit, con los Pentium4 no se nota la diferencia con una aplicacion nativa (he pasado de un pentium a un pentium4 y os aseguro que esto pasa). ¿Y si alguien escribe un office en Java?

Microsoft no se juega solo el mercado de sistemas operativos, que es muy importante pero no el unico, es que se juega TODOS los mercados de software que tenga abiertos. No los perdera por completo, claro, pero si reducira su presencia y eso hara bajar sus acciones.

Por eso no creo que .NET sea algo solo para hacer bonito.

[ Padre ]

Cuidadín, cuidadín (4.00 / 1) (#24)
por melenas a las Fri May 9th, 2003 at 11:09:02 AM CET
(Información Usuario)

empresas muy serias estan plantando (¡y recomendando!) linux en servidores. Ya no son unos hippies desarrapados que quieren cambiar el mundo con el software libre, si no que es IBM.

Yo creo que el que IBM o Oracle recomienden Linux no es sólo por su mayor robustez, sino por miedo a Hasecorp.

Por ejemplo Oracle sabe que SQL-Server funcionará mejor que cualquier Oracle en un Hasefroch 2003 Server por muy buena que sea la versión de Oracle, por ello se alían con Red Hat Linux.

Así cualquier empresa que tenga productos Oracle si quiere seguir utilizándolo se pasará ya a Linux, evitando así que si utiliza Hasefroch, le venga un comercial de Hasecorp instándole a que cambie a SQL-Server.

De la otra forma también tendrían la competencia de otros gestores de BB.DD. libres, pero para eso tienen su ejército de comerciales que supongo no será tan amplio como el de Hasecorp.

Yo todo esto lo comparo con la 2ª Guerra Mundial, en el que Rusia, EE.UU e Inglaterra se aliaron contra Alemania. Inglaterra ¿Linux? estaba desde el principio y Rusia se metió sólo cuando le atacaron ¿Oracle?. EEUU se introdujo cuando vio que si el frente europeo caía se le podían poner las cosas muy feas ¿IBM?.

Ea, mi pequeña lección de historia de hoy ;-)

FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.
[ Padre ]

Vale (3.00 / 1) (#25)
por thuban a las Fri May 9th, 2003 at 12:01:07 PM CET
(Información Usuario)

Pero sea por lo que sea, el caso es que recomiendan Linux.

Y me cuesta imaginar a los chicos de Oracle siendo amiguitos de los chicos del DB2.

Creo que pesa mas en Oracle que ha invertido mucho en un Oracle con Java, y en IBM que su AIX no es precisamente la primera eleccion de alguien que quiere un sistema medio, y ahi esta el Linux, que le han hecho unos tios muy majetes que no le han cobrado nada.

Pero eso son divagaciones...

[ Padre ]

Sobre empresas y herramientas (4.00 / 3) (#18)
por Victor (victor@taquiones.net) a las Thu May 8th, 2003 at 11:10:46 AM CET
(Información Usuario) http://www.taquiones.net/victor.html

el fichero que les manda el cliente por correo, y les da igual que el documento este en xml o en un formato propietario, o que el programa de correo lo mande todo en base64 o en base47, porque para ellas la informatica es un instrumento, no un fin.

No puedo estar de acuerdo con el planteamiento; tengo alguna experiencia en empresas y herramientas, y puedo afirmar que, una vez, para salir del paso, es posible que no se tengan en cuenta esos detalles que citas. Desde luego, en cuanto se vislumbra la más mínima frecuencia en el hecho, cualquier empresario intentará obtener la herramienta más eficaz y más barata a la larga. Es más, si tienen una mínima experiencia con el tratamiento de datos, su principal preocupación será la de que éstos sobrevivan al tiempo y sean accesibles bastante después de su uso inicial.

Entre todas las alternativas que les permitan eso, eligen la mas barata y la que mas seguridad les va a dar a la larga. Si OpenOffice GARANTIZA que puede abrir TODOS los ficheros que le manden, usara OpenOffice, pero si hay un unico fichero que no puede abrir nadie se va a arriesgar a perder una venta por no pagar una licencia.

¿ Ves ? Parece que estamos de acuerdo. Sólo falta el pequeño detalle de que el principio en que te basas es erróneo. Si alguien acepta una garantía absoluta de un producto informático es un ignorante o un loco. Suponiendo que no se den estas circunstancias, queda el detalle de ver el planteamiento desde el otro punto de vista: ¿ puede garantizar Microsoft Office que abrirá todos los documentos de Word siempre ?

Ahora tratemos el segundo punto: arriesgarse a perder una venta. Una vez consultado mi sistema experto en comercio (mi señor padre, que sólo lleva 50 años trabajando en esto), he llegado a las siguientes conclusiones:

Un venta que dependa de condiciones tan extremas es rarísima, y la mayor parte de las veces, inabarcable.
Si es cuestión de invertir en una herramienta, se invierte, pero hacerlo para nada es tontería.

El ejemplo que me ha indicado mi fuente es el de hablar otro idioma. Si alguien quiere comprar uno de mis productos y el cliente sólo se comunica en un impecable alemán: ¿ qué hacemos ? Pues contratar una traducción de la comunicación, si no rebaja nuestro margen, ó contratar a un traductor si vemos que vamos a continuar el trato por mucho tiempo.

Pero si resulta que no es posible comunicarnos con el cliente correctamente: ¿ cómo podemos tener la seguridad de que el trato comercial llegará a buen puerto ?

Resumiendo. A lo que quiero llegar es a la conclusión de que el empresario (con un mínimo de valía, claro) no verá en absoluto ventajas en un trato que incremente mucho sus gastos, y en el que tenga que ceder en todo. A eso se le llama imposición, no negociación.
Victor Moral <victor@taquiones.net>
[ Padre ]

Re: Sobre empresas y herramientas (4.14 / 7) (#26)
por runlevel0 (exterATvullferPUNTes) a las Fri May 9th, 2003 at 09:19:32 PM CET
(Información Usuario) http://perso.wanadoo.es/exter

Y precisamente hablando de empresas alemanas. Estuve trabajando en una empresa de asesoría jurídica para alemanes hace un par de años. Recuerdo que la pincipal preocupación de mi jefe inmediato (que sí tenía bastante idea de informática) era que los documentos, estuvieran hechos con la versión que fuera de Office (y teníamos varias) siempre se guardaran en formato Office 6 u Office 97 a lo sumo. Resulta que es esa versión la que se lleva la parte del león en el mercado, dándose la paradoja de que es Hascorp haciendo la competencia a Hasecorp. Efectivamente eso pasa incluso al nivel de los SSOO, donde los NT4.0 aun siguen empleándose a despecho de los 2k y los X-Peses.
Lo mismo le está ocurriendo ya a Win2003-server, que tiene que competir en su propio mercado contra su propia compañía.
En el artículo de Heise se comenta la comparativa que se hace de W2003-server con el Red Hat Advanced SErver 2.4 (creo) sin actualizar y con Samba y se comenta cómo el primero escala muy bien con 32 CPU's etc, en los comentarios ya hay gente (usuarios de Hasfroch, por cierto) que argumentan que una gananacia de un 30 % en un caso tan extremo como el del test, si se reduce a 1 o 2 CPU's, que sería lo normal en el día a día, carece de significado. Además en un análisis TCO que enlazaba sinner también (RFG-LinuxTCO-vFINAL-Jul2002, buenísimo, me lo leí de un trago) hecho por encargo de IBM y en le que se ponen de manifiesto unos cuantos detalles:
Por un lado la escalabilidad horizontal un interesante concepto, que desconocía, y que significa ni más ni menos que la cantidad de máquinas monoprocesador que puedes acoplar a tu red de servidores y que en Linux no tiene límite fijado y debido a lo cual no hay competencia posible (Hascorp te hace pagar licencias por servidor), si te falta potencia, pones un par de servidores más y listo.
Efectivamente se supone que la elección del Server 2003 sería por motivos de TCO, ya que si lo que prima es principalmente la potencia y escalabilidad "vertical" (cantidad de procesadores por servidor) y el factor $$$$ no es importante, un Sun sobre UltarSPARC le da mil patadas a Win2003 sobre intel32.
Luego tenemos el hecho de que un admin que trabaje con Linux administra una media de 44 máquinas (según el informe RFG del enlace), mientras que un admin que trabaje con Hasefroch lo hará con unas 20 (creo recordad, no tengo el informe delante ahora mismo), así el montante del salario total es menor y también la cantidad de personal necesario.
En fin, a donde quería llegar: en cierto sentido Hasecorp ha hecho las cosas tan rematádemente bien en los tiempos en los que ha campado a sus anchas, que ahora se está encontrando con que en *su* terreno se hace la competencia a sí misma, mientras que en el mercado de los Unix sigue teniendo dificultades para entrar (se cae por su propio peso que una migración de Sun / SCO a Linux será por fureza menos onerosa que a Win2003-Server).

-- S41002
[ Padre ]

Samba vs w2003 (3.50 / 4) (#28)
por ochoto (ochoto_@_diariolinux.com) a las Sat May 10th, 2003 at 01:44:52 PM CET
(Información Usuario) http://diariolinux.com

Algo que no se comenta de esta comparativa es que el redhat server estaba usando interrupciones para gestionar las tarjetas de red Gigabit.

Esto que probablemente alguien le sonará raro no lo es si tenemos en cuenta que bajo mucha carga el coste de gestionar semejante cantidad de interrupciones puede bloquear la máquina simplemente atendiendolas [1] [2].

Es por esto que las buenas tarjetas gigabit tienen buffers internos para agrupar varios paquetes y generar una única interrupción.

En la comparativa no se quedan contentos con esto, sino que además usan el "cpu affinity" para intentar ligar las interrupciones de las tarjetas de red a cpu's diferentes.

Esto también es justo lo contrario de lo deseable, de hecho lo que suele hacerse es (siempre en el caso de que se usen irqs) hacer que las tarjetas compartan la irq de forma que una sola irq haga llamarse a las rutinas de gestion de todas las tarjetas en vez de requerir una irq por cada tarjeta. Por otro lado la afinidad es interesante para que una misma cpu siempre ejecute el mismo código, luego es mas efectivo que una cpu (siempre que pueda con la carga) despache las irqs ejecutando el código del driver de la tarjeta.

[1] http://marc.theaimsgroup.com/?l=zebra&m=104115501423784&w=2
[2] http://marc.theaimsgroup.com/?l=zebra&m=104118006402645&w=2

[ Padre ]

Hablas de cambios de versiones (3.00 / 2) (#27)
por thuban a las Sat May 10th, 2003 at 09:42:54 AM CET
(Información Usuario)

Y ese es un problema que tienen todas las empresas. No te puedes imaginar la de Oracles 7 que hay por ahi todavia, y Solaris viejos, o incluso Linux con el kernel 1... Hacer un cambio de version es un coñazo porque es casi, casi como instalar un sistema operativo/aplicacion nuevo (o peor, que si cambias por completo no tienes que pensar en parches y SPs) y las empresas de software lo evitan dejando de dar soporte (ya no hay soporte de W95, Oracle7, dentro de nada de NT...) para obligar a los clientes a actualizarse. Incluso a veces, un cambio de un producto obliga a cambiar a otro (A no soporta OracleX, asi que cambias, pero OracleX no funciona en SolarisY, asi que cambias a SolarisY++, cambian las librerias y tienes que actualizar MQSeriesZ, y etc, etc) La mas habitual (en pymes y empresas donde cada proyecto es independiente de los demas) es la escalabilidad horizontal, y ahi Linux es donde realmente pega bien, porque el lugar perfecto para el linux es el servidor y es virtualmente gratis, y la gente solo cambiara a windows si los chicos de microsoft dan un giro (tal vez el .net) que de unos beneficios que hagan olvidar el coste de licencias. El que lo tiene muy jodido es el unix de toda la vida, pero tu fiate de microsoft...

[ Padre ]

Formatos e imposiciones (3.60 / 5) (#20)
por musg0 a las Thu May 8th, 2003 at 03:41:19 PM CET
(Información Usuario) http://helvete.escomposlinux.org

Resumiendo. A lo que quiero llegar es a la conclusión de que el empresario (con un mínimo de valía, claro) no verá en absoluto ventajas en un trato que incremente mucho sus gastos, y en el que tenga que ceder en todo. A eso se le llama imposición, no negociación.

Puntualizo que las empresas poderosas pueden imponer sus estándares de comunicación a otras. Así, si te vas a cartear por email con telefónica y usas PGP Mime, y ellos no pueden leerlo en condiciones por usar Outlook, seguramente, por ser más pequeño tendrás que pasar por el aro y dejar de usarlo en vez de conseguir que ellos cambien de lector de correo por uno decente.

Seas cliente o proveedor casi siempre la empresa grande se come al chico. Así, si IBM y otras empresas grandes empieza a exigir formatos abiertos en sus comunicaciones con el resto de empresas, los días de intercambio de información en docs se acabarán, y si además, el Office no es capaz de ser eficiente con los formatos abiertos (El Office 2k crea unos HTMLs horribles) tenderá a usarse menos.

Usar formatos abiertos además es mejor para bajar los costes de comunicación ya que no dependes de un sólo proveedor y en teoría puedes usar el programa que mejor te venga para tus necesidades.

[ Padre ]

Pingüinos en Wall Street | 30 comentarios (30 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda