Android non è adatto al mercato enterprise?

[iocci]

Originariamente inviato da Barra

Una distro di 7 anni fa ha upgrade costanti e gratuiti. Gli applicativi sono di norma ricompilati x queste distro e non ho presenti grosse eccezioni. Se usi un sistema per lavoro ti prendi una distro con un lungo supporto tecnico (hardy 8.04 ha 5 anni di supporto, centos 7) e stai tranquillo che non ci sono cambio di librerie!

L'unica distro che ha un supporto di 7 anni è REHL/CentOS, ed è un caso limite visto che è l'unica con un supporto cosi lungo.
Ora prova a scaricarti una distro del 2001 e prova ad aggiornarla, a installare qualche programma recente, e vedere cosa riesci a combinare.
Io ce li ho qua CD di distro del 2001 e so che sono del tutto inutilizzabili, mentre XP che è uscito nel 2001 è ancora supportato e lo sara fino al 2014 e i vecchi programmi funzionano benissimo.

Se voglio installare un programma nuovo su una distro con piu di qualche anno di sicuro ho una valanga di problemi dovuti al fatto che nei repository non ci sono le dipendenze necessarie, non è presente una versione sufficientemente aggiornata, vengono usati componenti obsoleti che non sono piu utilizzati nelle distro moderne, usa file di configurazione con sintassi vecchie e altri mille impicci.

Non si tratta che su Windows è piu facile, ma si tratta del fatto che non ti devi preoccupare della distro che ogni 12 mesi in genere diventa obsoleta e non piu aggiornata, non ti devi preoccupare perche l'exe è uno solo e non ci sono diversi pacchetti per ogni distro, e con 1 click hai il pacchetto installato.
Installare un deb nuovo che richiede dipendenza X che la distro non ha succede molto spesso e NON è affatto semplice il proseguimento.

Originariamente inviato da Barra

? sviluppare in python un applicativo e renderlo compatibile con tutte le distro è difficile? mi risulta il contrario..... Per la compatibilità su windows posso farti parlare con vari clienti che hanno gestionali fatti su misura. O sono incapaci quelli che sviluppano software a Modena (e può essere, ho conosciuto un paio di loro e non mi sono sembrati particolarmente svegli) o non è tutto così rose e fiori....

Non c'entra il linguaggio, il fatto è che le distro usano path e directory diverse, su alcune distro sono presenti delle librerie e su altre no, oppure le versioni disponibili non sono compatibili, ci sono metodi di autenticazioni diversi, i pacchetti nelle varie distro sono compilati con dipendenze diverse e con flag diversi, i servizi hanno nomi e funzionalita diverse, bisogna creare un pacchetto per ogni distro e tenere aggiornate le dipendenze nel tempo, e molte altre differenze che si devono gestire a mano.
Su Windows tutti questi problemi non ci sono, devo supportare solo un'unica piattaforma che resta stabile e immutata. Le API di Win32 è da una vita che sono quelle...

Originariamente inviato da Barra

Beh insomma office 97 su vista non fa, il 2000 necessita 200mb di patch e stessa cosa il 2003 se non vuoi crash ogni 2 secondi (sperimentato questa settimana da un mio cliente). La presunta compatibilità binaria è una fantasia! Prendi nero 6 e provalo su vista!

Un software scritto per Windows XP mi gira tutt'oggi su Windows XP, e Windows XP sara supportato con aggiornamenti di sicurezza fino al 2014.
Nessuna distro Linux offre una durabilita cosi elevata. Se mi faccio fare un programma per Vista adesso so che fra dieci anni Vista sara ancora supportato e la mia applicazione funzionera ancora, mentre con Linux fra tre anni il programma non funzionera piu con le distro che ci saranno fra tre anni e allora o mi tengo una distro che è diventata obsoleta o me lo faccio rifare.

Originariamente inviato da leptone

