IBM crede in un Linux Desktop

x Luca69

caso a) Segretaria; la maggior parte delle segretarie
non conoscono nulla ne' di Windows ne' di Linux. Usano
Office come una macchina per scrivere e salvano
tutti i file in un'unica "cartella". Non vedo
la difficolta' nell'usare l'uno o l'altro sistema,
quando le applicazioni sono poche. E il piu'
delle volte quelle che si devono utilizzare lo sono
lo sono. Basta guardare i PC delle assicurazioni
o della PA e degli uffici e noterai che per la contabilita' e le pratiche usano ancora il vecchio programma Unix o VMS o Novell tramite un programma di accesso Terminale VT100. Tutto il resto serve per navigare e scaricare o ascaltore MP3...

b) manager. I manager dovrebbero pensare di piu' ai
bilanci invece di perdere tempo con inutili grafici
in powerpoint... (o OpenImpress).

c) Navigare in Internet: mozilla ha il motore HTML
piu' preciso che esista (e c'e' pure per Windows). I siti che si vedono solo in Internet Explorer
e non in Mozilla sono una minima minoranza. Per giunta
confronta un PC di un utente finale che naviga
con Linux e di uno che naviga con Windows: il secondo
sara' pieno di Spyware e Dialer... (non mi
dire che esistono protezioni perche' l'utente
finale non sa nulla di cio', forse conosce
al massimo il Norton Antivirus).
Casomai e' ancora un po' debole sui plugin, ma
solo quelli basati sui filmati QuickTime e WMF
specie quando usano le PlayList:
per il resto dei plugin: java c'e', flashplayer
c'e' (almeno per X86), realplayer c'e' (per X86),
PDF pure, etc.; i plugin mozplugger, mplayerplug-in e
mozplayerxp (basati su Mplayer) sono ancora un po'
acerbi.

<OT> Ho indicato quel link solo per dare conferma a affermazioni che altrimenti sarebero passate come "leggende metropolitane". Non ho mai avuto il piacere di provare BeOS, purtroppo.

x sensine.

> Questo si risolve banalmente (e alcuni produttori lo > fanno) compilando staticamente i programmi.

In teoria e' cosi', ma in pratica si hanno spesso
dei "side-effect". Inoltre non sempre e' possibile,
per questioni di license compilare INTERAMENTE
staticamente gli eseguibili.


> L'interfaccia con il kernel e con xfree è la
> stessa, sia usando un 2.2 che un 2.6 o un xfree
> 3.3 o 4.3, quindi il programma così distribuito
> funzionerà di sicuro sia sulla Redhat 5 che
> sulla Suse 9.

Non esattamente. Esistono le estensioni OpenGL, Xft,
DRI, etc., che sulle versioni precedenti non sono
presenti e anche da una versione all'altra
della serie 4 cambiano.

Inoltre una libreria non e' costituita dal solo
eseguibile .so precaricabile in LD_PRELOAD o
in LD_LIBRARY_PATH; ci sono anche tutta una serie
di altri file (che possono essere dati,
file di configurazione, etc.) a cui la libreria
vecchia deve accedere.

> Riguardo alla compatibilità delle libc, è un problema > che hanno quasi completamente risolto (rimangono dei > problemi per le librerie scritte in c++, a causa di
> alcune caratteristiche di questo linguaggio). Io
> stesso sto facendo un programma in c, sviluppandolo
> con glibc 2.3 e gcc 3.2, e lo eseguo su un computer
> con glibc più vecchie compilate con il gcc 2.96,
> senza alcun problema.

Prova a far funzionare un eseguibile mplayer compilato completamente STATICAMENTE su una glibc 2.2 su
un sistema che usa glibc 2.3.X e dimmi cosa ottieni...

