Redox OS

[Slayer86]

Originariamente inviato da fano

Beh potresti una cosa alla "Android" usi solo il kernel di Linux e sostituisci tutto l'user space con applicazioni scritte in Rust, ma per fare chiamate al kernel (leggere / scrive banalmente un file) devi chiamare la libc quindi... a che serve?



X in particolare è stato pensato negli anni '60 / '70 quando si pensava ancora che ci serebbe stato un mega-computer nello scantinato (un mostro tipo 286 con HDD da 40 MB ) e i PC client "stupidi" connessi a questo...

Per me anche il multi utente è un concetto superato i PC sono sempre più "personal"!



Esatto! Io sono piuttosto talebano loro permettono di far girare comunque applicazioni scritte in C/C++ cosa che in Cosmos non sarà MAI permessa...e io credo che questo sia un bene: quasi tutto il software scritto in C/C++ è stato concepito negli anni '60 / '70 prendiamo per esempio Firefox ci sarà ancora dentro codice derivato da Netscape se non - addirittura - da Mosaic
Ma comunque sono convinto che anche dentro Windows ci sia codice magari non toccato da secoli che deriva dai tempi del DOS (anni '70 / '80)

Concordo quasi su tutto, tranne la prima parte. Ovvero la parte relativa all'ibrido alla Android. Secondo me gran parte dei problemi di Android sono dovuti al suo essere ibrido. Tanto che Google sembra voglia cambiare direzione!

La questione multiutente invece, la manterrei... cioè la gestione unix dei multiutenti (intesi come utenti di sistema con determinati privilegi in determinate cartelle e servizi) è ottima!

[fano]

Originariamente inviato da Slayer86

Concordo quasi su tutto, tranne la prima parte. Ovvero la parte relativa all'ibrido alla Android. Secondo me gran parte dei problemi di Android sono dovuti al suo essere ibrido. Tanto che Google sembra voglia cambiare direzione!

Beh infatti è il kernel Linux il problema o per meglio dire il fatto che l'ABI sia totalmente instabile e quindi ha ogni versione di Android con nome di dolciume tutti i driver vadano completamente riscritti!
Anche la licenza di Linux non va bene per prodotti commerciali quindi è per questo che Google si sta facendo il suo kernel con nome di fiore sta volta

Per fare altri esempi dove GPL fu un'inc*lata i TV Sony un tempo usavano Linux come OS e erano costretti a rilasciare le patch che Sony aveva fatto al kernel per far funzionare i propri TV!

Oggi sia i TV Sony che PS4 hanno una versione modificata di Net BSD come OS e tanti saluti

Originariamente inviato da Slayer86

La questione multiutente invece, la manterrei... cioè la gestione unix dei multiutenti (intesi come utenti di sistema con determinati privilegi in determinate cartelle e servizi) è ottima!

Dipende da quale dispositivo vuoi fare un server sì forse (anche se secondo me la via moderna sono le "capabilities" non gli "utenti"), ma se fai dispositivi embedded come nel mio caso a che serve? Tra l'altro per fare praticamente qualsiasi cosa devi essere root su Linux!
Se fai un telefono (Android) cosa te ne fai del multi utente? Puoi avere dei profili magari questo sì, ma il resto del c*sino secondo me su Android non c'è mica...

Dico di più il multi utente non serve manco più su Desktop, nel mio PC di casa ci smanazzo solo io e la prima cosa che ho attivato è stata l'auto-login

[pabloski]

Originariamente inviato da fano

Beh infatti è il kernel Linux il problema o per meglio dire il fatto che l'ABI sia totalmente instabile e quindi ha ogni versione di Android con nome di dolciume tutti i driver vadano completamente riscritti!

Oddio, non e' che cambiano tutto ad ogni versione del kernel. Mi e' capitato di usare driver "vecchi" con nuove versioni del kernel. Certo la possibilita' di incompatibilita' e' sempre dietro l'angolo, ma e' una situazione voluta per costringere chi scrive i driver a rilasciarli come opensource.