Come al solito girano un sacco di inesattezze. Io non sono un programmattore ma almeno conosco cose minime e basilari dell'informatica.
Su diverse distro Linux, per far andare un programma qualsiasi basta solo ricomplilarlo, e lo stesso vale per i software vecchi che devono girare su distro nuove. Se io faccio un software e voglio che vada su tutte le distro linux presenti e future ho 2 scelte:

1 ricompilare e reimpacchettare il programma ogni volta, e lo può fare anche uno script(provate una vecchissima versione di VMware e vedete se il .run funzione)

2 se non volgio avere rogne COMPILO STATICAMENTE e e metto le librerie nel software.

Il problema che tutti lamentano in windows è proprio quello che si porta dietro la compatibilità ed è vecchio, quella delle distro linux è la soluzione.
Guardate che tutto questo non dipende dal fatto di essere open-source o closed, è una cosa generale dell'informatica la compilazione statica, che ti garantisce che il software funzioni ovunque e sempre, o la compilazione linkando le librerie, che devi fare ogni volta ma la puoi fare con uno script o un qualsiasi sistema automatico.

Vedo che col tempo la cultura informatica scende inesorabilmente anche in certi ambienti.
È stupido stare a parlare di certe cose elementari, le aziende fanno marketing sapendo che tutti i niubbi(sedicenti power-user) ci cascano

Non si tratta solo di linkare tutto staticamente e ricompilare un programma ogni tot anni, intanto perche molti componenti non è assolutamente consigliabile linkarli staticamente (GTK, libc...) e anche eprche il programma deve interagire con altre parti e con servizi offerti dal sistema operativo, e se questi cambiano nel tempo devo anche rimettere mano al mkio programma per adattarlo.
Windows invece ha degli ottimi livelli di astrazione, quello che non cambiano sono le API ma tutto quello che c'è sotto possono migliorarlo e aggiornarlo continuamente tramite update senza che i programmi ne risentano, eprche sono isolati dalle modifiche interne.

[leptone]

Ma allora decidete cosa volete? la compatibilità col passato che comporta evidenti problemi o la modernità? e poi si possono seguire molte strade una è quella di tecnologie tipo apple con rosetta, o si possono utilizzare cose non compilate(vasta scelta), comunque in genere se io faccio un applicativo o scelgo di farne uno alla windows XP o pianifico fin da subito che quell'applicativo in futuro deve girare su diverse versioni dello stesso os. Se un applicativo non è pesante si può scegliere la strada del non compilato(java, python ecc) o si pacchettizza una versione che gira con il suo windows coetaneo in una immagine bella e pronta per VMware-Player e simili.
Se un software è vecchio di solito richiede una frazione della potenza di un a macchina moderna e la virtualizzazione va a pennello, se è un software che richiede molta potenza allora è un sw impotante e allora solitamente viene aggiornato .
Io non vorrei mai avere un sistema che si porta dietro tutta la compatibilità per far girare 2 gestionali e simili(che sul lavoro sono tanti e contano), ma preferisco un OS moderno e veloce, perchè non si porta compatibilità con la preistoria dietro, e il gestionale(o quelllo che è) lo faccio girare dentro una macchina virtuale con win98 o dos(parlando di desktop altrimenti si prospettano altre situazioni).

EDIT

Voi cosa preferite?

[iocci]

Originariamente inviato da leptone

Ma allora decidete cosa volete? la compatibilità col passato che comporta evidenti problemi o la modernità? e poi si possono seguire molte strade una è quella di tecnologie tipo apple con rosetta, o si possono utilizzare cose non compilate(vasta scelta), comunque in genere se io faccio un applicativo o scelgo di farne uno alla windows XP o pianifico fin da subito che quell'applicativo in futuro deve girare su diverse versioni dello stesso os. Se un applicativo non è pesante si può scegliere la strada del non compilato(java, python ecc) o si pacchettizza una versione che gira con il suo windows coetaneo in una immagine bella e pronta per VMware-Player e simili.
Se un software è vecchio di solito richiede una frazione della potenza di un a macchina moderna e la virtualizzazione va a pennello, se è un software che richiede molta potenza allora è un sw impotante e allora solitamente viene aggiornato .
Io non vorrei mai avere un sistema che si porta dietro tutta la compatibilità per far girare 2 gestionali e simili(che sul lavoro sono tanti e contano), ma preferisco un OS moderno e veloce, perchè non si porta compatibilità con la preistoria dietro, e il gestionale(o quelllo che è) lo faccio girare dentro una macchina virtuale con win98 o dos(parlando di desktop altrimenti si prospettano altre situazioni).

