El árbol completo con todo el código fuente, el código de prueba y todo lo que constituye el "código fuente de Windows" tiene más de medio terabyte de tamaño, en más de 4 millones de archivos. Asegura, por si lo anterior no fuese suficiente, que puedes pasar un año buscando en este árbol más de medio millón de carpetas que contienen el código de cada componente que constituye la estación de trabajo del sistema operativo, los productos de servidor y todas sus ediciones, herramientas y kits de desarrollo asociados, y ver lo que hay dentro.
|
etiquetas: microst , windows 10
Varios decenas de miles de personas pueden hacerlo gratis mejor que varios cientos de personas cobrando.
Y además, hay gente que programa para Linux a la que le pagan.
#5 Pues con la barbaridad de ficheros que son (4 millones), lo mismo si lo tienen en un disco cuyos ficheros se redondean a 4k se pueden ir facil como 60 gigas en espacio perdido.
Aunque prefiero el original, no voto duplicada por interesante y por si a alguien le apetece leer una traducción.
cc. #8
Si era sarcasmo, ya me voy solo a la fila de los Sheldoms...
Es Caos vs Orden.
Siempre sacan uno malo y otro bueno. Espero que windows 10 sea el malo.
El kernel más usado del mundo por amplísima diferencia respecto al segundo, presente en toda clase de dispositivos. Si se parasen todos los equipos que usan Linux la civilización actual colapsaría de un día para otro, y no es ninguna exageración, sería un auténtico desastre.
Pero hablando solo a nivel técnico, las cifras del kernel son también espectaculares:
www.phoronix.com/scan.php?page=news_item&px=Linux-EOY-2018-Kernel-
www.phoronix.com/scan.php?page=news_item&px=Linux-4.12-rc1-Git-Sta
Más de 26 millones de líneas de código repartidas en 62.000 ficheros, con un total de 17.000 contribuyentes en toda su historia.
Un poco de fuente generará un algo menos de objeto y un ejecutable mucho mayor pero, me imagino, que a partir de cierto tamaño de fuente la tendencia se invertirá porque se habrán linkado todo lo que hay que linkar.
La realidad es que en la última versión de Linux, Microsoft ni si quiera aparece entre las 20 primeras empresas que más contribuyen:
lwn.net/Articles/780271/
Y en la penúltima versión aparece en el puesto 20 por líneas de código:
lwn.net/Articles/775440/
Aquí puedes ver las estadísticas de todas las versiones:
kernelnewbies.org/DevelopmentStatistics
cc #5 #7
Mientras que por el monopolio de Microsoft son los fabricantes de hardware los que se adaptan a Windows, en el caso de Linux es justo al revés. Son los desarrolladores de Linux los que crean controladores para hardware muchas veces sin la colaboración de los fabricantes.
Windows, por contra, sólo tiene que establecer sus normas y los fabricantes las cumplen y desarrollan drivers para él.
No restemos mérito a quien lo tiene ni lo pongamos donde no lo hay.
Además no todas las contribuciones son en lineas de código, sino que pueden ser en dinero.
Por otro lado, es posible que su afirmación sea no de aportaciones de microsoft como empresa, sino de desarrolladores que trabajan para microsoft y que también trabajan en el kernel de linux de forma particular. (creo que también leí algo al respecto)
En cualquier caso no creo que sea un concurso de medirse las pollas a ver quien aporta más al kernel de linux, sino que es una tontería afirmar que windows es mejor porque al ser software privativo los trabajadores cobran dinero y por eso pueden hacer medio tera de código, que es lo que viene a decir el comentario que inicia el miniflame.
Es un tema que viene de muy lejos, una fakenews del 2009 que empezó el día que obligaron a Microsoft a aportar el código de Hyper-V al kernel Linux por haber incumplido la licencia GPL:
www.networkworld.com/article/2236556/microsoft-accused-of-being-in-vio
Y los medios comprados por Microsoft, o simplemente dirigidos por fans de la empresa, se apresuraron a manipular la situación, convirtiendo una mala noticia para Microsoft en una buena, diciendo que son los "mayores contribuyentes a Linux". Por ejemplo, esta noticia del NYT de las mismas fechas que tergiversa totalmente la realidad:
archive.nytimes.com/www.nytimes.com/external/idg/2009/07/20/20idg-micr
La parte real de la historia es que como se vieron obligados a aportar ese código de golpe, en total 22.000 líneas de código, en esa iteración del kernel pasaron a ser efímeramente los mayores contribuyentes del kernel. Y a partir de la tergiversación y manipulación de la noticia, en el colectivo de fanboys de Microsoft todavía perdura la creencia de que Microsoft es el mayor contribuyente, cuando ya han pasado 10 años desde eso. La prueba la tenemos en @Bumaro que sigue diciendo a día de hoy que Microsoft es quien más contribuye, con la única intención de medir pollas, a pesar de que lo que dice es totalmente falso como he demostrado en mi comentario anterior.
Microsoft contribuye al kernel, eso es innegable, y lo hace sin esconderse, ahí tienes el enlace a las estadísticas del kernel 4.19. Pero tú has dicho que es el que más contribuye, y eso es totalmente falso, por mucho que imagines o inventes con fantasías de empresas subsidiarias inexistentes.
W10 debe haber entrado hace mucho en la planicie de la desesperación, donde cualquier nueva línea de código para corregir un bug, se generan otros 3 bugs.
Ah bueno, y han liberado el fuente de calc.exe
La realidad es que GNU sin el kernel no sería nada más que cuatro paquetes de software que no usarían ni sus creadores, simplemente porque no habría donde usarlos.
En GNU adoptaron el kernel Linux porque eran incapaces de desarrollar uno propio por la complejidad del proyecto, hicieron un primer intento y fracasaron, y después lo volvieron a intentar desde cero con Hurd, el cual lleva casi 30 años en desarrollo y sigue sin estar listo para producción, según los mismos desarrolladores;
In 2010, after twenty years under development, Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems"
Y por último, le restas importancia a Linux porque la mayoría del código son drivers, cuando es obvio que es la parte más importante para que un kernel sea usable; es indispensable para hacer funcionar el hardware. Estás son las palabras de Stallman al respecto;
but added that "finishing it is not crucial" for the GNU system because a free kernel already existed (Linux), and completing Hurd would not address the main remaining problem for a free operating system: device support.
Resumiendo; eres más papista que el Papa.
Salu2
de mis clientes no lo ha podido instalar por problemas de compatibilidad con los discos duros, y tiene instalado el 7, que también funciona bastante bien.
Me encanta las ventanas en donde ves las aplicaciones que tienes abiertas al pasar el ratón sobre ellas y te permite ver el contenido directamente.
declare -x CFLAGS="-m64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O0 -g3 -ggdb3 -pipe -msse3
fnostrict-aliasingfnofast-mathfnoomit-frame-pointer"declare -x CXXFLAGS="-m64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O0 -g3 -ggdb3 -pipe -msse3
fnostrict-aliasingfnofast-mathfnoomit-frame-pointer"rwxrxr-x 1 aokromes aokromes 17M Apr 14 15:16 authserverrwxrxr-x 1 aokromes aokromes 24M Apr 14 15:16 bnetserverrwxrxr-x 1 aokromes aokromes 3.4M Sep 26 2018 mapextractorrwxrxr-x 1 aokromes aokromes 17M Sep 26 2018 mmaps_generatorrwxrxr-x 1 aokromes aokromes 8.2M Sep 26 2018 vmap4assemblerrwxrxr-x 1 aokromes aokromes 4.3M Sep 26 2018 vmap4extractorrwxrxr-x 1 aokromes aokromes 358M Apr 14 15:17 worldserverdu -h
56K ./server/ipc
48K ./server/game/Phasing
un largo etc....
29M .
directorio .git:
920M ./objects
922M .
Development on the Hurd began in 1990 after an abandoned kernel attempt in 1986, based on the research TRIX operating system developed by Professor Steve Ward and his group at MIT's Laboratory for Computer Science (LCS).[11]
Y en GNU adoptaron el kernel Linux porque ya existía, pero no dejaron ni han dejado de intentarlo con Hurd, que siempre fue su primera opción hasta que se dieron con la realidad en los morros; el desarrollo del kernel es la parte más compleja, y además sin drivers para hacerlo un funcionar, un kernel no sirve para nada. Que sigas negando esto demuestra que no tienes ni idea de informática, y que hablas desde el corazón, por no decir desde el estómago.
Después, aunque sea absurdo hacer suposiciones sobre lo que hubiese ocurrido, es lógico pensar que si no hubiesen existido las herramientas GNU se hubiesen usado otras o se hubiesen desarrollado desde cero. Porque al fin y al cabo son simples herramientas, que no tienen la más mínima dificultad comparado con la complejidad de un kernel.
Por último, decirte que el kernel sin contar los drivers sigue siendo un proyecto enorme en tamaño, ocupando millones de líneas de código. Aquí tienes las estadísticas del 2015:
unix.stackexchange.com/a/223763
Apple no usa Linux, sino FreeBSD
Estooooo... ¿Te suena Android? ¿Meego? ¿ChromeOS?
#80 El código fuente es expresivo, para que sea entendible por humanos. El binario son instrucciones, que tienen que ser entendidas por un ordenador. Habrá partes como el código enlazado que añadan mucho a un ejecutable, si hay que incluir esas librerías dentro del mismo, pero en programas grandes las librerías se comparten y ocupan espacio sólo una vez. A nivel de sólo código, también habrá partes que se expresen de forma resumida y el compilador lo extienda, pero lo normal es que simplemente quitando comentarios ( que en un código como Windows serán kilométricos ) y cambiando lo expresivo por funcional, se produzca una reducción considerable ( sin contar con el juego de caracteres unicode para el código y uno mucho más reducido para el binario ):
1) Fuente:
int SayThisIsMyClassyClassName::seeThisClassyMethodFreeSundaysAndBoobies( int MyVeryLongAndExpressiveParameter ) {
//a lot of expressive operations
return OtherVeryLongAndUnderstandableName::operateAndSayWhatYouDo( MyVeryLongAndExpressiveParameter );
}
2) Fuente para binario:
int _S::aa( int mm ){ return Q[z]::ow( mm ) ;
El código de ambos en modo texto sufre una reducción del 83%, si además añades que el primero es unicode o al menos UTF-8 (2,3 o 4 bytes por caracter ) y que el segundo es un juego de caracteres más reducido ( 2 bytes por caracter, seguramente ), tienes una reducción mayor.
Los compiladores, además, reescriben tu código si ven partes que pueden hacerse de una manera menos extendida o más óptima, reducen código redundante y además descartan partes que no se utilizan.
Si todos estos factores los multiplicas al nivel que estamos hablando, la reducción puede llegar a ser cercana al 95%.