Originariamente inviato da fano

Anche la licenza di Linux non va bene per prodotti commerciali quindi è per questo che Google si sta facendo il suo kernel con nome di fiore sta volta

Non direi visto il numero di prodotti commerciali basati su Linux. In fondo cosa si chiede? Di rendere GPL le patch. Mi pare il minimo visto che si sfrutta un kernel da 10 miliardi di dollari.

Originariamente inviato da fano

Oggi sia i TV Sony che PS4 hanno una versione modificata di Net BSD come OS e tanti saluti

Orbis e' basato su FreeBSD. Comunque che ci sarebbe di bello? Il fatto che il loro fork di FreeBSD ha driver eccellenti per le radeon integrate e FreeBSD non ne gode?

Mi sembra tanto che queste aziende si comportino da perfetti portoghesi.

Originariamente inviato da fano

Se fai un telefono (Android) cosa te ne fai del multi utente? Puoi avere dei profili magari questo sì, ma il resto del c*sino secondo me su Android non c'è mica...

Android invece sfrutta ampiamente il supporto alla multiutenza, basti notare che ogni app ha un proprio user e group id.

Originariamente inviato da fano

Dico di più il multi utente non serve manco più su Desktop, nel mio PC di casa ci smanazzo solo io e la prima cosa che ho attivato è stata l'auto-login

Se levi la multiutenza devi comunque implementare un altro sistemi per la separazione e la gestione dei diritti d'accesso alle risorse. Altrimenti si ritorna ai tempi del DOS, dove l'utente, le applicazioni e i servizi di sistema girano come medesimo utente e potevano fare di tutto. Vabbe' li' c'era il problema piu' grosso che tutto girava a ring-0.

[fano]

Beh ma parlando di systemd o delle "applettine" GNU tipo "mv" cosa te ne frega che siano chiamabili dall'esterno? Sono programmi a se stanti se vuoi fargli fare qualcosa chiami la system()

Tanti mica le hanno fatte bene anche adesso sai? Per esempio la funzione C "simlink()" si comporta diversamente da "ln -s" tanto che alla fine per avere il comportamento sensato ho dovuto usare system() se ti sembra un API ben fatta...

No, i motivi sul perché su Linux si usa il C sono "politici", nella mia azienda addirittura mi costringono a fare anche cose di alto livello che usando C++/C# farei in molto meno tempo tipo parsare file XML o interagire con un DB usando il C! Per me non ha senso...
io con C# senza dovermi concentrare continuamente sui "quirk" del linguaggio e invece su ciò che debbo fare sono 10 volte più produttivo
Solo per lo sviluppo di GUI si sono - con reticenza - convinti a farci usare C++ (il "dialetto" farlocco di Qt però)...

[pabloski]

Originariamente inviato da Bellaz89

linux ha sempre cercato di avere api e abi facilmente chiamabili da altri linguaggi.

Ovviamente c'e' anche questa ragione, tant'e' che l'ABI C e' di fatto quella standard e non e' un caso se tutti i linguaggi implementano FFI per il C.

Sull'efficienza si potrebbe discutere, perche' si puo' fare di meglio e alcuni linguaggi fanno di meglio.

Per il kernel ha tuttavia poco senso, in quanto la sua API e' esposta tramite INT o syscall. Tant'e' che ci sono kernel scritti in C++ e commerciale diffusissimi.

Originariamente inviato da Bellaz89

Certo, GHC permette comunque di creare interfacce Haskell <--> C Calling convention.. Io una volta l'ho fatto, ma è una grossa rottura di balle che assorbe un sacco di tempo. A quel punto non saprei se il gioco vale ancora la candela. Lo stesso vale con C++ dove puoi fare wrapper ad esempio di classi per C. E' piu' semplice, ma e' sempre lavoro in piu'