Il discorso della retrocompatibilità non funziona cosi. Guarda bene questa immagine:



L'intero kernel, l'executive e tutte le funzionalità di Windows sono isolate dalle applicazioni tramite un livello di astrazione.
Le applicazioni non accedono direttamente alle parti interne ma chiamano le loro funzionalita tramite delle API ben definite che non cambiano mai.
Questo significa che alla Microsoft possono cambiare quando vogliono il codice interno di Windows, possono migliorarlo, renderlo piu veloce, possono cancellare e riscrivere tutto e alle applicazioni non cambia niente.
Questo permette di poter evolvere il sistema velocemente ogni volta che si desidare, in quanto la modifica di un componente interno non costringe ad aggiornare tutte le applicazioni che usano quel componente. L'astrazione e l'isolamento tra i vari moduli di un programma è una cosa essenziale.

Da XP a Vista hanno fatto un lavoro imponente e importantissimo: hanno riscritto milioni di righe di codice da C a C#, rendendo il sistema piu mantenibile e piu sicuro, e potenzialmente piu veloce grazie alla possibilita di implementare piu facilmente algoritmi piu efficenti, senza che questo intaccasse il funzionamento delle applicazioni.
Come si vede non è vero che la retrocompatibilità col passato comporta evidenti problemi con la modernità, anzi.

Su Linux invece non è cosi, il fatto che non c'è un'unica interfaccia di programmazione stabile e fissa che comprende non solo il kernel ma tutte le funzionalita di base che un OS deve offrire fa in modo che ogni cambiamento si ripercuote anche sulle applicazioni. Se uno vuole fare una modifica che non è trasparente alle applicaziioni deve modificare anche le applicazioni che dipendono dal componente che viene modificato, e puo essere anche un grosso lavoro e di sicuro rallenta lo sviluppo. Mentre su windows il problema non si pone visto che le modifiche interne sono trasparenti alle applicazioni e quindi possono evolvere e modificare quello che vogliono molto piu rapidamente con meno lavoro e meno camplicazioni.

Inoltre l'uso di linguaggi managed come Python o Java non risolve il problema, perche non basta che il codice venga eseguito ma dipende anche cosa fa e come interagisce col sistema.
Se faccio un programma in Python gira su tutte le distro, ma se quando l'ho scritto le impostazioni venivano memorizzate in un posto e dopo mesi vengono messe in un altro il programma non funziona, tanto per fare un esempio semplice. E queste cose capitano spesso, il post che ho incollato prima rende l'idea:

Noto la tendenza ultimamente di scaricare su chi rilascia le distribuzioni il compito di "far andare le cose". Versione del kernel stabile? Non serve, tanto ci pensa la distro a sceglierne una "abbastanza vecchia" e a mettere le patch che servono. Una qualche versione di alsa che funzioni out of the box senza smadonnamenti? Non serve tanto basta che la distro sistemi tutte le rogne. E cosi' via. Naturale che qualcosa poi scappi.
Non che per l'utente ci siano meno rogne, soprattutto quando si parla di configurarsi le cose. Non solo non si sa piu' dove vengono salvate le impostazioni (in un dotfile, in un misterioso file xml in una qualche sottocartella o in una abominevole copia del registro di Windows), ma applicazioni diverse le salvano in posti diversi (perche' se imposto il wifi dal dall'applet di gnome non e' lo stesso che farlo da linea di comando?). La lista di componenti che si comporta cosi' e' lunga e questo causa problemi anche a chi deve preparare la distribuzione, perche' diventa difficile, se non impossibile, usare applicazioni che vanno a cercarsi la stessa configurazione in posti diversi.
(le nuove distro sono peggiori delle precedenti)

[leptone]

stiamo andando un po' offtopic, quello che dici sicuramente è corretto, ma quello che voglio dire è che le parole di mr Rosenthal, sono solo pubblicità, marketing o FUD e non sono un giudizio tecnico, e che sulla piattaforma android certe cose si possono implementare.

Poi nemmeno a me piace l'invasività delle applicazioni google, io da questo punto di vista sono all'antica: i dati stanno sulla mia macchinae devo essere io a preoccuparmi di sincronizzare i miei vari dispositivi come desktop, portatile, cellulare, palmare anche con un'applicazione user-friendly immediata e semplicissima.(non tanto mi sta simpatico android anche se sono un simpatizzante e utente del FOSS)

E comunque riprendendo il tuo discorso Android è un sistema completo, e per quanto riguarda Linux, ci si dimentica che il sistema è GNU, e poi ci sono le specifiche LSB(linux standard base) che sono quelle che usano ANCHE E SOPRATTUTTO software come skype, opera, mathlab insomma i closed source che per loro necessità devono fare così. Per esempio in debian basta installare il pacchetto LSB e si ha la compatibilità con tutti i software binari che rispettano quello standard.
Poi essendo open-source nulla vieta di creare distro che hanno come centro linux invece di GNU, ovvero partono da un kernel e non da un sistema e qui il discorso è diverso, per esempio esistono cose di tutti i colori come bsd/GNU opensolaris/GNU e chi + ne ha + ne metta. Ma la maggior parte delle distro diffuse supporta LSB (magari qualcuno in versione + recente, e su freeBSD c'è una compatibilità al 70% di LSB che permette di far girare mathlab e compagni) e cmq android è un sistema e le parole di mr Rosenthal fanno parte del mondo della pubblicità, marketing, FUD infatti è un CEO non un ingegnere(se lo e dice il falso essendo di parte o no?)
Con android non ci saranno di questi problemi, giusto, se così non è informatemi e sarò contento di ascoltare le vostre spiegazioni(imparando qualcosa di nuovo grazie a voi come spesso avviene in questo forum da anni)

[Sire_Angelus]

oddio.. va be va.. apparte che mi fa ridere vedere che passando dal c al csharp il sistema va più veloce..

in ogni caso.. pensate un'attimo.. l'evoluzione di windows e di linux sono su due mondi diversi.

linux.. escono aggiornamenti con una rapidità disarmante.. ubuntu ne fa uscire qualcosa come 10-15 al giorno minimo.. che fanno EVOLVERE tutto il sistema, non si parla solo di patch di sicurezza..

windows.. é xp e basta.. il kernel, le api, tutti RESTA COSì comé per 7-8 anni... non ce evoluzione, non ce miglioramento... ci credo che i programmi continuano a girare per 7-8 anni!

se vuoi che il tuo programma per linux facciamo come windows.. beh... allora BASTA AGGIORNARE E NON CAMBIARE DISTRO!

in più tutti a nominare ubuntu.. mentre una distro gentoo(ma li bisogna saperci mettere le mani) ha nei repository di portage librerie dell'anno del cucco, se servono é sufficente richiamare nome e versione e le installi...

se pensate che come kernel linux é più che raddoppiato in funzionalità dal passaggio dal 2,4 al 2,6(che é equivalente al passaggio da XP a vista)(e deve dare funzionalità sulle macchine più disparate- sparc, powerpc, alpha, cose che windows si sogna) e la pesantezza é rimasta uguale(Windows manager principali non hanno proprio fatto altrettanto, si é visto qualcosa con kde4 ma é presto..) la dice lunga sulla finezza e cura con cui viene evoluto e scritto il kernel..

[eimer]

X iocci

tanto per restare OT

Nel 1969 la potenza di due commodore 64 ha portato l'uomo sulla luna, oggi un processore a 3 ghz serve a far girare windows xp...Qualcosa è andato storto!!!

[Barra]

Avevo scritto una risposta lunga un km ma poi l'ho cancellata. Riassumo brevemente:

Quoto Leptone quando dice che la situazione non è affatto così drammatica. Google ad esempio x evitare casini con gli update di wine ha pacchettizzato picasa (facendo tecnicamente una porcata indicibile x il mondo linux ma è la norma x gli ambienti MS) con wine e tutte le dipendenze necessarie. Questo se dal punto di vista tecnico è un vantaggio e una semplificazione porta cmq grossi svantaggi: esce una qualche patch che impedisce al computer di trasformarsi in un terminator a causa di un bug di wine. I google boys devono correre ad aggiornare altrimenti gli utilizzatori di picasa saranno terminati dai loro pc. Su windows questo modus operandi è la norma. Chi fa un applicativo lo fa con determinate librerie e tutto muore li. La soluzione linux-like è decisamente + intelligente. 1 unico sistema di gestione che aggiorna tutto. Questo comporta (o meglio così può sembrare) + lavoro x i piccoli sviluppatori. Però la sicurezza del sistema ne giova. Attualmente la maggior parte dei crash e dei casini di windows non dipendono da windows ma da elementi di 3e parti non correttamente installati, aggiornati, mantenuti dai produttori. Questo è imho uno dei limiti maggior di windows. Vedere che aggiornado il mio intrepid alla rc1 mi vengono aggiornati pulseaudio, driver video, cups (il sistema di gestione della stampa), librerie di vario tipo è bello. Significa che tutti si lavora x la stabilità. Se poi devo (come infatti ho fatto) ricompilare vmware non è un gran danno. Tanto + che x merito di dell la cosa la faccio ora e non la farò mai + visto che è stato introdotto in intrepid (non so se è già operativo e non so se vale x qualunque modulo) un applicativo che ricompila i moduli aggiuntivi del kernel a seguito di update dello stesso (x semplificare la vita gli utonti).

CMQ i casini che può avere linux non centrano una mazza con Android che NON È UN SISTEMA LINUX. E' un kernel + altra roba. Esattamente come il software di un qualunque lettore divx economico, qualunque router adsl (con qualche rara eccezione), come qualunque decoder iptv in commercio (SKY, tiscali, alicetv). Certamente non è un sistema completo quanto windows mobile (che ha anni di vita alle spalle). Ma già ora è una spanna sopra a iphone x quanto riguarda le funzionalità (questo nonostante l'interfaccia di iphone mi piaccia molto). Dategli 1 annetto poi vedrete se non avremo connettori x exchange, applicativi x la sincronizzazione senza passare da bigG.

[mjordan]

Ah quindi le considerazioni le fa proprio uno indipendente e neutrale...
Ho interrotto di leggere la news già dopo la prima riga...

[mjordan]

Originariamente inviato da iocci

L'intero kernel, l'executive e tutte le funzionalità di Windows sono isolate dalle applicazioni tramite un livello di astrazione.

Non è forse cosi in tutti i SO? O meglio, non è forse questo uno dei compiti di un so?

Le applicazioni non accedono direttamente alle parti interne ma chiamano le loro funzionalita tramite delle API ben definite che non cambiano mai.

Il "cambiano mai" è un po forte, come affermazione (voglio essere gentile e non dire che hai detto una grossa cagata), comunque, non è forse cosi in tutti i SO? O forse negli altri SO le applicazioni si programmano facendo chiamate kernel?

Questo significa che alla Microsoft possono cambiare quando vogliono il codice interno di Windows, possono migliorarlo, renderlo piu veloce, possono cancellare e riscrivere tutto e alle applicazioni non cambia niente.

Quindi se io quel codice lo cancello, le mie applicazioni continueranno a girare... Scherzi a parte, fin quando rispetti le interfacce è normale... Ma ancora, non è forse cosi in tutti i SO o API?

Questo permette di poter evolvere il sistema velocemente ogni volta che si desidare, in quanto la modifica di un componente interno non costringe ad aggiornare tutte le applicazioni che usano quel componente. L'astrazione e l'isolamento tra i vari moduli di un programma è una cosa essenziale.

Che è il semplice concetto di API, comune a qualsiasi software di questo mondo. E di certo non è un'evoluzione che si può fare cosi facilmente come vuoi far credere. Modificare anche solo un'interfaccia di astrazione (perchè evolversi significa anche fare questo) comporta i problemi che invece vuoi far credere non esistano.

Come si vede non è vero che la retrocompatibilità col passato comporta evidenti problemi con la modernità, anzi.

Come no. Per mantenere la compatibilità col passato ci portiamo dietro ancora API vecchie e completamente duplicate con quelle nuove.
O peggio ancora un numero di layer eccessivo, con nuove API basate su API vecchie.

Su Linux invece non è cosi, il fatto che non c'è un'unica interfaccia di programmazione stabile e fissa che comprende non solo il kernel ma tutte le funzionalita di base che un OS deve offrire fa in modo che ogni cambiamento si ripercuote anche sulle applicazioni.

Ma quando mai. Se mi parli di "interfaccia di programmazione" mi parli di API, che per concetto, è un'astrazione piu' alta di un livello piu' basso e quindi "immutabile" rispetto alle system call mutabili (parliamo di interfacce). E i problemi ce li hanno solo i driver, non le applicazioni. Driver che vengono mantenuti in concomitanza con il kernel, il che quindi è pure relativo. E soprattutto nemmeno Windows ne è esente, non crederai forse che i driver di Windows Vista oggi funzioneranno con Windows del 2018... Windows poi non evolve incrementalmente ma sta sul mercato almeno 4 o 5 anni con un'API fissa... Paragonare Linux e Windows in questo non ha senso.
Secondo, fai una grande confusione fra api del kernel (livello modulo o livello driver) e api di esposizione del kernel (livello applicazione). In Linux, l'API immutabile che fa da interfaccia fra kernel e applicazioni si chiama glibc. E sono vent'anni che funziona e in linea di massima presenta le stesse chiamate di sempre. Ed è uno standard POSIX, non è che se lo inventano i programmatori mentre scrivono il kernel. Terzo, il 99.99% delle applicazioni non deve mai andare a un livello piu' basso della glibc e il restante 0.01% che lo deve fare sono tool di sistema, non proprio software applicativo.

Se uno vuole fare una modifica che non è trasparente alle applicaziioni deve modificare anche le applicazioni che dipendono dal componente che viene modificato, e puo essere anche un grosso lavoro e di sicuro rallenta lo sviluppo.

Perchè, in Windows i layer piu' alti si adattano al nuovo codice con la bacchetta magica? Ti ripeto, fin quando si modifica il codice nel rispetto delle interfacce è cosi per tutti i SO, non solo per Windows (e gli SO in questo non c'entrano nulla, è cosi proprio per il codice in generale). Ma stiamo parlando di evoluzione, e quindi anche la possibilità che queste interfacce debbano cambiare. O no?