Oppure prova a far funzionare UAE
o BasiliskII compilato (che
e' in C, non C++) su glibc 2.96 su sistemi con
glibc 2.3.X (anche portandoti dietro),
oppure ancora WordPerfect 8 (che usa il loader ld-linux 1.9), anche portandoti dietro tutte le librerie
di compatibilita'.

Oppure ancora fammi funzionare il plugin l'nppdf.so
di acrobat su un sistema con glibc 2.3.X (e' l'nppdf.so
e' un programmino di 50k in C, che non usa codice
o librerie C++).

Per non parlare delle rogne di Maple 8 con Java,
di Mathematica 5 con le LOCALEs, di Matlab
con i compilatori per le MEX, o delle rogne
che si avevano all'inizio in Oracle in tutte
le distribuzioni basate su threading NTPL.

> Perchè vengono programmati per Windows... pensa se
> fossero tutti come Ut2003 e altri giochi.. che hanno

considera che una grossa spinta proviene dalle
DirectX e il supporto dell'accelerazione fornita
dai driver proprietari. Laddove su Linux,
ci si ferma a una o due generazioni
di schede 3D precedenti sui driver free source,
e ci si deve accontentare di quelli proprietari
per le schede Nvidia e ATI dell'ultima generazione
(o di tentativi di patch per i driver Nvidia
se si vogliono usare su kernel 2.6...).

> anche il CD per l'installazione per LINUX che fine
> farebbe WINZOZ.

Chi era quella casa produttrice di giochi che
aveva in mente di produrre giochi non piu' per
Windows, ma per PC in stile Knoppix, dove
il gioco stesso avrebbe provveduto a riconoscere
l'hardware e a far partire la corretta
configurazione?

Re: x sensine.

Le questioni di licenze sono risolvibili.


L'applicazione non sa un tubo di dri o altre alchimie di visualizzazione. Usa gli STANDARD glx, OpenGL e altri (standard sanciti dal consorzio X, non da linux o xfree). Se una estensione non esiste in un particolare server (xfree e non solo), semplicemente non viene utilizzata o emulata in sw, e il programma funziona. Punto.


Una libreria non dovrebbe accedere a file di configurazione. In realtà quelle di linux non lo fanno, tranne rare, giustificate e standardizzate eccezioni.


mplayer come ben sai usa dei plugin che non sono compilabili staticamente.


A parte il fatto che non conosco questi programmi (io parlo solo per le mie esperienze), non credo che portare ad esempio il vetusto ld-linux 1.9 sia pertinente. In passato, in effetti, dei problemi c'erano.


E' codice c++, informati bene.

x ilsensine

Anch'io parlo per esperienze, pero' secondo me
non hai capito il codice ideale da quello reale.

Portare in esempio il ld-linux 1.9 invece ha
senso, perche' non e' piu' vecchio di 2 anni. Cio'
significa che il software proprietario piu' vecchio
di 2 anni, non lo puoi piu' usare o lo usi
in maniera instabile (oppure ti tieni la distro
vecchie di 2-3 anni, che su nel mondo Linux e'
preistoria e continui a usare il software
proprietario con quella).

Tra due anni ci potra' essere il loader ld-linux-3 che potra' dare gli stessi problemi. Quindi a me non frega
se le API o le ABI ci sono, ma non vengono
rispettate, poiche' e' la triste realta'. E'
spesso le case produttrici non sono nemmeno
lungimiranti da fornire delle semplici
ricompilazioni che risolverebbero tutti i problemi
in quattro e quattr'otto.
Quindi chi compra software Linux proprietario deve
sapere a cosa va incontro.

l'nppdf di acrobat 5.0.8 e' codice C, non C++:

ldd nppdf.so
libc.so.6 => /lib/i686/libc.so.6 (0x40045000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Re: x ilsensine

objdump -t nppdf.so | grep .cpp
00000000 l df *ABS* 00000000 NS_PDFX.cpp

ah comunque per prova ho appena scaricato questo plugin compilato più di un anno fa per la Madeinlinux con gcc 2.qualcosa, per mozilla 1.0, sulla mia Mandrake 9.1, gcc 3.2.2, Mozilla 1.3.1. Funziona

x ilsensine

Io non ho detto che nppdf.so non funziona
(tra l'altro proprio su Mandrake 9.1 o 9.2). Ho detto che funziona male, poiche' in tal caso il processo X quando il plugin entra in azione, assorbe il 100% della
CPU. Mentre non succede quando usato su distribuzioni
con glibc 2.2.5 (come potrebbe essere Mandrake 9.0).

Secondo me la gente si sta facendo troppe pippe mentali pensando a Linux, go buy windows

x ilsensine

Inoltre la questione "licenze" non e' facilmente risolvibile. Se il mio software proprietario
usa la libreria pincopallo e' questa e' GPL,
non posso che linkarla dinamicamente, a meno
di non rilasciare i sorgenti del mio software proprietario sotto la medesima (o compatibile)
licenza. E' la maggior parte dei produttori
di software proprietario non rilascerebbe i
sorgenti neppure di un software che
usa semplicemente "printf("Hello world!\n";"...