Ma va fatto una volta sola e lo si inserisce come parte del sistema operativo. Del resto al rovescio pure si fa, ovvero interfacciare Java, Haskell, Rust, ecc... con le librerie C. Non vedo perche' ci si debba fare problemi a fare il viceversa.

[fano]

Infatti visto che su questo Redox OS codice scritto in C/C++ ci gira avranno esattamente fatto così: dare la possibilità al C di chiamare codice scritto in Rust

[fano]

Originariamente inviato da Bellaz89

Penso che system() abbia un overhead maggiore che chiamare la funzione esposta direttamente dalla libc. In un caso crei un processo(almeno due syscall, di cui una e' una fork()), nell'altro fai una singola syscall. In alcuni casi questo e' accettabile. In altri no.

Ovviamente system() è più lento che chiamare una funzione dentro la libc però cosa ci posso fare se le funzione della libc fanno cose diverse? Uno si aspetterebbe che 'ln -s' chiamasse internamente symlink() invece si comportano completamente diversamente (symlink() in pratica non serva a nulla!), quindi usano codice differente!

Originariamente inviato da Bellaz89

Per le coreutils ti posso dare anche ragione (c'e' qualcuno che le sta riscrivendo in rust). Per systemd meno visto che esporta un'api

Vediamo come saranno accolte dalla community temo male non essendo fatte in C!

Originariamente inviato da Bellaz89

Non ho idea di cosa si occupi la tua azienda, quindi boh. Ci sta che sia una scelta dettata dall'inerzia.

Inerzia al 99% la mentalità della mia azienda è rimasta agli anni '60 / '70 io sono stato tacciato di troppo "modernismo" perché mi rifiuto di usare VIM e uso invece... GVIM

Ora siamo arrivati all'assurdo che è il cliente ad obbligarci ad usare Eclipse (la proprietà del codice è sua e vuole poterselo compilare anche da solo senza nel 2017 inoltrato dover smanazzare nel terminale) ovviamente si stanno studiando "truschi" per fargli credere che lo usiamo e poi continuare come al solito (G)VIM e Makefile

[GTKM]

Originariamente inviato da fano

Ovviamente system() è più lento che chiamare una funzione dentro la libc però cosa ci posso fare se le funzione della libc fanno cose diverse? Uno si aspetterebbe che 'ln -s' chiamasse internamente symlink() invece si comportano completamente diversamente (symlink() in pratica non serva a nulla!), quindi usano codice differente!



Vediamo come saranno accolte dalla community temo male non essendo fatte in C!



Inerzia al 99% la mentalità della mia azienda è rimasta agli anni '60 / '70 io sono stato tacciato di troppo "modernismo" perché mi rifiuto di usare VIM e uso invece... GVIM

Ora siamo arrivati all'assurdo che è il cliente ad obbligarci ad usare Eclipse (la proprietà del codice è sua e vuole poterselo compilare anche da solo senza nel 2017 inoltrato dover smanazzare nel terminale) ovviamente si stanno studiando "truschi" per fargli credere che lo usiamo e poi continuare come al solito (G)VIM e Makefile

Sarò sfigato io, ma con il C Eclipse è una tortura per me. Mi trovo molto meglio con Emacs (più tanti plugin), giuro.

Molto meglio QtCreator, anche per il codice C "puro", a 'sto punto.

[LukeIlBello]

Originariamente inviato da GTKM

Sarò sfigato io, ma con il C Eclipse è una tortura per me. Mi trovo molto meglio con Emacs (più tanti plugin), giuro.

Molto meglio QtCreator, anche per il codice C "puro", a 'sto punto.

io mi torvo bene con code::blocks

[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.

[GTKM]

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.

Io, invece, resto dell'idea che un dispositivo contenente i fatti miei debba restare in casa mia.
Questa voglia di tornare indietro da 50 anni non la capisco e non mi piace, ma tant'è.

Sulla prima parte del tuo discorso: scarica RHEL 7, con un account da sviluppatore (gratuito dall'anno scorso) e guarda se in quella distro noti "i soliti problemi di Linux". Quando c'è una seria volontà di portare avanti un progetto omogeneo, la licenza del codice è ininfluente.

[LukeIlBello]

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.

totalmente in disaccordo

tui vuoi tornare agli anni 70-80, ai client stupidi e alle informazioni che viaggiano (inutilmente) in rete...
vuoi regredire insomma

o sei giovane ( meno di 35 anni) e non sai di cosa parli, oppure sei un programmatore cobol over 60 che non riesce a trovare impiego

[LukeIlBello]

Originariamente inviato da GTKM

Io, invece, resto dell'idea che un dispositivo contenente i fatti miei debba restare in casa mia.
Questa voglia di tornare indietro da 50 anni non la capisco e non mi piace, ma tant'è.

Sulla prima parte del tuo discorso: scarica RHEL 7, con un account da sviluppatore (gratuito dall'anno scorso) e guarda se in quella distro noti "i soliti problemi di Linux". Quando c'è una seria volontà di portare avanti un progetto omogeneo, la licenza del codice è ininfluente.

bravo quoto tutto..
poi sti discorsi "i soliti problemi di linux"..
da gente che non l'ha mai usato oltretutto..

ah ma forse parla delle schermate blu? del registro crittato? no xchè non ho mica capito quali sono sti problemi

[Perseverance]

Originariamente inviato da LukeIlBello

bravo quoto tutto..
poi sti discorsi "i soliti problemi di linux"..
da gente che non l'ha mai usato oltretutto..

ah ma forse parla delle schermate blu? del registro crittato? no xchè non ho mica capito quali sono sti problemi

Ma che arroganza indicibile, ma che vòi? Tu sii educato e aperto nel confronto con gli altri, ma ti pare l'atteggiamento corretto da tenere su un forum? Esprimi le tue idee nel rispetto degli altri senza attacchi sul piano personale!

Mi aspettavo un confronto costruttivo, essendo nella sezione linux e alternativi, non mi è sembrato di dare un cattivo contributo esprimendo la mia idea. Oh che vi devo dì, volete buttalla in caciara, contenti voi...saluti...

[GTKM]

Originariamente inviato da Perseverance

Ma che arroganza indicibile, ma che vòi? Tu sii educato e aperto nel confronto con gli altri, ma ti pare l'atteggiamento corretto da tenere su un forum? Esprimi le tue idee nel rispetto degli altri senza attacchi sul piano personale!

Mi aspettavo un confronto costruttivo, essendo nella sezione linux e alternativi, non mi è sembrato di dare un cattivo contributo esprimendo la mia idea. Oh che vi devo dì, volete buttalla in caciara, contenti voi...saluti...

Mi scuso se anch'io ho dato l'impressione di volerla buttare in caciara, non era proprio la mia intenzione.

Per quanto riguarda i problemi di Linux e il mio consiglio di provare RHEL 7, beh, era appunto un consiglio. In quel caso si tratta di una distro di Red Hat, pienamente supportata e aggiornata per anni, e in quel caso diversi problemi vanno via.

Anche se io rimango innamorato di Slackware. Ma questo è soggettivo.

[LukeIlBello]

Originariamente inviato da Perseverance

Ma che arroganza indicibile, ma che vòi? Tu sii educato e aperto nel confronto con gli altri, ma ti pare l'atteggiamento corretto da tenere su un forum? Esprimi le tue idee nel rispetto degli altri senza attacchi sul piano personale!

Mi aspettavo un confronto costruttivo, essendo nella sezione linux e alternativi, non mi è sembrato di dare un cattivo contributo esprimendo la mia idea. Oh che vi devo dì, volete buttalla in caciara, contenti voi...saluti...

scusa ma, sto attacco sul personale, dopo aver riletto bene la mia risposta, non la rilevo

[matsnake86]

Originariamente inviato da GTKM

Mi scuso se anch'io ho dato l'impressione di volerla buttare in caciara, non era proprio la mia intenzione.

Per quanto riguarda i problemi di Linux e il mio consiglio di provare RHEL 7, beh, era appunto un consiglio. In quel caso si tratta di una distro di Red Hat, pienamente supportata e aggiornata per anni, e in quel caso diversi problemi vanno via.

Anche se io rimango innamorato di Slackware. Ma questo è soggettivo.

RHEL 7 e Centos 7 sono la stessa cosa vero?

[GTKM]

Originariamente inviato da matsnake86

RHEL 7 e Centos 7 sono la stessa cosa vero?

Ni. RHEL 7 è la versione "stabile e ufficiale" rilasciata da Red Hat, con aggiornamenti che arrivano direttamente dai loro repository, e supporto per 10 anni.

CentOS 7 e Fedora sono un po' i "laboratori" in cui viene testato ciò che, al momento opportuno, finirà in RHEL.

[pabloski]

Originariamente inviato da Perseverance

per me è solo un numero che si aggiunge ai numeri.

Qualunque progetto e' cosi' finche' non diventa un fenomeno di massa. Pure Linux nacque cosi', tant' che Torvalds scriveva:

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)"

Poi sappiamo com'e' finita, con gnu (hurd) che e' ancora in forse e linux che si e' esteso a macchia d'olio.

Difficilmente c'entra la bonta' tecnica, tant'e' che nel ramo informatico si dice un po' scherzosamente ( ma e' troppo spesso vero ) che sono i peggiori software a diffondersi maggiormente.

Originariamente inviato da Perseverance

Non vedo sbocco commerciale

Un kernel scritto in un linguaggio che spazza via tutti i piu' comuni bug ( e vulnerabilita' derivanti ) non ti sembra avere uno sbocco commerciale?

Originariamente inviato da Perseverance

continuo a vedere i soliti problemi dell'open di linux che prima o poi si affacceranno anche su redox.

Se ti riferisci a quelli che elenchi sotto, allora non hai compreso cos'e' Rust e in cosa aiuta. Rust non elimina la frammentazione della comunita', non fonde KDE e Gnome, non abolisce le distro. Rust si occupa di tutt'altro.

Originariamente inviato da Perseverance

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.

Guarda che la comunita' open e' appunto una comunita', non un'azienda. Quello che tu stai dicendo si potrebbe estendere alla societa'/comunita' umana e dire che questa fa pena perche' Tizio s'inventa il motore diesel e Caio quello a benzina.

Devi guardare alla comunita' opensource nella giusta prospettiva, che non e' quella di un'azienda. Se vuoi guardare dal punto di vista aziendale, allora osserva i sottoinsiemi della comunita', ad esempio Redhat, Canonical, System76, Intel. Allora vedrai che le cose procedono piu' o meno come con il closed source.

Originariamente inviato da Perseverance

mi piace l'idea di avere un megaserver da cui attingere risorse di calcolo e storage

Un'idea decotta, si chiamavano mainframe e furono sostituiti dai pc/workstation per ovvie ragioni.

La prima ragione e' l'avere un single point of failure. Certo le tecniche sono migliorate da allora, ma ogni tanto apri hwupgrade e leggi: "Amazon down, milioni di siti web offline".

Ecco, e' questo il futuro che vuoi? Senza contare gli evidenti problemi legati alla privacy e al tecnocontrollo.

E poi vuoi davvero mettere sullo stesso piano un NAS collegato alla tua rete locale o magari un hard disk/ssd connesso alla porta usb3 del tuo pc, con un sistema di storage raggiungibile via internet? Velocita', affidabilita', spreco di risorse. Questo e' il futuro che ti auguri?

E non parliamo delle risorse di calcolo. Il cloud in questo ambito puo' andare bene per le cazzatine da smartphone, ma t'immagini minare bitcoin inviando dati a destra e a manca ad una nuvola di server dall'altra parte del mondo? Le latenze ucciderebbero un rinoceronte.

Originariamente inviato da Perseverance

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.

Finche' non arriva il DDOS, un outage di un ISP, qualche furbone che modifica le tabelle BGP. E fu cosi' che il mondo si fermo'.

Ripeto, sono scenari ampiamente studiati e la conclusione e' che sono inadeguati in moltissimi casi. Arpanet ( madre di Internet ) fu progettata a partire dall'assioma che la centralizzazione e' il male e che la rete doveva essere il piu' possibile decentralizzata ( nelle connessioni e negli host/funzionalita' ).

Originariamente inviato da Perseverance

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.

Ma se c'ho provato a casa mia, con connessione fast ethernet e i lag sono vistosi. Stai dicendo che ogni utente dovrebbe avere un canale gigabit effettivo. Se in un'abitazione si connettono 3 persone contemporaneamente gia' va tutto all'aria. E ovviamente il server dall'altra parte dovrebbe avere una banda di decine di terabit.

Originariamente inviato da Perseverance

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

Veramente Rust ha gia' una visibilita' mostruosa https://redmonk.com/sogrady/2017/03/...rankings-1-17/

"Rust: One of the biggest overall gainers of any of the measured languages, Rust leaped from 47 on our board to 26"

Le sue qualita' risiedono nell'essere un linguaggio orientato alla generazione di programmi corretti e robusti, non c'e' nessun legame con cloud, mainframe e compagnia.

Originariamente inviato da Perseverance

e mi è sempre piacuta l'idea di estremizzare l'usabilità condivisa di risorse altrimenti sprecate.

Appunto, risorse condivise, non che mi azzeri il pc per trasferire tutto su server. Questo non e' condividere, e' uccidere.

Originariamente inviato da Perseverance

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.

Difficile che un software svincolato dalla macchina fisica possa anche essere efficiente. A meno di nuove invenzioni nel campo dei compilatori JIT.

C'e' stata un'azienda che ha fatto quello che dici, creando un'eccezionale OS che ( tra le altre cose, ma non era l'unica novita' ) consentiva la condivisione trasparente e nativa di risorse in rete. Si chiamava Taos/Intent, doveva essere il nuovo OS dell'Amiga...e' sparito!

https://en.wikipedia.org/wiki/Tao_Group#Intent

[fano]

Originariamente inviato da pabloski

Difficilmente c'entra la bonta' tecnica, tant'e' che nel ramo informatico si dice un po' scherzosamente ( ma e' troppo spesso vero ) che sono i peggiori software a diffondersi maggiormente.

Beh questa è una cosa "anomala" derivata da tutto ciò che è Unix di cui nel 2017 inoltrato dovremmo un po' liberarci via:

https://en.wikipedia.org/wiki/Worse_is_better

Originariamente inviato da pabloski

Un kernel scritto in un linguaggio che spazza via tutti i piu' comuni bug ( e vulnerabilita' derivanti ) non ti sembra avere uno sbocco commerciale?

Quoto questo in particolare perché lo trovo estremamente importante: perché sbattesi a rendere sicure applicazioni scritte in C/C++ linguaggi "unsafe by design"? Perché nel 2017 inoltrato non usare linguaggi pensati apposta per essere sicuri?

Io - personalmente - credo che sia meglio C# che Rust, ma ammetto che rispetto a C/C++ Rust è un enorme passo avanti!

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

Originariamente inviato da pabloski

C'e' stata un'azienda che ha fatto quello che dici, creando un'eccezionale OS che ( tra le altre cose, ma non era l'unica novita' ) consentiva la condivisione trasparente e nativa di risorse in rete. Si chiamava Taos/Intent, doveva essere il nuovo OS dell'Amiga...e' sparito!

https://en.wikipedia.org/wiki/Tao_Group#Intent

Amiga... che occasione sprecata