Mentre su windows il problema non si pone visto che le modifiche interne sono trasparenti alle applicazioni e quindi possono evolvere e modificare quello che vogliono molto piu rapidamente con meno lavoro e meno camplicazioni.

Quindi se io in Windows con una modifica "interna" rimuovo un metodo di classe, tutta la gerarchia di ereditarietà fa refactoring in automatico con la sfera del mago silvan...

Inoltre l'uso di linguaggi managed come Python o Java non risolve il problema, perche non basta che il codice venga eseguito ma dipende anche cosa fa e come interagisce col sistema.
Se faccio un programma in Python gira su tutte le distro, ma se quando l'ho scritto le impostazioni venivano memorizzate in un posto e dopo mesi vengono messe in un altro il programma non funziona, tanto per fare un esempio semplice. E queste cose capitano spesso, il post che ho incollato prima rende l'idea.

Ma questo non è mica un'esempio rappresentativo del discorso che si faceva, cosa c'entra un linguaggio e i problemi di portabilità e retrocompatibilità con il modo con cui uno scrive delle applicazioni.

Noto la tendenza ultimamente di scaricare su chi rilascia le distribuzioni il compito di "far andare le cose". Versione del kernel stabile? Non serve, tanto ci pensa la distro a sceglierne una "abbastanza vecchia" e a mettere le patch che servono. Una qualche versione di alsa che funzioni out of the box senza smadonnamenti? Non serve tanto basta che la distro sistemi tutte le rogne. E cosi' via. Naturale che qualcosa poi scappi.

