Redox OS

[pabloski]

Originariamente inviato da fano

perché sbattesi a rendere sicure applicazioni scritte in C/C++ linguaggi "unsafe by design"?

Che poi non sarebbe nemmeno possibile. Magari usando qualche diavoleria prestata dal deep learning, ci si potrebbe avvicinare.

Originariamente inviato da fano

Io - personalmente - credo che sia meglio C# che Rust

Il problema di C# e' che quelle garanzie si pagano in termini prestazionali e di complessita' del CLR.

Rust e' stato pensato affinche' il compilatore fosse in grado di fare le sue valutazioni a compile-time. A runtime hai un normalissimo programma, senza garbage collector, senza controlli sui tipi, senza bound checking, ecc...

Il risultato e' questo http://benchmarksgame.alioth.debian.org/u64q/rust.html

Originariamente inviato da fano

Ma un "language based OS" offre ulteriori vantaggi sia per quanto riguarda la sicurezza che per quanto riguarda la velocità

Che poi sarebbe pure ora di svecchiare un po' il software di base. Negli ultimi 40 anni sono cambiate parecchie cose e nuovi modelli sono stati sviluppati, che semplificano il lavoro del programmatore e migliorano prestazioni, efficienza e robustezza.

[fano]

Originariamente inviato da pabloski

Che poi non sarebbe nemmeno possibile. Magari usando qualche diavoleria prestata dal deep learning, ci si potrebbe avvicinare.

Infatti: non è possibile!
Anche le funzioni "safe" sulle stringhe tipo strncpy() non sono "safe" per nulla (banale ti puoi "emozionare" ed invertire il parametro len mettendoci la len di destinazione... o usare sizeof() su un char * ed ottenere 4 / 8 SEMPRE!).

Originariamente inviato da pabloski

Il problema di C# e' che quelle garanzie si pagano in termini prestazionali e di complessita' del CLR.