Veramente è proprio il contrario, sono proprio le distribuzioni che invece non aspettano le release stabili e includono le branch ancora in sviluppo e testing, facendo addirittura backporting su release considerate stabili di features che stanno presenti sono in trunk e sono ancora in sviluppo attivo... Cognizione di causa saltami addosso....

Non che per l'utente ci siano meno rogne, soprattutto quando si parla di configurarsi le cose. Non solo non si sa piu' dove vengono salvate le impostazioni (in un dotfile, in un misterioso file xml in una qualche sottocartella o in una abominevole copia del registro di Windows), ma applicazioni diverse le salvano in posti diversi (perche' se imposto il wifi dal dall'applet di gnome non e' lo stesso che farlo da linea di comando?).

Il discorso è semplicemente tecnico: utilizzando una GUI molto spesso non puoi avere lo stesso ventaglio di parametri. Di conseguenza il front-end gui fa prima a crearsi un file di configurazione differente nel quale leggere i parametri da passare all'applicazione console. Questo è lo svantaggio del modello applicazione / frontend rispetto al modello applicazione GUI pura. Ma il vantaggio rispetto allo svantaggio, almeno a quelli piu' esperti, è evidente. E di certo non è un concetto che investe Linux in quanto SO ma è proprio un paradigma di scelta nel codificare un'applicazione. E' una scelta progettuale delle applicazioni, non ha nulla a che vedere con Linux in se. Puoi scrivere un'applicazione GUI nativa senza riga di comando e non avere di questi problemi. Nemmeno da Visual Studio puoi accedere a tutto quello che supporta il compilatore da riga di comando, tanto per farti un esempio. E i file di una soluzione visual studio non sono certo uguali ai makefile di un build system completamente da riga di comando...
Altro esempio, vuoi forse dirmi che MS ha introdotto PowerShell su Vista perchè la riga di comando è obsoleta? Una riga di comando è considerata obsoleta solo da chi con un computer oltre 3 checkbox di un'utility del menga non va. Fortunatamente l'utenza non è tutta uguale.

La lista di componenti che si comporta cosi' e' lunga e questo causa problemi anche a chi deve preparare la distribuzione, perche' diventa difficile, se non impossibile, usare applicazioni che vanno a cercarsi la stessa configurazione in posti diversi.

Le applicazioni sono fatte per gli utenti, non per i creatori di distribuzioni. Quello di far funzionare pacchetti in un sistema completo è il loro lavoro. Nessuno ha mai detto che sia facile. Quanto agli utenti, l'approccio applicazione console basata su frontend GUI è una scelta che favorisce gli utenti esperti. I lamer, i noob e tutto il resto dovrebbero usare Ubuntu e configurare il tutto mediante gli strumenti forniti. Se tutto ciò non fosse ancora sufficiente, possono tornare a Windows tranquillamente. Nessuno ha mai detto o preteso che Linux sia lo strumento ideale per tutti.Ognuno deve scegliere ciò è piu' consono per le proprie esigenze. Solo che se uno ha esigenze da noob e pretende simili modifiche da un sistema Unix, come direbbe abatantuono, sta pisciando fuori dal seminato. Io personalmente un'apache o un mysql la cui configurazione sia esclusivamente GUI non li chiederei nemmeno come punizione se dovessi andare a finire all'inferno.