C# (o meglio IL) con un buon compilatore AOT può essere velocissimo anche lui...
Prendi per esempio Midori si trovarono nella situazione assurda di avere un OS che occupava la CPU al 100%, ma non perché era "gonfio", ma perché era così efficiente e parallelo che la CPU non era mai IDLE!
(Ovviamente era un po' un "bug" e poi lo hanno risolto )

Leggi qui:
http://joeduffyblog.com/2015/12/19/safe-native-code/

Originariamente inviato da pabloski

Rust e' stato pensato affinche' il compilatore fosse in grado di fare le sue valutazioni a compile-time. A runtime hai un normalissimo programma, senza garbage collector, senza controlli sui tipi, senza bound checking, ecc...

Io non so se lo voglio un "programma" normalissimo... per avere un linguaggio "safe" non puoi esimerti da fare quei controlli a run time! Poi il compilatore in molti casi può (deve) durante l'ottimizzazione rimuovere bound checking, allocare nello stack il più possibile, ecc...
Se l'assenza del garbage collector significa che debbo essere io a sbattermi a rilasciare la memoria beh no grazie c'è già il C per questo

Il risultato e' questo http://benchmarksgame.alioth.debian.org/u64q/rust.html

Originariamente inviato da pabloski

Che poi sarebbe pure ora di svecchiare un po' il software di base. Negli ultimi 40 anni sono cambiate parecchie cose e nuovi modelli sono stati sviluppati, che semplificano il lavoro del programmatore e migliorano prestazioni, efficienza e robustezza.

Infatti il fatto che su Redox OS potranno comunque girare applicazioni scritte in C/C++ un po' mi preoccupa finirà presto per essere "infettato" dalla marea di applicazioni GNU totalmente unsafe e crashanti...

[LukeIlBello]

si vabbè adesso non bestemmiamo con C# e Java...
linguaggi nati per dar luogo a programmi lenti e ridondanti..
tutto ciò che origina byte-code e non assembly è fuori discussione
(nel senso che perde in partenza senza sè ne ma)..

io comunque resto fedele al C++, dopo anni di uso (sia in Ansi che win32)
ogni puntatore allocato non mi scordo mai di ammazzarlo

[pabloski]

Originariamente inviato da fano

Infatti: non è possibile!
C# (o meglio IL) con un buon compilatore AOT può essere velocissimo anche lui...

In parte si. Ma i controlli a runtime restano e costano. Il garbage collector e' il vero problema, perche' bisogna prestare moltissima attenzione a non farlo entrare in funzione in un "brutto momento". Le architetture multicore aiutano in parte, visto che lo si puo' "scaricare" sul core maggiormente libero.

Originariamente inviato da fano

Io non so se lo voglio un "programma" normalissimo... per avere un linguaggio "safe" non puoi esimerti da fare quei controlli a run time!

Fosse solo quello. L'infrastruttura per fare tutto cio' e' estremamente complessa e quindi vi si possono annidare molti bug.

Se non sbaglio proprio Cosmos si e' dovuto inventare X#, visto che ovviamente garbage collector e compagnia non hanno il supporto del garbage collector e compagnia e dunque vanno sviluppati in un simil-C# ma unsafe.

Ecco, quella parte si potrebbe considerare di scriverla in Rust.

Originariamente inviato da fano

Se l'assenza del garbage collector significa che debbo essere io a sbattermi a rilasciare la memoria beh

Nel caso di Rust no. Le istruzioni necessarie per liberare le aree di memoria allocate vengono inserite ( ovviamente ) nell'eseguibile, ma e' il compilatore a farlo.

Originariamente inviato da fano

Infatti il fatto che su Redox OS potranno comunque girare applicazioni scritte in C/C++ un po' mi preoccupa finirà presto per essere "infettato" dalla marea di applicazioni GNU totalmente unsafe e crashanti...

Che ci potranno essere applicazioni in C credo sia ormai scontato. Bisognera' vedere se saranno quelle GNU o altre. La licenza MIT farebbe pensare di no. L'uso di Newlib lascia dei dubbi. Se avessero portato Musl, si sarebbe potuto concludere che sono in buona sostanza anti-GNU.

Per ora credo che attirera' soprattutto i fan di Rust, quindi...

[fano]

Originariamente inviato da pabloski

In parte si. Ma i controlli a runtime restano e costano. Il garbage collector e' il vero problema, perche' bisogna prestare moltissima attenzione a non farlo entrare in funzione in un "brutto momento". Le architetture multicore aiutano in parte, visto che lo si puo' "scaricare" sul core maggiormente libero.

Alcuni controlli spariscono / possono sparire se il compilatore ottimizza banalmente:

for(int i = 0; i < MyArray.len; i++) 
{
     MyArray[i] = ...;
}

Il normale compilatore C# (Roslyn) genera un IL che effettivamente per ogni MyArray[i] controlla che 'i' sia "in bound" cosa che beh è ovvio per costruzione... compito dell'optimizzazione è - appunto - rendersi conto di questo ed altri casi e modificare l'IL generato.

Tutte cose che appunto in Midori sono state fatte e lo saranno anche in Cosmos.

Anche per il GC con l'escape analys si può fare in modo di "allocare" la maggioranza degli oggetti sullo stack!

Originariamente inviato da pabloski

Fosse solo quello. L'infrastruttura per fare tutto cio' e' estremamente complessa e quindi vi si possono annidare molti bug.

Se non sbaglio proprio Cosmos si e' dovuto inventare X#, visto che ovviamente garbage collector e compagnia non hanno il supporto del garbage collector e compagnia e dunque vanno sviluppati in un simil-C# ma unsafe.

No X# è un "High Level Assembler" non c'entra con il GC, è necessario solo per la parte molto a basso livello e sarà l'1% dell'intero codice di Cosmos, il resto è tutto C# (sì il codice "low level" è unsafe, ma cerchiamo di ridurre al minimo possibile anche quello).

Originariamente inviato da pabloski

Nel caso di Rust no. Le istruzioni necessarie per liberare le aree di memoria allocate vengono inserite ( ovviamente ) nell'eseguibile, ma e' il compilatore a farlo.

Non usa il "kludge" del distruttore come C++ giusto? Avevo letto come facevano, ma mi sembrava troppo "magico"...

Vedi io preferisco scrivere in un linguaggio di alto livello come C# / F# / VB .Net e lasciare al compilatore il compito di ottimizzare il mio codice senza dovermi preoccupare di:

1. Dove la memoria venga allocata
2. Se ho lo spazio per scrivere la stringa
3. Non dover riempire il mio codice di if (rc = ...), ma appunto concentrarmi sulla parte "no fail" del codice (quella che sarà eseguita il 99.9999% delle volte!)
4. Senza dovermelo menare con simboli strani tipo '&`' (?) per evitare che il linguaggio mi freghi con i dangling pointer

Originariamente inviato da pabloski

Che ci potranno essere applicazioni in C credo sia ormai scontato. Bisognera' vedere se saranno quelle GNU o altre. La licenza MIT farebbe pensare di no. L'uso di Newlib lascia dei dubbi. Se avessero portato Musl, si sarebbe potuto concludere che sono in buona sostanza anti-GNU.

Se avessero scritto una loro libc in Rust credo che sarebbe stato più interessante e forse più safe una sorta di "sand box" per il C... altrimenti arriverà sempre il "ragazzetto" che deciderà di portare SSL e partire dal codice "iper-bacato" di OpenSSL (un componente dove la sicurezza è essenziale me lo scrivi in C? E` davvero così importante la velocità di esecuzione rispetto alla sicurezza?)

Originariamente inviato da pabloski

Per ora credo che attirera' soprattutto i fan di Rust, quindi...

Me lo auguro per loro... io ormai vedo C/C++ come virus

(Il porting di Python su Haiku OS ha praticamente fatto secco Haiku visto che sono "diventati" Linux nel processo: persa retro-compatibilità con BeOS, non si possono più installare i programmi semplicemente scompattandoli, ma c'è un Package Manager incasinatissimo, ecc...)

[pabloski]

Originariamente inviato da fano

Il normale compilatore C# (Roslyn) genera un IL che effettivamente per ogni MyArray[i] controlla che 'i' sia "in bound" cosa che beh è ovvio per costruzione... compito dell'optimizzazione è - appunto - rendersi conto di questo ed altri casi e modificare l'IL generato.

Tutte cose che appunto in Midori sono state fatte e lo saranno anche in Cosmos.

Cioe' il compilatore usato non si comporta come quello di default? Mi pare di capire che tenda ad eliminare quanti piu' controlli a runtime possibile. In pratica e' una rustizzazione di c#.

Originariamente inviato da fano

No X# è un "High Level Assembler" non c'entra con il GC, è necessario solo per la parte molto a basso livello e sarà l'1% dell'intero codice di Cosmos, il resto è tutto C# (sì il codice "low level" è unsafe, ma cerchiamo di ridurre al minimo possibile anche quello).

Ridurlo e' certamente un modo per tagliare le gambe a quanti piu' bug possibile. Ma mi pare di capire che alla fine il GC rimane e gia' quello e' un pezzo di codice molto grosso. In cui si possono annidare molti bug.

Originariamente inviato da fano

Non usa il "kludge" del distruttore come C++ giusto? Avevo letto come facevano, ma mi sembrava troppo "magico"...

E' vero, e' difficile star dietro ai progettisti di Rust. Hanno realizzato qualcosa di incredibile e complesso. Non e' un caso se il meccanismo dell'ownership risulta ostico alla stragrande maggioranza di coloro che cominciano con Rust.

Originariamente inviato da fano

Vedi io preferisco scrivere in un linguaggio di alto livello come C# / F# / VB .Net e lasciare al compilatore il compito di ottimizzare il mio codice senza dovermi preoccupare di:

1. Dove la memoria venga allocata
2. Se ho lo spazio per scrivere la stringa
3. Non dover riempire il mio codice di if (rc = ...), ma appunto concentrarmi sulla parte "no fail" del codice (quella che sarà eseguita il 99.9999% delle volte!)
4. Senza dovermelo menare con simboli strani tipo '&`' (?) per evitare che il linguaggio mi freghi con i dangling pointer

Penso che quasi tutti i programmatori preferiscano evitare questo tipo di problemi, ragion per cui sono nati tantissimi linguaggi ad alto livello.

Ovviamente anche la presenza di strutture dati che non si limitino ad un'area di memoria contigua spacciata per array, fa piacere.

Ma tutti i nuovi linguaggi affrontano questi problemi, in un modo o nell'altro.

Originariamente inviato da fano

Se avessero scritto una loro libc in Rust credo che sarebbe stato più interessante e forse più safe una sorta di "sand box" per il C... altrimenti arriverà sempre il "ragazzetto" che deciderà di portare SSL e partire dal codice "iper-bacato" di OpenSSL (un componente dove la sicurezza è essenziale me lo scrivi in C? E` davvero così importante la velocità di esecuzione rispetto alla sicurezza?)

Non conosco i loro piani e mi pare strano che non l'abbiano fatto o almeno considerato. Visto che sono dei maniaci di Rust, mi risulta difficile credere che in futuro non tenteranno un'altra strada. Restera' anche una libc? Bella domanda. Potrebbero decidere che non vale la pena lasciare una simile liability nel sistema.

Originariamente inviato da fano

(Il porting di Python su Haiku OS ha praticamente fatto secco Haiku visto che sono "diventati" Linux nel processo: persa retro-compatibilità con BeOS, non si possono più installare i programmi semplicemente scompattandoli, ma c'è un Package Manager incasinatissimo, ecc...)

Credo che il problema sia la consapevolezza che senza software non si vada da nessuna parte. E il software e' disponibile per una manciata di OS. Quindi o si sta alle loro regole o si tenta la fortuna ricreando tutto da zero.

Certo e' che a colpi di retrocompatibilita' non si evolvera' mai per davvero. Appunto, Haiku ha perso l'anima. Vabbe' che ormai parlano di kernel NetBSD o FreeBSD.

[fano]

Originariamente inviato da pabloski

Cioe' il compilatore usato non si comporta come quello di default? Mi pare di capire che tenda ad eliminare quanti piu' controlli a runtime possibile. In pratica e' una rustizzazione di c#.

Il compilatore C# (Roslyn) già durante la generazione dell'IL può fare piccole ottimizzazioni (per esempio roba "matematica" tipo trasformare divisioni per 2 in shift, sostituire uno switch con solo un case e un defualt in un if / else ecc...) a runtime il JIT è libero di fare tutte le trasformazioni che vuole per ottimizzare il codice ha solo 2 limiti:

1. L'intento del programmatore deve essere preservato (non può fare come GCC con -O3 che per ottimizzare togli i check messi dal programmatore e così il codice va in SEGFAULT)
2. Ha poco tempo a disposizione quindi molte "trasformazioni" non possono essere fatte!

Usando un Ahed of Time compiler come quello di Cosmos o quello a cui sta lavorando la Microsoft (CoreRT) si ha molto più tempo a disposizione e si possono fare più ottimizzazioni interessanti...

Faccio notare - comunque - che anche Rust è in un certo senso "managed" per esempio il bound checking degli array lo fa anche Rust:

https://til.hashrocket.com/posts/9f3...ked-at-runtime

Originariamente inviato da pabloski

Ridurlo e' certamente un modo per tagliare le gambe a quanti piu' bug possibile. Ma mi pare di capire che alla fine il GC rimane e gia' quello e' un pezzo di codice molto grosso. In cui si possono annidare molti bug.

Beh ma è "un tratto" di .Net che ovviamente non può essere completamente eliminato, comunque si cercherà di scrivere ANCHE quella parte in C# (C# unsafe è comunque più safe di C/C++ ) e avremo degli unit test appositi per verificare che funzioni in maniera corretta...

Originariamente inviato da pabloski

E' vero, e' difficile star dietro ai progettisti di Rust. Hanno realizzato qualcosa di incredibile e complesso. Non e' un caso se il meccanismo dell'ownership risulta ostico alla stragrande maggioranza di coloro che cominciano con Rust.

Sì ma se la sintassi è ancora più complessa di C/C++ dubito sarà usato dalla massa faccio un esempio driver VGA Bochs:

Cosmos:
https://github.com/CosmosOS/Cosmos/b...o/VBEDriver.cs
(low level non accessibile all'utente)
https://github.com/CosmosOS/Cosmos/b...s/VBEScreen.cs

Redox:
https://github.com/redox-os/drivers/...gad/src/bga.rs

Originariamente inviato da pabloski

Penso che quasi tutti i programmatori preferiscano evitare questo tipo di problemi, ragion per cui sono nati tantissimi linguaggi ad alto livello.

Ovviamente anche la presenza di strutture dati che non si limitino ad un'area di memoria contigua spacciata per array, fa piacere.

Anche avere "davvero" l'array è un puntatore travestito fa piacere ciò se il C avesse avuto un vero tipo array uno sciocchezza fatta così per esempio:

typedef struct {
   size_t len;
   void *data;
} array;

sarebbe stato tutto molto più "safe" e persino accettabile che non ci fosse un tipo stringa e che si dicesse che una stringa è semplicemente un array di char (beh fino a che poi non è arrivato unicode e questa cosa ha perso totalmente di senso ovviamente ) avendo un campo len si avrebbe ottenuto 2 vantaggi:

1. Le farie funzioni che operano sulle "stringhe" sarebbe d'improvviso diventute "safe" copiare 2 stringhe? Do subito errore se la sorgente è più grande della destinazione: roba da signorine!
2. Pure più efficente visto che tutte le varie strXXX fanno dei gran for() / while() per cercare il famoso tappo '\0' sbordando - sovente - nel processo

Originariamente inviato da pabloski

Ma tutti i nuovi linguaggi affrontano questi problemi, in un modo o nell'altro.

Già perché tutti cercano di cancellare C / C++ dalla faccia della terra

Originariamente inviato da pabloski

Non conosco i loro piani e mi pare strano che non l'abbiano fatto o almeno considerato. Visto che sono dei maniaci di Rust, mi risulta difficile credere che in futuro non tenteranno un'altra strada. Restera' anche una libc? Bella domanda. Potrebbero decidere che non vale la pena lasciare una simile liability nel sistema.

Potrebbe pure essere una cosa "temporanea" l'uso di una libc scritta in codice unsafe magari hanno intenzione in futuro di riscriverla in Rust... bisognerebbe chiederglielo

Originariamente inviato da pabloski

Credo che il problema sia la consapevolezza che senza software non si vada da nessuna parte. E il software e' disponibile per una manciata di OS. Quindi o si sta alle loro regole o si tenta la fortuna ricreando tutto da zero.

Le "loro" regole sono per me inaccettabili vedi appunto Haiku che ha dovuto "sputt*nare" il suo file system che aveva una logica per facilitare il porting di Pithon che voleva a tutti i costi scrivere in /etc che su BeOS / Haiku non è mai esisto (che è sto "etc" non starà mica per "etcetera" vero ?)

Originariamente inviato da pabloski

Certo e' che a colpi di retrocompatibilita' non si evolvera' mai per davvero. Appunto, Haiku ha perso l'anima. Vabbe' che ormai parlano di kernel NetBSD o FreeBSD.

Spiego brevemente per chi non sa cosa sia Haiku (è IT per chi sta sviluppando un proprio OS) era nato per essere la re-implementazione moderna di BeOS e con retro-compabitilità con le applicazioni "legacy" fino a 2 anni fa era "perfetto" funzionava già un sacco di roba le applicazioni si "installavano" nel modo più semplice possibile (si scompattavano nella root... alcune funzionavano semplicemente scompattandole in una directory) poi si sono emozionati a portare le robe di GNU e si sono resi conto che era una "menata" doverle cambiare solo per i path che queste applicazioni (orrende) hanno cablato nel codice (!) e così si sono inventati un sistema di packaging che avrebbe reso una distro Linux orgogliosa per quanto complessa e "barocca" (filesystem "sbudellato", le app creano una sorta di FS virtuale)... nel processo hanno ottenuto anche di aver perso la retro-compatibilità con Be OS!

[homoinformatico]

Originariamente inviato da Perseverance

Ho letto per curiosità questa discussione e tutti i commenti, informandomi meglio su questo redox. Sarò sincero, io resto di un'altra idea, per me è solo un numero che si aggiunge ai numeri. Non vedo sbocco commerciale, vedo solo i classici buoni propositi con la topmodel che fà vedere che com'è dimagrita usando il prodotto X rispetto al C; continuo a vedere i soliti problemi dell'open di linux che prima o poi si affacceranno anche su redox.

Quando una cosa è open ogniuno fà come c***o gli pare, il problema principale è questo a mio avviso; aldilà del linguaggio di programmazione che può avere certi sviluppi favorevoli in un contesto piuttosto che in un altro, se c'è l'idea condivisa di sviluppare 1 cosa e per 1 cosa, e farla bene per quella cosa, tutto fila liscio altrimenti tutto và in fuffa.

Riguardo ai commenti sul personal computer io sono dell'idea contraria, cioè mi piace l'idea di avere un megaserver da cui attingere risorse di calcolo e storage, e clients indipendenti\rimpiazzabili che ne usufruiscono. Cioè io aumenterei ancora di più il divario della potenza di calcolo tra server e client, per me il client deve diventare un oggetto che, paradossalmente, vadi a pile AAA con potenza di calcolo di un flip-flop ma che tramite una postazione KVM (tastiera monitor mouse) interagisca in tutto e per tutto con un'istanza desktop su un server. Mi piacerebbe poi veder estesa la cosa anche oltre l'ambito domestico, oltre l'attuale desktop-remoto di vnc: quando le linee telefoniche saranno veloci da 100Mbps o più secondo me sarà possibile interagire fluidamente e senza accorgersene con un server avendo l'impressione di usare un pc in locale.

Secondo me sarebbe già possibile, su cavo di rete ormai si veicola di tutto oltre ai dati. Con una rete a bassa latenza su cui vengono codificati gli input di mouse\tastiera e il video remoto codificato in flusso audio\video a 60fps (la frequenza di refresh degli lcd) io credo che se qualcuno vuole potrà costruirci un sistema operativo client\server interamente basato sul concetto di desktop remoto.

E magari farlo con RUST potrebbe dargli quella visibilità che non ha mettendone in luce le notevoli qualità di coding, espressività ed efficienza.

Quando andavo a scuola, con un mio compagno, così per passione realizzammo un mini sistema operativo con un desktop environment basato su interfaccia web, aveva l'aspetto basilare tipo icewm, e mi è sempre piacuta l'idea di estremizzare l'usabilità condivisa di risorse altrimenti sprecate. Abbiamo tanta potenza di calcolo inespressa, lì, ad aumentare solo l'entropia e far girare le ventole di raffreddamento. La cosa poi morì lì, xò secondo me il futuro dovrebbe essere come lo immagino io o simile al più. Le risorse vanno condivise, il software va parallelizzato e svincolato dalla macchina fisica. Bisogna puntare sempre di più sull'ultimo livello del cosiddetto ISO\OSI, sull'astrazione, ed ottimizzare\efficientare ciò che sta sotto.

Sul fatto che l'eccessiva frammentazione sia il principale problema di linux (ma anche diciamo di tutti i sistemi diversi da windows o osx) ti do ragione.

Sul fatto invece di ritornare al sistema server/client non mi trovo d'accordo.
Rimanendo al sistema italia, la stragrande maggioranza dell'utenza "core" di un pc (ossia quelli che prima o poi non lo sostituiranno con un tablet, un telefono o chissà quale altra diavoleria), è composta da piccole aziende o piccoli lavoratori autonomi che fa tutto con un pc. Se a questo aggiungiamo la qualità delle nostre linee (il mio fetentissimo gestionale non và tanto bene manco con una vpn fibra/fibra), ti lascio immaginare la comodità di utilizzo di un sistema server/client.
Se poi per sistema server/client non intendiamo nemmeno l'idea di avere un server grosso fisicamente rilocato da qualche parte, ma l'idea di, come dire, noleggiarne la funzione, sono pure io dell'idea che i miei dati meno girano per internet e meglio è...

[fraquar]

Originariamente inviato da homoinformatico

Sul fatto che l'eccessiva frammentazione sia il principale problema di linux (ma anche diciamo di tutti i sistemi diversi da windows o osx) ti do ragione.

Sul fatto invece di ritornare al sistema server/client non mi trovo d'accordo.
Rimanendo al sistema italia, la stragrande maggioranza dell'utenza "core" di un pc (ossia quelli che prima o poi non lo sostituiranno con un tablet, un telefono o chissà quale altra diavoleria), è composta da piccole aziende o piccoli lavoratori autonomi che fa tutto con un pc. Se a questo aggiungiamo la qualità delle nostre linee (il mio fetentissimo gestionale non và tanto bene manco con una vpn fibra/fibra), ti lascio immaginare la comodità di utilizzo di un sistema server/client.
Se poi per sistema server/client non intendiamo nemmeno l'idea di avere un server grosso fisicamente rilocato da qualche parte, ma l'idea di, come dire, noleggiarne la funzione, sono pure io dell'idea che i miei dati meno girano per internet e meglio è...

Certo il problema di Linux è la frammentazione, non che non c'è un cazzo di software con un livello di produttività paragonabile alla concorrenza, non che sia ostico nell'utilizzo per l'utente medio, non che ad ogni aggiornamento non funziona più nulla...

[Slayer86]

Originariamente inviato da fraquar

Certo il problema di Linux è la frammentazione, non che non c'è un cazzo di software con un livello di produttività paragonabile alla concorrenza, non che sia ostico nell'utilizzo per l'utente medio, non che ad ogni aggiornamento non funziona più nulla...

I problemi che evidenzi sono tutti figli della frammentazione.
Se Adobe dovesse portare la sua suite su linux che librerie grafiche dovrebbe usare? Qt? Gtk+? qualsiasi cosa scelga si "gioca" metà delle poche persone che usano linux.

Dare compatibilità tutto con tutto porta agli altri problemi! Se il software venisse deprecato e riscritto in maniera sensata allora moltissimi problemi non ci sarebbero. Però essendo tutto libero ognuno fa come vuole e ci si trova nel 2017 ad usare X come server grafico con 2 candidati per sostituirlo, che sono incompleti e mal supportati da ormai 7/8 anni.

Una linea aziendale forte potrebbe al superamento di questi problemi, ma snaturerebbe il mondo Linux a tal punto che diventerebbe qualcos'altro.

[pabloski]

Originariamente inviato da fraquar

Certo il problema di Linux è la frammentazione

In parte si, altrimenti non sarebbe sentito il bisogno di una standardizzazione in stile Flatpak o Snap.

E poi la frammentazione e' una delle concause della presenza di un parco software ridotto.

Originariamente inviato da fraquar

non che non c'è un cazzo di software con un livello di produttività paragonabile alla concorrenza

Vero, ma non e' una situazione uniforme. Io per esempio sono uno sviluppatore software e di programmi di "produttivita'" nel mio campo ne trovi a decine. Parlo di quelli di alto livello, perche' quelli amateurish sono migliaia.

Quindi non facciamo di tutte le erbe un fascio. Ovviamente esistono anche altre nicchie che sono coperte. Penso a Blender per la grafica 3D, a VariCAD e simili per la progettazione meccanica, ecc...

Chiaro che Windows ne ha di piu' e copre praticamente ogni possibile caso d'uso del PC.

Originariamente inviato da fraquar

non che sia ostico nell'utilizzo per l'utente medio

Non sara' che l'utente medio vorrebbe usarlo a la Windows-maniera? No perche' definire ostico un Linux con Gnome e' un'abominazione.

Originariamente inviato da fraquar

non che ad ogni aggiornamento non funziona più nulla...

Questa francamente e' ridicola. Da Windows 8 si hanno piu' problemi con gli aggiornamenti di Windows ( tra blocchi, reboot infiniti e compagnia ) di quanti se ne avevano con Linux 5 anni fa.

[pabloski]

Originariamente inviato da Slayer86

ci si trova nel 2017 ad usare X come server grafico con 2 candidati per sostituirlo, che sono incompleti e mal supportati da ormai 7/8 anni.

Veramente Wayland e' di default su Fedora e presto lo sara' su Ubuntu e altre distribuzioni maggiori.

Il supporto da parte di Nviida, Intel e AMD e' arrivato. In tempo per integrare nel nuovo stack grafico pure Vulkan, cosi' risolviamo pure i problemi della grafica 3D.

Originariamente inviato da Slayer86

Una linea aziendale forte potrebbe al superamento di questi problemi, ma snaturerebbe il mondo Linux a tal punto che diventerebbe qualcos'altro.

Magari il successo di Linux ( perche' c'e' stato, e' innegabile ) e' in buona parte dovuto al non dover seguire le logiche "aziendali", da cattedrale, ovvero contrastare MS sul suo stesso terreno.

In tanti c'hanno provato prima di Linux, tante aziende, con sistemi operativi sviluppati in maniera "unitaria" e centralizzata. Risultato? Sono tutte sparite.

L'arte della guerra c'insegna che, contro un nemico piu' forte, bisogna fare la guerra asimmetrica. Combattere secondo le sue regole significa aver perso in partenza.

[pabloski]

Originariamente inviato da homoinformatico

Se a questo aggiungiamo la qualità delle nostre linee (il mio fetentissimo gestionale non và tanto bene manco con una vpn fibra/fibra), ti lascio immaginare la comodità di utilizzo di un sistema server/client.

L'amico sopra sogna ( senza offesa ovviamente ). La realta' del mitologico cloud e' questa http://www.hwupgrade.it/news/web/sky...oft_69448.html

Stiamo tornando indietro, altro che grande rivoluzione. Cioe', per le agenzie di spionaggio e' sicuramente una grande rivoluzione

[IngMetallo]

Originariamente inviato da pabloski

Magari il successo di Linux ( perche' c'e' stato, e' innegabile ) e' in buona parte dovuto al non dover seguire le logiche "aziendali", da cattedrale, ovvero contrastare MS sul suo stesso terreno.

In tanti c'hanno provato prima di Linux, tante aziende, con sistemi operativi sviluppati in maniera "unitaria" e centralizzata. Risultato? Sono tutte sparite.

L'arte della guerra c'insegna che, contro un nemico piu' forte, bisogna fare la guerra asimmetrica. Combattere secondo le sue regole significa aver perso in partenza.

Quanta filosofia in queste parole scusatemi se non ho seguito il ragionamento, ma queste parole mi son piaciute quindi up per te

[pabloski]

Originariamente inviato da IngMetallo

Quanta filosofia in queste parole scusatemi se non ho seguito il ragionamento, ma queste parole mi son piaciute quindi up per te

Grazie dell'up

Il discorso era il solito, cioe' Linux fa pena, Linux non ha i programmi, ecc... A parte che nel 2017 non e' vero tutto cio', molti comunque non realizzano che Linux e' figlio della logica comunitaria ( quella che Eric Raymond defini' la logica del bazaar ). Se Linux fosse nato come sistema operativo guidato dall'alto, sarebbe finito nel cestino accanto a BeOS, Taos/Intent, AmigaOS e tanti altri. Tutti sistemi superiori a Linux e Windows messi assieme, ma curiosamente tutti morti.

E probabilmente la comunita' ( il bazaar ) si sarebbe buttata su FreeBSD. Con l'attuale modello di sviluppo? Non credo proprio. Sarebbero nati millemila fork e ci ritroveremmo oggi a parlare della frammentazione di FreeBSD ( ma con qualche migliaio di driver in meno, courtesy of BSD license ).

Del resto erano quattro gatti e sono stati capaci di spaccare 386BSD in NetBSD, FreeBSD, 4.4BSD, OpenBSD, NextBSD, DesktopBSD, MidnightBSD, TrueOS, Rhapsody/Darwin, DragonflyBSD, ecc... Ed erano quattro gatti!!

[Slayer86]

Originariamente inviato da pabloski

Veramente Wayland e' di default su Fedora e presto lo sara' su Ubuntu e altre distribuzioni maggiori.

Il supporto da parte di Nviida, Intel e AMD e' arrivato. In tempo per integrare nel nuovo stack grafico pure Vulkan, cosi' risolviamo pure i problemi della grafica 3D.



Magari il successo di Linux ( perche' c'e' stato, e' innegabile ) e' in buona parte dovuto al non dover seguire le logiche "aziendali", da cattedrale, ovvero contrastare MS sul suo stesso terreno.

In tanti c'hanno provato prima di Linux, tante aziende, con sistemi operativi sviluppati in maniera "unitaria" e centralizzata. Risultato? Sono tutte sparite.

L'arte della guerra c'insegna che, contro un nemico piu' forte, bisogna fare la guerra asimmetrica. Combattere secondo le sue regole significa aver perso in partenza.

Si bhe, non so del supporto di Nvidia, ma fino a qualche mese fa ancora non c'era.

Il discorso su Wayland è roba freschissima e di Wayland si parla da almeno 10 anni. Ed indovina cosa ne ha rallentato diffusione e supporto? La decisione di Canonical di farsi il suo server grafico!

Concordo con te, l'essere così libero lo contraddistingue dal resto e non deve essere visto come una cosa sbagliata.
Però lo rende meno appetibile rispetto ad altre piattaforme perché più complesso sviluppare e mantenere un progetto.

Insomma poter fare autocritica costruttiva secondo me è l'aspetto che maggiormente manca nel mondo Linux. Oltre al fatto che non ci sono interessi economici forti nello sviluppare una user experience adeguata al 2017 (contrariamente alla parte kernel dove di interessi economici ce ne sono eccome...)

[pabloski]

Originariamente inviato da Slayer86

Il discorso su Wayland è roba freschissima e di Wayland si parla da almeno 10 anni. Ed indovina cosa ne ha rallentato diffusione e supporto? La decisione di Canonical di farsi il suo server grafico!

La vera ragione e' l'estrema complessita' di un server grafico, nonche' il fatto che Xorg ha migliaia di applicazioni che utilizzano il suo protocollo e fanno uso anche delle sue capacita' di rete. Queste ultime sono state eliminate, il che ha generato un grosso problema per le applicazioni legacy, tant'e' che si e' dovuto sviluppare XWayland.

In buona sostanza il ritardo e' dovuto a:

1. oggettiva complessita'
2. discussioni di natura tecnica e politica, nonche' lotte intestine
3. dover traghettare il software che usa X, cosa facile a parole ma difficile in pratica

Originariamente inviato da Slayer86

Concordo con te, l'essere così libero lo contraddistingue dal resto e non deve essere visto come una cosa sbagliata.

Il punto e' che non fosse cosi' libero, probabilmente sarebbe morto.

Originariamente inviato da Slayer86

Però lo rende meno appetibile rispetto ad altre piattaforme perché più complesso sviluppare e mantenere un progetto.

Windows lo e' di piu'. Basti pensare che hanno dovuto modificare git per far fronte alle necessita' della codebase di Windows ( ovviamente ad uso interno ).

Originariamente inviato da Slayer86

Insomma poter fare autocritica costruttiva secondo me è l'aspetto che maggiormente manca nel mondo Linux.

Non e' un problema solo di Linux. Guarda cosa sono stati Vista e Windows 8. E' dovuto cambiare il CEO per dare una raddrizzata parziale.

Almeno nel mondo Linux puoi forkare e se la comunita' ti segue hai vinto.

Originariamente inviato da Slayer86

Oltre al fatto che non ci sono interessi economici forti nello sviluppare una user experience adeguata al 2017 (contrariamente alla parte kernel dove di interessi economici ce ne sono eccome...)

Non c'e' interesse a svilupparlo per PC. Si considera che il PC e' un campo monopolizzato e oltretutto con vendite e utili in costante calo. E' come le zone bianche per il cablaggio in fibra. Se non c'entrava lo Stato coi suoi soldi, col cavolo che Tim, Vodafone e compagni c'avrebbero messo mano.

Ma non e' un ramo del tutto abbandonato, basti pensare che SuSE, Ubuntu, in parte Redhat se reggono su pc e workstation. Ma e' un settore molto marginale per Linux.

[Slayer86]

Originariamente inviato da pabloski

La vera ragione e' l'estrema complessita' di un server grafico, nonche' il fatto che Xorg ha migliaia di applicazioni che utilizzano il suo protocollo e fanno uso anche delle sue capacita' di rete. Queste ultime sono state eliminate, il che ha generato un grosso problema per le applicazioni legacy, tant'e' che si e' dovuto sviluppare XWayland.

In buona sostanza il ritardo e' dovuto a:

1. oggettiva complessita'
2. discussioni di natura tecnica e politica, nonche' lotte intestine
3. dover traghettare il software che usa X, cosa facile a parole ma difficile in pratica

Appunto, stai venendo nel mio discorso se si evitava il punto 2 non dico che ci voleva la metà ma almeno ora eravamo su un qualche cosa di più definitivo.
Magari si riusciva a fare il passaggio in tempo per rendere meno difficoltosa l'introdizione di gesture per schermi touch e touchpad evoluti.

Sicuramente avrebbe fatto bene a tutto il mondo linux.

Originariamente inviato da pabloski

Il punto e' che non fosse cosi' libero, probabilmente sarebbe morto.

Qui siamo d'accordo al 100%.

Originariamente inviato da pabloski

Windows lo e' di piu'. Basti pensare che hanno dovuto modificare git per far fronte alle necessita' della codebase di Windows ( ovviamente ad uso interno ).

Non e' un problema solo di Linux. Guarda cosa sono stati Vista e Windows 8. E' dovuto cambiare il CEO per dare una raddrizzata parziale.

Almeno nel mondo Linux puoi forkare e se la comunita' ti segue hai vinto.

Tuttavia questa libertà, è sia il motivo dell'esistenza, sia il motivo del mancato decollo in ambito consumer e workstation.

Originariamente inviato da pabloski

Non c'e' interesse a svilupparlo per PC. Si considera che il PC e' un campo monopolizzato e oltretutto con vendite e utili in costante calo. E' come le zone bianche per il cablaggio in fibra. Se non c'entrava lo Stato coi suoi soldi, col cavolo che Tim, Vodafone e compagni c'avrebbero messo mano.

Ma non e' un ramo del tutto abbandonato, basti pensare che SuSE, Ubuntu, in parte Redhat se reggono su pc e workstation. Ma e' un settore molto marginale per Linux.

Hanno quote piccolissime, purtroppo. È il classico cane che si morde la coda, niente programmi professionali (parlo di Adobe...) niente utenti, niente programmi, niente utenti...

Cmq siamo OT, direi che possiamo tornare a parlare di Rust / Redox che è comunque molto interessante come argomento!

[pabloski]

Originariamente inviato da Slayer86

Appunto, stai venendo nel mio discorso se si evitava il punto 2 non dico che ci voleva la metà ma almeno ora eravamo su un qualche cosa di più definitivo.

Ma non si puo' creare qualcosa senza discuterne. E quando gli interessi in ballo sono molteplici, e' normale che ci voglia tempo per mettersi d'accordo. Che poi non e' che siano solo interessi politici, ci sono anche differenze tecniche che vanno discusse e risolte nel modo migliore possibile.

Non dimentichiamo mai che Windows gira sui PC, Linux gira ovunque. Avere un server grafico che possa essere utilizzato su PC, smartphone, Raspberry e compagnia, controller industriali, sistemi per l'infotainment. Linux e' troppe cose per troppa gente, il che allunga i tempi di sviluppo di alcune tecnologie chiave.

Originariamente inviato da Slayer86

Tuttavia questa libertà, è sia il motivo dell'esistenza, sia il motivo del mancato decollo in ambito consumer e workstation.

Potrebbe essere uno dei motivi, ma sicuramente non l'unico e nemmeno il piu' rilevante.

Posso citarti almeno 4-5 OS closed-source, sviluppati secondo il modello a cattedrale, che hanno fallito su PC. E parliamo di OS estremamente validi ( BeOS ) o addirittura rivoluzionari ( TaOS ). Eppure, siamo ancora a zigzagare tra le Windows a quadroni.

Linux su PC e' una necessita' sentita? Sentita dall'utenza e quindi dagli OEM!?! Risolve quale problema esattamente? Perche' il succo e' questo. Stesso succo che sta alla base del flop di Windows su smartphone.

Originariamente inviato da Slayer86

Hanno quote piccolissime, purtroppo. È il classico cane che si morde la coda, niente programmi professionali (parlo di Adobe...) niente utenti, niente programmi, niente utenti...

E nessuna ragione che li spinga a migrare.

Originariamente inviato da Slayer86

Cmq siamo OT, direi che possiamo tornare a parlare di Rust / Redox che è comunque molto interessante come argomento!

Mica tanto OT. Redox per ora e' in sviluppo, e' un interessante concept. Poi bisognera' vedere se e quanto attecchira' nella comunita'.

[s-y]

come ho scritto altre volte, lo 'spezzatino' del pinguino fa parte della sua storia, anche per come è nato e si è sviluppato.
la cosa ha sia dei vantaggi che degli svantaggi, ma concordo che se l'impianto fosse stato meno aperto (ma con la licenza gpl che con la sua viralità ha fatto da 'collante') è probabile non sarebbe sopravvissuto (uso questo termine all'interno del discorso, poi altro che sopravvissuto. considerando gli 'odds' è stato una sorta di mezzo miracolo, tutt'altro che scontato, imho)