View Full Version : Redox OS
IngMetallo
29-04-2017, 19:30
Cosa ne pensate di questo sistema operativo scritto interamente in Rust ?
Io ho in mente un gigantesto turbine di idee positive: questo progetto potrebbe rivelarsi una grandissima novità tra qualche anno.
Nell'immediato è probabile che cominceremo a vedere componenti di Redox nei repository delle principali distribuzioni Linux.
https://www.redox-os.org/
ed in più aggiungo una bellissima intervista di Bryan Lunduke a Jeremy Stoller, lo sviluppatore principale di Redox: https://youtu.be/eH5JgMlNE8o
Non ne avevo mai sentito parlare, onestamente.
Mi sembra interessante. E il modo migliore per testare Rust a livello davvero basso per farlo competere col C puro.
pabloski
01-05-2017, 14:47
Cosa ne pensate di questo sistema operativo scritto interamente in Rust ?
Che hanno 2 OO grosse cosi', soprattutto considerando quanta roba hanno implementato in cosi' poco tempo.
La scelta di Rust direi che e' sensata, soprattutto e' un ottimo test bench per scovare eventuali problemi di design e bug nel linguaggio. Ovviamente e' una buona scelta pure per la correttezza del sistema operativo. Non e' un caso se sempre piu' progetti stanno scegliendo Rust, ultimo in ordine di tempo un client per la blockchain sviluppato dai creatori di Ethereum.
Infine posso dire finalmente...un microkernel tra quelli alternativi e open. Una svecchiata ci voleva proprio.
Nell'immediato è probabile che cominceremo a vedere componenti di Redox nei repository delle principali distribuzioni Linux.
Dipende da quali componenti hai in mente. Il kernel Linux non credo verra' mai scalfito, almeno finche' sara' in vita Torvalds. Ha idee molto rigide in merito a kernel e linguaggi che ( secondo lui ) hanno l'onore di poterlo codificare.
IngMetallo
14-05-2017, 08:03
Che hanno 2 OO grosse cosi', soprattutto considerando quanta roba hanno implementato in cosi' poco tempo.
Oh che bello, allora non sono l'unico a pensarlo :cool:
Altra cosa interessante è che Jeremy Stoller, il ragazzo che ha sviluppato Redox, lavora anche per System76: tra qualche anno sono sicuro che vedremo finalmente dei portatili, prodotti ufficialmente con sistemi opensource (GNU/Linux, Redox), estremamente validi.
La scelta di Rust direi che e' sensata, soprattutto e' un ottimo test bench per scovare eventuali problemi di design e bug nel linguaggio. Ovviamente e' una buona scelta pure per la correttezza del sistema operativo. Non e' un caso se sempre piu' progetti stanno scegliendo Rust, ultimo in ordine di tempo un client per la blockchain sviluppato dai creatori di Ethereum.
Infine posso dire finalmente...un microkernel tra quelli alternativi e open. Una svecchiata ci voleva proprio.
Esatto, ultimamente con Rust ci si stanno divertendo parecchi sviluppatori :D chissà se diventerà "lo Javascript della programmazione di basso livello" ?
Dipende da quali componenti hai in mente. Il kernel Linux non credo verra' mai scalfito, almeno finche' sara' in vita Torvalds. Ha idee molto rigide in merito a kernel e linguaggi che ( secondo lui ) hanno l'onore di poterlo codificare.
Nel video lui si riferisce a code del tipo: sistema audio (che dovrà risviluppare in Rust), applicazioni di sistema (file manager, image viewer,...),...
pabloski
14-05-2017, 09:00
Altra cosa interessante è che Jeremy Stoller, il ragazzo che ha sviluppato Redox, lavora anche per System76
Non lo sapevo. Quindi c'e' la possibilita' che sia uno di quei progetti tipo Fuchsia, cioe' creati da gruppi interni ad un'azienda ma con una sorta di interesse da parte dell'azienda stessa.
Esatto, ultimamente con Rust ci si stanno divertendo parecchi sviluppatori :D chissà se diventerà "lo Javascript della programmazione di basso livello" ?
Direi che l'inizio e' promettente. Del resto non ci sono altri linguaggi che garantiscono una simile robustezza e senza una qualche sorta di VM/meccanismo a runtime.
Il linguaggio e' unico nel suo genere, c'e' poco da aggiungere su questo.
Nel video lui si riferisce a code del tipo: sistema audio (che dovrà risviluppare in Rust), applicazioni di sistema (file manager, image viewer,...),...
Anche in questo caso bisognera' vincere le resistenze dei padroni di LInux.
Voglio dire, Systemd sviluppato in C. A nessuno e' venuto in mente che e' una cazzata colossale? Usare Haskell ( per esempio ) era troppo difficile? Visto il ruolo ricoperto da Systemd e il fatto che Haskell sia un linguaggio pensato per garantire correttezza ai programmi ( non ai livelli di Rust ma mille volte meglio di C ), sarebbe stata una scelta ovvia.
Invece l'ecosistema Linux continua ad essere C-centrico e i suoi padroni ( Redhat in testa ) non sembrano interessati a cambiare la situazione.
E' un problema di mentalita' in buona sostanza. Basti notare che non hanno mai nemmeno minimamente investito in cose come un framework a la WPF. QT e' l'unico che gli si avvicina, ma GTK+? E' chiaro che vivono negli anni '70 e non vogliono uscirne.
Non lo sapevo. Quindi c'e' la possibilita' che sia uno di quei progetti tipo Fuchsia, cioe' creati da gruppi interni ad un'azienda ma con una sorta di interesse da parte dell'azienda stessa.
Direi che l'inizio e' promettente. Del resto non ci sono altri linguaggi che garantiscono una simile robustezza e senza una qualche sorta di VM/meccanismo a runtime.
Il linguaggio e' unico nel suo genere, c'e' poco da aggiungere su questo.
Anche in questo caso bisognera' vincere le resistenze dei padroni di LInux.
Voglio dire, Systemd sviluppato in C. A nessuno e' venuto in mente che e' una cazzata colossale? Usare Haskell ( per esempio ) era troppo difficile? Visto il ruolo ricoperto da Systemd e il fatto che Haskell sia un linguaggio pensato per garantire correttezza ai programmi ( non ai livelli di Rust ma mille volte meglio di C ), sarebbe stata una scelta ovvia.
Invece l'ecosistema Linux continua ad essere C-centrico e i suoi padroni ( Redhat in testa ) non sembrano interessati a cambiare la situazione.
E' un problema di mentalita' in buona sostanza. Basti notare che non hanno mai nemmeno minimamente investito in cose come un framework a la WPF. QT e' l'unico che gli si avvicina, ma GTK+? E' chiaro che vivono negli anni '70 e non vogliono uscirne.
Il problema è che Torvalds è una figura ingombrante, e ha deciso che il C è l'unico linguaggio accettato e accettabile per il kernel.
GNU era interamente scritto in C, e ora chi lo rifà da zero? Per il resto, come hai detto, gran parte dei progetti continuano ad essere realizzati con quel linguaggio, a prescindere.
pabloski
14-05-2017, 12:03
Il problema è che Torvalds è una figura ingombrante, e ha deciso che il C è l'unico linguaggio accettato e accettabile per il kernel.
Poettering e soci nemmeno scherzano. L'unico che ha cambiato idea e' stato de Icaza, visto che e' partito da GTK/C ed e' arrivato a Mono/C#.
GNU era interamente scritto in C, e ora chi lo rifà da zero?
Sarebbe un buon inizio cominciare ad usare linguaggi piu' moderni per i nuovi progetti. Non c'era nessuna ragione per usare C per Systemd.
E poi l'userland e' ovviamente complessa, ma considera che Busybox la implementa quasi tutta, quindi rifarla e' possibile.
Poettering e soci nemmeno scherzano. L'unico che ha cambiato idea e' stato de Icaza, visto che e' partito da GTK/C ed e' arrivato a Mono/C#.
Sarebbe un buon inizio cominciare ad usare linguaggi piu' moderni per i nuovi progetti. Non c'era nessuna ragione per usare C per Systemd.
E poi l'userland e' ovviamente complessa, ma considera che Busybox la implementa quasi tutta, quindi rifarla e' possibile.
Infatti anch'io concordo sul fatto che il problema non sia tecnico, ma psicologico.
Torvalds è un talebano che accetta solo quello che va bene a lui, non ciò che è meglio. E molti altri nella comunità sono come lui. Effettivamente, systemd è un esempio eclatante in tal senso (ma non l'unico).
Praticamente l'intero userland è in C, quando va di c*lo si vede un po' di C++, ma difficilmente altro.
pabloski
14-05-2017, 14:25
Infatti anch'io concordo sul fatto che il problema non sia tecnico, ma psicologico.
Torvalds è un talebano che accetta solo quello che va bene a lui, non ciò che è meglio. E molti altri nella comunità sono come lui. Effettivamente, systemd è un esempio eclatante in tal senso (ma non l'unico).
Praticamente l'intero userland è in C, quando va di c*lo si vede un po' di C++, ma difficilmente altro.
C'e' anche un problema relativo alla logica del "se funziona lascialo stare". Un progetto di riammodernamento di Linux ( kernel escluso perche' sarebbe davvero apocalittico a quel punto ) e' un progetto colossale e nessuno vuole imbarcarcisi.
Questo pero' crea un circolo vizioso, per cui l'interazione tra componenti deve seguire le regole del C ( in particolare per le librerie a collegamento dinamico ), il che ti conduce o ad usare linguaggi C-like o andare di FFI.
L'altro problema riguarda sempre le librerie e concerne il fatto che comunque e' codice unsafe, molto codice unsafe, che vanificherebbe all'atto pratico l'uso di linguaggi safe. Come se uno realizzasse un programma C#, dove il codice effettivamente eseguito, e' al 90% contenuto in librerie C. Praticamente inutile dal punto di vista della sicurezza.
E' cosi' che la lobby C trova valide scuse per continuare sulla strada vecchia. Poi vabbe' siamo nel bel mezzo di un cataclisma, con l'affermarsi di virtualizzazione, sistemi di containerizzazione come docker e la diffusione del browser come runtime di default ( vedi Electron ). Per cui non crede che quest'andazzo continuera' in eterno.
C'e' anche un problema relativo alla logica del "se funziona lascialo stare". Un progetto di riammodernamento di Linux ( kernel escluso perche' sarebbe davvero apocalittico a quel punto ) e' un progetto colossale e nessuno vuole imbarcarcisi.
Questo pero' crea un circolo vizioso, per cui l'interazione tra componenti deve seguire le regole del C ( in particolare per le librerie a collegamento dinamico ), il che ti conduce o ad usare linguaggi C-like o andare di FFI.
L'altro problema riguarda sempre le librerie e concerne il fatto che comunque e' codice unsafe, molto codice unsafe, che vanificherebbe all'atto pratico l'uso di linguaggi safe. Come se uno realizzasse un programma C#, dove il codice effettivamente eseguito, e' al 90% contenuto in librerie C. Praticamente inutile dal punto di vista della sicurezza.
E' cosi' che la lobby C trova valide scuse per continuare sulla strada vecchia. Poi vabbe' siamo nel bel mezzo di un cataclisma, con l'affermarsi di virtualizzazione, sistemi di containerizzazione come docker e la diffusione del browser come runtime di default ( vedi Electron ). Per cui non crede che quest'andazzo continuera' in eterno.
Diciamo che non hanno sempre tutti i torti, e diciamo anche che molto spesso le colpe del C sarebbero da addebitare agli sviluppatori.
Per dire, glibc per qualche motivo ignoto spesso rompeva la compatibilità, o aggiungeva cose del tutto inutili.
Non è che, se fosse stata scritta in Rust, Drepper sarebbe diventato sano di mente, ecco.
Poi bisogna vedere anche tante altre cose: per dire, hai migliaia di sviluppatori cresciuti a pane e C, è difficile che inizino un progetto grosso con un linguaggio del tutto nuovo, perché molti non hanno la necessaria elasticità mentale.
Poi bisogna anche vedere con cosa sostituisci il vecchio: per intenderci, per ora c'è la mania di voler usare JavaScript per qualsiasi stron*ata. Ecco, calmiamoci. Sono invece curioso di capire se Rust potrà davvero sostituire il C, almeno finalmente la vagonata di gente che in 40 anni non ha ancora capito l'aritmetica dei puntatori avrà un problema in meno. :D
LukeIlBello
25-05-2017, 12:58
non capisco l'astio di pabloski nei confronti del C..
va bene che il linguaggio è difficile per chi non sa allocare correttamente
i puntatori...
ma se usato correttamente è un signor linguaggio...
adesso cmq mi vado ad erudire su RUST (di cui ammetto l'ignoranza :sofico: )
pabloski
25-05-2017, 13:32
non capisco l'astio di pabloski nei confronti del C..
va bene che il linguaggio è difficile per chi non sa allocare correttamente
i puntatori...
ma se usato correttamente è un signor linguaggio...
ovviamente si puo' usare, ma il punto e' che il cervello umano non e' progettato per mantenere il controllo totale ( oltretutto sull'insieme e contemporaneamente sui dettagli ) sui sistemi complessi
il software e' un sistema complesso, un kernel di un sistema operativo lo e' ai massimi livelli
e il C non fornisce alcuno strumento per aiutare il programmatore nel mantenere il controllo su tali sistemi
in teoria si puo' dire che usare il linguaggio correttamente, scrivere il codice con attenzione, puo' evitare qualsiasi bug
nella pratica la situazione e' nettamente differente e non e' affatto raro commettere errori stupidi che portano ad inserire bug e vulnerabilita', anche tra le piu' ovvie come i buffer overflow
il C non ti da' nulla per difenderti da tutto cio', Rust ti da' una batteria di meccanismi invece, che ti difendono dai piu' comuni errori di programmazione fino ai casini generati dalla gestione della concorrenza
Slayer86
26-05-2017, 08:46
Chissà se con questo progetto nasceranno anche una serie di librerie moderne e ben documentate. Sarebbe il caso anche di restringere un minimo le opzioni offerte a favore di una soluzione nettamente superiore alle altre.
A mio parere è il problema numero 1 ad oggi sul mondo linux (forse figlio dei fondamentalismi elencati sopra...)
Comunque stanno implementando una marea di roba e lo stanno facendo impiegando pochissimo tempo. Sono davvero dei mostri!
pabloski
26-05-2017, 08:54
Sono davvero dei mostri!
Vero ma forse sara' anche dovuto al fatto che...
Comunque stanno implementando una marea di roba e lo stanno facendo impiegando pochissimo tempo.
...Rust e' un linguaggio tremendamente espressivo, cosa che C non e' ( ad esempio ).
Slayer86
26-05-2017, 22:29
Vero ma forse sara' anche dovuto al fatto che...
...Rust e' un linguaggio tremendamente espressivo, cosa che C non e' ( ad esempio ).
Si immagino ma qui parlano di aver implementato un filesystem con hash di controllo integrità dei dati. Driver nvme e usb3, cache basata su algoritmi di machine learning.
Ammettiamo che il linguaggio di base sia 10 volte più espressivo del C, questi sono in 2 ed hanno tirato su un sistema operativo da 0 che ha pure un server grafico ed un gestore di temi.
I casi sono 2 o sono davvero delle bestie e non vedono la luce del sole da anni... oppure nel mondo open come lo sonosciamo noi c'è qualche cosa che non va, tipo un freno tirato, un paracadute aperto... non saprei (canonica in 5/6 anni non ha cacciato fuori un DE)
pabloski
27-05-2017, 15:17
Si immagino ma qui parlano di aver implementato un filesystem con hash di controllo integrità dei dati. Driver nvme e usb3, cache basata su algoritmi di machine learning.
l'ultima parte e' la piu' facile :D
beh certo hanno sviluppato un bel po' di roba non ci piove, ma quanti sono esattamente? e che esperienza hanno?
voglio dire, Travis Geiselbrecht sviluppo' nel tempo libero NewOS, microkernel usato poi dal progetto Haiku, poi se ne venuto fuori con Fuchsia ( si quello di Google )
era un ingegnere della Be, quindi ha lavorato su BeOS e praticamente scrive sistemi operativi ad occhi chiusi, un tizio con molta molta esperienza insomma
Ammettiamo che il linguaggio di base sia 10 volte più espressivo del C, questi sono in 2 ed hanno tirato su un sistema operativo da 0 che ha pure un server grafico ed un gestore di temi.
ho letto che lavorano per system76, l'azienda che produce computer con linux preinstallato
quindi e' gente che conosci i propri polli
poi non credere che l'espressivita' del linguaggio non aiuti, soprattutto la standard library puo' fare parecchia differenza
per esempio una cosa e' avere un'implementazione bella pronta delle hash table, ben diverso e' doverla creare da zero
stesso discorso per array a dimensione dinamica e altre strutture dati che semplifica notevolmente gli sforzi di programmazione
I casi sono 2 o sono davvero delle bestie e non vedono la luce del sole da anni... oppure nel mondo open come lo sonosciamo noi c'è qualche cosa che non va, tipo un freno tirato, un paracadute aperto... non saprei (canonica in 5/6 anni non ha cacciato fuori un DE)
nel mondo open linux e' la retrocompatibilita' con unix che ha tirato il freno
e' noto che molti dei meccanismi unix ( a cominciare da pipe, thread, mutex, condvar, i/o di rete ) sono obsoleti e verbosi
solo per aprire una socket bisogna settare un paio di strutture e chiamare 4-5 funzioni, la gestione dell'i/o concorrente e' un orrendo pastrocchio
suppongo che quelli di redox abbiano tagliato un bel po' di schifezze, ma non ho approfondito la faccenda
interessante
lato telefoni (drv delle periferiche permettendo) potrebbe esserci qualche 'sbocco indiretto'?
btw magari è attinente, la system76 da quel poco che ho visto ha una organizzazione peculiare, praticamente se non ricordo male lavorano jit
Io conseglerei loro di occuparsi del loro kernel e basta cercare di "migliorare" Linux è una battaglia persa rischierebbero anche di tirarsi addosso le ire sia del "Malevolo Dittatore a Vita" ( :D ) che di altra gente della community!
Poi secondo me creare "ibridi" non è mai la soluzione il problema di Linux è il kernel e quello di certo non puoi riscriverlo in Rust!
P.S.
Comunque a me la sintassi di Rust sembra ancora più incasinata del C... non mi ci trovo con tutti quegli '&', i 2 - 3 modi diversi per rappresentare le stringhe...
Slayer86
29-05-2017, 15:29
Bhe perché la parte GNU dei sistemi GNU/linux come già indicato? Non è incasinata ed immodificabile?
Ed il server grafico? Con annessi driver proprietari e non? Diciamoci la verità non ci sono gli interessi per riscrivere tutto (e sarebbe una discreta follia) però i sistemi operativi concorrenti ad ogni major release ripartono con progetti nuovi, o comunque in buna percentuale nuovi.
DEVONO assolutamente puntare sul loro kernel e creare il loro ecosistema.
Poi si vedrà, con le web app moderne si possono avere in breve tempo un set di applicazioni bello completo per poter partire!
Bhe perché la parte GNU dei sistemi GNU/linux come già indicato? Non è incasinata ed immodificabile?
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?
Ed il server grafico? Con annessi driver proprietari e non? Diciamoci la verità non ci sono gli interessi per riscrivere tutto (e sarebbe una discreta follia) però i sistemi operativi concorrenti ad ogni major release ripartono con progetti nuovi, o comunque in buna percentuale nuovi.
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 :eek:) e i PC client "stupidi" connessi a questo...
Per me anche il multi utente è un concetto superato i PC sono sempre più "personal"!
DEVONO assolutamente puntare sul loro kernel e creare il loro ecosistema.
Poi si vedrà, con le web app moderne si possono avere in breve tempo un set di applicazioni bello completo per poter partire!
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 :eek:
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) :D
Slayer86
30-05-2017, 14:50
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 :eek:) 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 :eek:
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) :D
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!
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 :D
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 :)
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 :D
pabloski
30-05-2017, 18:33
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.
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 :D
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.
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.
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.
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 :D
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.
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() :D
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 :muro:
Solo per lo sviluppo di GUI si sono - con reticenza - convinti a farci usare C++ (il "dialetto" farlocco di Qt però)...
pabloski
31-05-2017, 09:16
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.
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.
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 :D
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!
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!
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 :eek:
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 :muro:
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 :eek:
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 :muro:
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. :D
LukeIlBello
01-06-2017, 12:21
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. :D
io mi torvo bene con code::blocks :D
Perseverance
01-06-2017, 13:19
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.
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
01-06-2017, 14:21
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 :doh:
tui vuoi tornare agli anni 70-80, ai client stupidi e alle informazioni che viaggiano (inutilmente) in rete...
vuoi regredire insomma :muro:
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 :read:
LukeIlBello
01-06-2017, 14:23
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 :asd:
Perseverance
01-06-2017, 19:52
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 :asd:
Ma che arroganza indicibile, ma che vòi? :confused: 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...
Ma che arroganza indicibile, ma che vòi? :confused: 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. :D
Anche se io rimango innamorato di Slackware. Ma questo è soggettivo.
LukeIlBello
02-06-2017, 11:46
Ma che arroganza indicibile, ma che vòi? :confused: 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 :asd:
matsnake86
02-06-2017, 12:59
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. :D
Anche se io rimango innamorato di Slackware. Ma questo è soggettivo.
RHEL 7 e Centos 7 sono la stessa cosa vero?
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
02-06-2017, 14:28
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.
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?
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.
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.
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.
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' ).
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.
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/17/language-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.
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.
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
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
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à :D
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 :cry:
pabloski
05-06-2017, 09:42
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.
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
Ma un "language based OS" offre ulteriori vantaggi sia per quanto riguarda la sicurezza che per quanto riguarda la velocità :D
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.
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!).
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 :D)
Leggi qui:
http://joeduffyblog.com/2015/12/19/safe-native-code/
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 :D
Il risultato e' questo http://benchmarksgame.alioth.debian.org/u64q/rust.html
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
05-06-2017, 13:11
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 :sofico:
pabloski
05-06-2017, 13:43
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.
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.
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.
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...
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!
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).
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
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?)
Per ora credo che attirera' soprattutto i fan di Rust, quindi...
Me lo auguro per loro... io ormai vedo C/C++ come virus :D
(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
05-06-2017, 16:51
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#.
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.
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.
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.
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.
(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.
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:
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)
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/9f39124f6f-rust-array-access-is-bound-checked-at-runtime
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++ :D) e avremo degli unit test appositi per verificare che funzioni in maniera corretta...
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/blob/master/source/Cosmos.HAL/Drivers/Video/VBEDriver.cs
(low level non accessibile all'utente)
https://github.com/CosmosOS/Cosmos/blob/master/source/Cosmos.System/Graphics/VBEScreen.cs
Redox:
https://github.com/redox-os/drivers/blob/master/bgad/src/bga.rs
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 :cry: ) avendo un campo len si avrebbe ottenuto 2 vantaggi:
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!
Pure più efficente visto che tutte le varie strXXX fanno dei gran for() / while() per cercare il famoso tappo '\0' sbordando - sovente - nel processo
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 :D
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 :D
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 :D ?)
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
19-06-2017, 12:36
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 è...
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
20-06-2017, 09:06
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
20-06-2017, 09:44
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.
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.
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.
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
20-06-2017, 09:49
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.
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
20-06-2017, 10:03
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/skype-down-in-italia-e-non-solo-problemi-di-connessione-per-la-piattaforma-di-microsoft_69448.html
Stiamo tornando indietro, altro che grande rivoluzione. Cioe', per le agenzie di spionaggio e' sicuramente una grande rivoluzione :D
IngMetallo
20-06-2017, 15:55
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 :D scusatemi se non ho seguito il ragionamento, ma queste parole mi son piaciute quindi up per te :cincin:
pabloski
20-06-2017, 16:03
Quanta filosofia in queste parole :D scusatemi se non ho seguito il ragionamento, ma queste parole mi son piaciute quindi up per te :cincin:
Grazie dell'up :D
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
20-06-2017, 17:36
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
20-06-2017, 17:45
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
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.
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 ).
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.
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
20-06-2017, 23:26
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.
Il punto e' che non fosse cosi' libero, probabilmente sarebbe morto.
Qui siamo d'accordo al 100%.
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.
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! :D
pabloski
21-06-2017, 09:27
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.
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.
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.
Cmq siamo OT, direi che possiamo tornare a parlare di Rust / Redox che è comunque molto interessante come argomento! :D
Mica tanto OT. Redox per ora e' in sviluppo, e' un interessante concept. Poi bisognera' vedere se e quanto attecchira' nella comunita'.
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)
pabloski
21-06-2017, 16:40
la licenza gpl che con la sua viralità ha fatto da 'collante'
Ahi ahi, per fortuna che da queste parti non ci sono molti fanboy della BSD.
Che pero' impietriscono quando gli faccio notare che nemmeno una riga di codice di quello stupendo driver Radeon per la PS4 e' percolata nel mainline di FreeBSD :D
in realtà non ho una posizione al riguardo :D
anche nel caso della licenza, vantaggi e svantaggi che convivono
...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 :eek:) e i PC client "stupidi" connessi a questo...
Per me anche il multi utente è un concetto superato i PC sono sempre più "personal"!
e il cloud? :stordita: a me sembra che invece si stia tornando al modello dei "terminali stupidi", anche se tecnicamente è un'assurdità vista la potenza a disposizione.
...nel mondo open come lo conosciamo noi c'è qualche cosa che non va, tipo un freno tirato, un paracadute aperto... non saprei (canonica in 5/6 anni non ha cacciato fuori un DE)
beh, il vantaggio di essere in pochi e che decidi che fare e lo fai, ed il risultato in genere è anche coerente e unitario.
i progetti open che avanzano + veloci spesso sono quelli dove uno dirige e pochi altri scrivono. Mettere inseme migliaia di teste invece ha dei pro, ma anche dei contro. :)
...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.
condivido, anche se direi piuttosto sanguisughe
IngMetallo
22-06-2017, 11:04
Negli ultimi anni (merito anche di SteamOS ed AMD che ha abbracciato la filosofia open-source) il supporto GPU su Linux è migliorato enormemente. Penso siano un paio di anni che le GPU Nvidia girano benissimo tramite driver proprietari.
Riguardo Canonical abbiamo assistito ad un loro miracoloso cambio di mentalità, se tutto va bene l'ecosistema GNU/Linux avrà un'ulteriore accelerata allo sviluppo merito di tanti fattori:
il team di Canonical già è al lavoro su Gnome per raffinarlo ulteriormente
system76* che sta spingendo molto con i suoi laptop basati su Ubuntu, con storie di successo anche in un'azienda importante come la Pixar (qui un mini-tour (https://youtu.be/80zhEF1zrw8?t=3m58s) alla loro piccola ma preziosa Hall of Fame :D)
SteamOS che continua a lavorare sull'ottimizzazione di sistema (anche se il progetto non è pubblicizzato, il team che c'è dietro lavora costantemente)
progetti come Redox OS che si spera possa portare idee innovative ed un modello di sviluppo più rapido e moderno, contribuendo allo stesso tempo con tutti i software che saranno compatibili anche su distribuzioni Linux
* tra l'altro hanno qualcosa di grosso in cantiere, di cui possiamo specularne su questo thread: Open-Source-Revolution 76 (http://www.hwupgrade.it/forum/showthread.php?t=2819336e)
...Riguardo Canonical abbiamo assistito ad un loro miracoloso cambio di mentalità, se tutto va bene l'ecosistema GNU/Linux avrà un'ulteriore accelerata allo sviluppo
hanno tempo fino al termine del periodo di supporto di win7... :D
pabloski
22-06-2017, 11:49
progetti come Redox OS che si spera possa portare idee innovative ed un modello di sviluppo più rapido e moderno, contribuendo allo stesso tempo con tutti i software che saranno compatibili anche su distribuzioni Linux
Spero non si lascino tentare dal software facile. L'innovazione e' la chiave di quell'OS, mettersi a portare roba Linux o BSD sarebbe un disastro.
Che seguano la loro strada, visto che o per capacita' o per buon design o per gli strumenti di sviluppo usati ( o per tutte queste cose messe assieme ), il loro OS ha raggiunto un livello di completezza molto alto nel poco tempo a disposizione.
Infatti potrebbe avere senso portare software scritto in Rust su Linux (e Windows ovviamente), ma come ho detto temo che la community Linux non lo apprezzerebbe: direbbe che è "lento" visto che non va in core a caso...
L'incontrario invece - portare software GNU fatto con l'insensata filosofia del "Peggio è Migliore" - su Redox sarebbe un disastro come dice pabloski :cry:
I problemi di usare codice GNU a parte la "questionabile" qualità di molto di quel software sono 2:
Sono scritti in C e se stai facendo un OS safe devi almeno "incatenarli" dentro una sandbox... se no tanto valeva che manco lo facevi il SO con Rust
Molti hanno path "Unix" hardcoded e se non ti sbatti a fare un porting come si deve o fai come MacOS che "di nascosto" hai /etc, /usr/local, ... o fai come Haiku e muori nel tentativo di fare un package manager per nascondere sotto al tappeto quella bratta :cry:
eclissi83
02-07-2017, 23:41
Ahi ahi, per fortuna che da queste parti non ci sono molti fanboy della BSD.
fanboy no, ma qualcuno che apprezza la licenza BSD c'è. :D
la viralità della GPL è il suo miglior pregio ed anche il suo peggior difetto, perché se da un lato obbliga chi modifica il sorgente al rilascio del codice senza modifiche alla licenza, dall'altro allontana chi vuole farci modifiche rilasciandole con una licenza diversa.
la licenza BSD, a differenza della GPL, non si preoccupa di proteggere la libertà del software, quanto piuttosto che il software sia libero, accessibile e modificabile.
il risultato è che il software rilasciato sotto licenza BSD può essere incluso in software con licenza non libera, con l'obbligo di non modificare la licenza originale e di citare l'autore d'origine.
teniamo presente che le licenze BSD [a 3 e 2 clausole] rispettano i 4 punti fondamentali della licenza GPL e quindi sono qualificate dalla FSF come licenze di software libero a tutti gli effetti.
entrambe hanno pregi e difetti e non mi sento di condannare una delle due.
Che pero' impietriscono quando gli faccio notare che nemmeno una riga di codice di quello stupendo driver Radeon per la PS4 e' percolata nel mainline di FreeBSD :D
beh, d'altro canto, la viralità della GPL non mi pare sia riuscita a convincere nvidia a rilasciare il suo proprietarissimo driver come software libero :)
tornando a Redox, credo che bisogna incoraggiare gli sviluppatori perché la loro sperimentazione può portare a miglioramenti per tutti, anche senza tutte le - sepppur giustissime - discussioni tecniche su C/C++/C# e via discorrendo.
non conosco rust come linguaggio, ma mi sembra che stia avendo un giustificatissimo seguito, date le sue pecularietà.
posso solo augurare il massimo al team di sviluppo di rust e di Redox-os
pabloski
03-07-2017, 09:08
fanboy no, ma qualcuno che apprezza la licenza BSD c'è. :D
Ha la sua ragion d'essere, che e' pero' incentrata sugli interessi delle multinazionali piuttosto che su quelli della comunita'. La GPL sara' rompigliona, pero' realisticamente e' la ragione per cui oggi abbiamo un'ecosistema open che consente di usare i computer sul serio.
Forzare le multinazionali a cooperare ha consentito a Linux di crescere. In caso contrario ho il fondato sospetto che avremmo ancora un sistema operativo con driver vesa e niente grafica 3D.
Citavo appunto l'esempio di OrbisOS perche' e' molto indicativo di come le multinazionali concepiscano l'opensource. Cioe' tu scrivi, io prendo, impacchetto e vendo.
Ovviamente nessuna condanna. E sono convinto che un progetto non GPL, oggi, potrebbe sfondare come Linux ( o anche di piu' ), ma perche' ormai e' diffusa e radicata la cultura dell'opensource. La GPL ha il merito di aver sfondato il pregiudizio ed essere penetrata nelle cattedrali.
beh, d'altro canto, la viralità della GPL non mi pare sia riuscita a convincere nvidia a rilasciare il suo proprietarissimo driver come software libero :)
Questo e' vero, perche' hanno trovato un'escamotage. Sarebbe interessante sapere cosa avrebbero fatto nel caso l'escamotage non fosse esistito. Avrebbero rinunciato al mercato Linux? Compreso il settore HTPC, deep learning e similari?
tornando a Redox, credo che bisogna incoraggiare gli sviluppatori perché la loro sperimentazione può portare a miglioramenti per tutti, anche senza tutte le - sepppur giustissime - discussioni tecniche su C/C++/C# e via discorrendo.
non conosco rust come linguaggio, ma mi sembra che stia avendo un giustificatissimo seguito, date le sue pecularietà.
posso solo augurare il massimo al team di sviluppo di rust e di Redox-os
Rust ha dei vantaggi indubbi e del resto e' nato per soddisfare necessita' reali e pressanti. Il team di Mozilla ha visto cose turche in questi anni e sentito il bisogno di realizzare un linguaggio che desse almeno una mano nell'evitare imbarazzanti e stupidi bug.
Nella stessa direzione va Redox. Per ora cercano di dimostrare che un OS un pelino robusto si puo' creare. Come spesso accade, si spera che il loro lavoro percoli e porti beneficio anche ad altri progetti ( soprattutto kernel ).
eclissi83
03-07-2017, 11:10
Ha la sua ragion d'essere, che e' pero' incentrata sugli interessi delle multinazionali piuttosto che su quelli della comunita'.
permettimi di dissentire: le licenze BSD non nascono certamente per strizzare l'occhio alle multinazionali, anzi.
il software rilasciato sotto licenza BSD è quanto di più libero possa esistere. talmente libero che se ne può fare ciò che si vuole, anche inserirlo in software closed (Microsoft ha preso quasi tutto lo stack tcp di FreeBSD, Apple ha preso parti di FreeBSD e gettato le basi per OSX, etc etc).
sotto licenza BSD sono anche rilasciati progetti di notevole fattura, come NGINX o Vi, che non hanno certamente delle multinazionali alle spalle.
voglio ricordare che nessuno impedisce ad aziende di fare business con software libero, che non significa che sia gratis.
La GPL sara' rompigliona, pero' realisticamente e' la ragione per cui oggi abbiamo un'ecosistema open che consente di usare i computer sul serio.
se parliamo strettamente di GPL hai un ecosistema libero, più che aperto. ed indubbiamente, senza il software libero, l'informatica sarebbe molto diversa da com'è ora. e molto probabilmente sarebbe peggiore, almeno dal punto di vista della diversificazione.
Forzare le multinazionali a cooperare ha consentito a Linux di crescere. In caso contrario ho il fondato sospetto che avremmo ancora un sistema operativo con driver vesa e niente grafica 3D.
più che altro le multinazionali hanno visto, col tempo, che investire nell'ambiente Linux può portare loro tanti soldi ed una base di utenza decisamente ampia (molto maggiore rispetto a tutto il panorama BSD).
pensi davvero che IBM ed Intel contribuiscano allo sviluppo del kernel (sia con codice che con sovvenzioni) per motivi etici? rilasciano software perché - avendo aderito a questo tipo di sviluppo - sono costretti a farlo e visto che così facendo possono anche veicolare scelte progettuali.
secondo te quanto pesano aziende del calibro di Intel o IBM visto che "donano" team di sviluppatori o che assumono sviluppatori del kernel dandogli del tempo per contribuire a Linux?
Citavo appunto l'esempio di OrbisOS perche' e' molto indicativo di come le multinazionali concepiscano l'opensource. Cioe' tu scrivi, io prendo, impacchetto e vendo.
sony, come apple, utilizza software BSD all'interno dei suoi prodotti finali.
è consentito, lo fanno senza grossi problemi e senza dover rilasciare nulla.
tralasciando l'aspetto puramente tecnico (a detta di molti il kernel FreeBSD è un gran pezzo di codice), se avessero dovuto rilasciare il codice probabilmente avrebbero preferito riscrivere tutto, tanto sono in grado di farlo.
d'altro canto, certamente non tutte le aziende che utilizzano software con licenza BSD poi non contribuiscono al progetto; ci sono aziende come - solo per citarne alcune - iXsystems, Sandisk, Intel, Google che contribuiscono allo sviluppo di FreeBSD con patch o donazioni.
pensi che Google sia molto meglio di Sony o Apple perché per sviluppare Android ha usato Linux come sistema di partenza? Google ha contribuito ben poco al kernel, tant'è che le loro patch sono state una meteora in mainline, visto che non le mantenevano.
non avevano alcuna intenzione di - parafrasando Trump - rendere Linux di nuovo grande, quanto piuttosto cercare di fare un sistema funzionante (sulla cui qualità possiamo discutere un bel po') in tempi relativamente brevi.
ah, ovviamente hanno lasciato libero solo ciò che era strettamente necessario, mentre tutto il resto (come le GApps, che vengono distribuite a parte) sono closed, così come la maggior parte delle App presenti nel Play Store.
tant'è che ci sono degli store terzi (tipo F-Droid) dove c'è solo software libero.
Ovviamente nessuna condanna. E sono convinto che un progetto non GPL, oggi, potrebbe sfondare come Linux ( o anche di piu' ), ma perche' ormai e' diffusa e radicata la cultura dell'opensource. La GPL ha il merito di aver sfondato il pregiudizio ed essere penetrata nelle cattedrali.
sicuramente è molto più "normale" parlare ora di licenze libere rispetto a quando mi sono avvicinato a questo mondo io, quasi 20 anni fa. si sono sdoganate tutta una serie di falsità e di miti che ammantavano il software libero. e questo è comunque un gran passo in avanti.
Questo e' vero, perche' hanno trovato un'escamotage. Sarebbe interessante sapere cosa avrebbero fatto nel caso l'escamotage non fosse esistito. Avrebbero rinunciato al mercato Linux? Compreso il settore HTPC, deep learning e similari?
l'escamotage si è trovato perché conveniva a tutti fare così, e sebbene Linus faccia il dito medio ad Nvidia, non si è riusciti a trovare un modo - o forse non si è voluto farlo - per far rilasciare il driver sotto licenza libera.
non conosco lo stato attuale dei driver AMD/ATI perché ormai utilizzo solo Intel anche per le VGA (sinceramente me le aspettavo peggio, ma questo è un altro paio di maniche), ma appena rilasciano driver decenti sotto licenza libera, quanta gente passerà da Nvidia ad AMD/ATI?
Rust ha dei vantaggi indubbi e del resto e' nato per soddisfare necessita' reali e pressanti. Il team di Mozilla ha visto cose turche in questi anni e sentito il bisogno di realizzare un linguaggio che desse almeno una mano nell'evitare imbarazzanti e stupidi bug.
Nella stessa direzione va Redox. Per ora cercano di dimostrare che un OS un pelino robusto si puo' creare. Come spesso accade, si spera che il loro lavoro percoli e porti beneficio anche ad altri progetti ( soprattutto kernel ).
non essendo uno sviluppatore mi mancano tutta una serie di nozioni che ho letto nei precedenti post, come per esempio il fatto che del codice possa essere "safe" anche solo in base al linguaggio. mi piacerebbe saperne di più, anche senza entrare nel tecnicismo della programmazione, che non saprei apprezzare appieno.
sia per lavoro che per interesse personale utilizzo Linux, FreeBSD e OpenBSD; Linux ha al suo interno un'accozzaglia di codice atto a far funzionare il lettorino mp3 cinese, o la webcam dal chip sconosciuto.
FreeBSD e OpenBSD hanno modelli di sviluppo diversi ed anche obiettivi differenti, privilegiando prestazioni e flessibilità o sicurezza. soprattutto OpenBSD fa della semplicità del codice una sua prerogativa (sebbene io non sia in grado di giudicarlo).
non so tu quanto abbia provato sistemi diversi da Linux, ma secondo me un'occhiata ai vari BSD andrebbe data.
pabloski
03-07-2017, 15:12
permettimi di dissentire: le licenze BSD non nascono certamente per strizzare l'occhio alle multinazionali, anzi.
il software rilasciato sotto licenza BSD è quanto di più libero possa esistere.
Ovviamente la licenza non e' nota per far arricchire le multinazionali, pero' e' nata dal compromesso tra accademia ed industria. L'universita' della California voleva mantenere il copyright sul software prodotto, rendendolo pero' fruibile a tutti, e contemporaneamente non scontentare i finanziatori privati ( molti sono multinazionali ).
Che sia una licenza libera per definizione siamo d'accordo, ma talmente libera da lasciare un vuoto di cui hanno approfittato in parecchi.
voglio ricordare che nessuno impedisce ad aziende di fare business con software libero, che non significa che sia gratis.
Anche in questo caso si e' trattato di un compromesso, accettato pure dalla FSF, dal progetto GNU e dalla licenza GPL. Ma va bene, perche' chiunque puo' fare business col software open ( GPL o meno che sia ). La parte importante rimane il fatto che costringano tutti a cooperare. Per quanto nello spirito la BSD sia piu' libertaria, e' anche piu' "fessa" nella pratica.
più che altro le multinazionali hanno visto, col tempo, che investire nell'ambiente Linux può portare loro tanti soldi ed una base di utenza decisamente ampia (molto maggiore rispetto a tutto il panorama BSD).
La questione e' come si e' arrivati a quel punto. Logicamente di fronte ad un'ecosistema cosi' ben fornito e capillarmente diffuso, le multinazionali hanno fatto i loro bei conticini.
Quello che domando e' se, seguendo le regole della BSD, si sarebbe potuto creare un'ecosistema altrettanto vitale. Ovviamente non ho la sfera di cristallo, ma ho il leggerissimo dubbi che avremmo avuto un'ecosistema riccamente popolato di portoghesi.
pensi davvero che IBM ed Intel contribuiscano allo sviluppo del kernel (sia con codice che con sovvenzioni) per motivi etici?
No, ma col software BSD avrebbero potuto semplicemente prendere, usare e non restituire nulla alla comunita'. Magari oggi non l'avrebbero fatto comunque, ma 20 anni fa temo di si. Era l'epoca in cui MS definiva Linux un cancro! Era l'epoca in cui le multinazionali non avevano tra le loro pratiche di PR quella di contribuire all'opensource.
secondo te quanto pesano aziende del calibro di Intel o IBM visto che "donano" team di sviluppatori o che assumono sviluppatori del kernel dandogli del tempo per contribuire a Linux?
Direi che le statistiche sui contributor parlano chiaro in questo senso. Linux e' ormai un manufatto corporativo, anche se con licenza copyleft.
sony, come apple, utilizza software BSD all'interno dei suoi prodotti finali.
...
se avessero dovuto rilasciare il codice probabilmente avrebbero preferito riscrivere tutto, tanto sono in grado di farlo.
Il problema e' proprio che la licenza consente di fare i portoghesi. Dal loro punto di vista e' ok, da quello della licenza pure, ma da quello della comunita' non e' cosi' vantaggioso lo scambio.
E francamente credo che se non avessero avuto i BSD a disposizione, sarebbero stati costretti ad adottare Linux. Riscrivere da zero un sistema operativo avrebbe raggiunto un bel mazzo di miliardi ai costi di R&D.
d'altro canto, certamente non tutte le aziende che utilizzano software con licenza BSD poi non contribuiscono al progetto; ci sono aziende come - solo per citarne alcune - iXsystems, Sandisk, Intel, Google che contribuiscono allo sviluppo di FreeBSD con patch o donazioni.
Ed e' a queste che mi riferivo quando scrivevo che oggi la portoghesaggine non andrebbe comunque di moda nemmeno in ambito BSD. Le aziende che hai citato usano le contribuzioni come strumento di PR. Ma il meccanismo l'hanno messo in moto Linux e la GPL, portando il software libero e open alla ribalta delle cronache. Non dimentichiamoci che 20 anni fa questi signori erano considerati dei poveri sfigati che sognavano, con i loro programmi giocattolo, di competere con i "colossi".
pensi che Google sia molto meglio di Sony o Apple perché per sviluppare Android ha usato Linux come sistema di partenza?
No no, non m'interessa tessere le lodi di alcuna azienda. Semplicemente noto che la licenza BSD concede alle multinazionali dei vantaggi che la GPL non da'. Del resto proprio parlando di Google, ricordiamo che tutto il suo software l'ha rilasciato sotto licenze non GPL. E tutte licenze business-friendly. Evidentemente pure loro concordano che la GPL e' creata per ingabbiare le multinazionali e costringerle a cooperare.
sicuramente è molto più "normale" parlare ora di licenze libere rispetto a quando mi sono avvicinato a questo mondo io, quasi 20 anni fa. si sono sdoganate tutta una serie di falsità e di miti che ammantavano il software libero. e questo è comunque un gran passo in avanti.
Esattamente. Sono stati costretti a scendere a compromessi. Vuole usare il mio software GPL? Bene, collabori, aiuti nello sviluppo, al che non puoi piu' andare in giro a dire che e' un software giocattolo scritto in cantina da poveri sfaccendati.
Ovviamente questo effetto benefico ha investito tutto il mondo open e free, BSD compreso.
non conosco lo stato attuale dei driver AMD/ATI perché ormai utilizzo solo Intel anche per le VGA (sinceramente me le aspettavo peggio, ma questo è un altro paio di maniche), ma appena rilasciano driver decenti sotto licenza libera, quanta gente passerà da Nvidia ad AMD/ATI?
AMD contribuisce attivamente ai driver radeon e amdgpu. Entrambi sono open e sono da considerarsi quelli da usare in ogni caso. Hanno un driver closed amdgpu pro che supporta profili per i giochi e altre aggiunte. Ma gia' da un anno gli amdgpu pro sono basati sugli amdgpu.
FreeBSD e OpenBSD hanno modelli di sviluppo diversi ed anche obiettivi differenti, privilegiando prestazioni e flessibilità o sicurezza. soprattutto OpenBSD fa della semplicità del codice una sua prerogativa (sebbene io non sia in grado di giudicarlo).
non so tu quanto abbia provato sistemi diversi da Linux, ma secondo me un'occhiata ai vari BSD andrebbe data.
Non ci piove. Personalmente ho una buona di FreeBSD e ho giocherellato un po' con i rump kernel NetBSD.
Quello che purtroppo noto e' che ormai tutti si stanno Linuxizzando, a partire dalla moda di inglobare il kernel mode setting, dri/drm e gallium. E questo e' in buona sostanza dovuto al fatto che molti nella comunita' BSD fanno i portoghesi, a cominciare da chi come Sony ( e AMD ) non rilasciano driver importanti come quelli grafici.
pabloski
03-07-2017, 17:05
La ragione della licenza MIT va ricercata nel fatto che e' un'azienda ad aver avviato il progetto. Riprova del fatto che le aziende mal digeriscono la GPL.
Sperano cosi' di scroccare contributi da parte di sviluppatori independenti? Sperano di ottenere un'adozione rapida da parte delle imprese? Boh!
eclissi83
03-07-2017, 19:03
secondo me c'è un'incomprensione di fondo: la licenza GPL non riesce - purtroppo, e lo dico da sostenitore FSF - ad imporsi perché si riesce sempre a trovare il modo per bypassare la sua viralità.
ed Android è l'esempio lampante di come si riesca a fornire software misto: l'OS è GPL mentre gli applicativi no, ed alcuni di essi sono praticamente indispensabili per sfruttare determinati servizi diventati di uso comune.
per un'azienda usare software con licenza BSD è più semplice solo perché non deve far altro che citare e mettere a disposizione la fonte, mentre con la licenza GPL dovrebbe far dei distinguo tra ciò che è rilasciato free e ciò che è closed.
non mi sembrano ostacoli insormontabili per un'azienda.
comunque, il "vuoto normativo" della licenza BSD è spiegato qua:
https://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
da cui estraggo un pezzo:
A BSD license is not simply a gift. The question “why should we help our competitors or let them steal our work?” comes up often in relation to a BSD license. Under a BSD license, if one company came to dominate a product niche that others considered strategic, the other companies can, with minimal effort, form a mini-consortium aimed at reestablishing parity by contributing to a competitive BSD variant that increases market competition and fairness. This permits each company to believe that it will be able to profit from some advantage it can provide, while also contributing to economic flexibility and efficiency. The more rapidly and easily the cooperating members can do this, the more successful they will be. A BSD license is essentially a minimally complicated license that enables such behavior.
A key effect of the GPL, making a complete and competitive Open Source system widely available at cost of media, is a reasonable goal. A BSD style license, in conjunction with ad-hoc-consortiums of individuals, can achieve this goal without destroying the economic assumptions built around the deployment-end of the technology transfer pipeline.
eclissi83
03-07-2017, 22:25
Non capisco come la situazione potrebbe essere migliore su android se la licenza del kernel fosse BSD.
ah, probabilmente non sarebbe diversa da com'è ora.
Le APP chiuse rimarrebbero chiuse e in piu' ci sarebbe la possibilita' di avere anche tutto il resto del sistema operativo/kernel chiuso.
Veramente non vedo nessun vantaggio per l'utente finale.
magari potrebbe non essere così, non possiamo saperlo.
ci sono fior fiori di progetti rilasciati con licenza BSD che sono tranquillamente sviluppati, tipo Apache od NGINX (i due webserver più usati al mondo), ed anche se venissero utilizzati poi in prodotti chiusi, il codice sarebbe comunque lì, chiunque lo potrebbe vedere, migliorare ed utilizzare a proprio piacimento.
quel codice, nessuno lo può toccare.
Almeno con Android il kernel linux, che e' una delle parti piu' critiche per la sicurezza, e' liberamente visionabile anche nelle eventuali patch fatte.
E in un periodo come il nostro dove viene spesso messa in dubbio la 'buona fede' delle aziende
nei confronti dei dati personali degli utenti non mi sembra una questione da poco.
beh, di certo non è il kernel il problema degli smartphone, ma tutto l'hardware di cui non si conoscono le specifiche e il cui firmware non è pubblico, la profilazione degli utenti da parte di Google, Apple e Microsoft si fa a livello applicativo, che è per la maggior parte closed.
Per l'appunto e' una roba fatta e pensata per le aziende.
Ma a me, singolo sviluppatore, cosa mi interessa? Tutte aziende adottano un certo software piuttosto che un altro unicamente per il proprio profitto.
E la BSD e la MIT non danno la garanzia A ME che a un certo punto un'azienda non chiuda tutto e rivenda il MIO lavoro. Ad alcuni sta bene questo ad altri no.
i vari sistemi operativi BSD stanno lì da decenni, stessa cosa Apache e tutti i progetti collegati alla foundation.
a questi prodotti contribuiscono molti sviluppatori che non sono certamente ingenui o noncuranti del fatto che il loro codice possa essere usato in prodotti closed; lo fanno perché hanno la garanzia che quel codice è il loro, qualunque cosa gli succeda.
per quanto io preferisca la GPL, sto facendo un po' l'avvocato del diavolo per mettere in evidenza che l'adozione della GPL non risolve ancora - purtroppo - l'annoso problema della ereditarietà della libertà visto che si riescono a trovare molto spesso delle scappatoie legali per inserire codice con altre licenze.
pabloski
04-07-2017, 09:49
secondo me c'è un'incomprensione di fondo: la licenza GPL non riesce - purtroppo, e lo dico da sostenitore FSF - ad imporsi perché si riesce sempre a trovare il modo per bypassare la sua viralità.
La FSF la pensa allo stesso modo. Si accorsero pure che con i brevetti potevano rigirare completamente la frittata, cosa che ha spinto per l'uscita della GPLv3.
per un'azienda usare software con licenza BSD è più semplice solo perché non deve far altro che citare e mettere a disposizione la fonte, mentre con la licenza GPL dovrebbe far dei distinguo tra ciò che è rilasciato free e ciò che è closed.
Appunto, si aggiungono ostacoli per indurre le aziende a cooperare. Poi e' risaputo che fatta la legge si trova l'inganno e chi e' proprio determinato a fare il portoghese lo fara' lo stesso. Ci sono esempi lampanti in Cina di aziende che semplicemente fanno finta di non capire gli articoli della GPL e la violano bellamente.
comunque, il "vuoto normativo" della licenza BSD è spiegato qua:
https://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
da cui estraggo un pezzo:
Molto ingenua la parte del consorzio che dovrebbe schiacciare il monopolista. Ci possono essere casi in cui e' impossibile perche':
1. le aggiunte sono proprietarie
2. le aggiunte rappresentano quantita' di codice abnorme
3. disinteresse da parte degli altri soggetti/calcolo economico
4. le aziende sono piu' propensi a formare oligopoli e cartelli, piuttosto che "far trionfare" la giustizia
Voglio dire, se e' tutto cosi' semplice e bello perche' FreeBSD si e' ridotto ad importare tecnologie Linux a iosa?
eclissi83
04-07-2017, 11:40
Gia' adesso nessuno vieta ai produttori di APP di rilasciare il loro codice sotto BSD. Continuo a non vedere come avere un sistema operativo sotto BSD possa aiutare l'apertura delle APP.
ma vedi che io non voglio convincere nessuno che la BSD sia migliore di GPL.
come ho detto, preferisco la GPL, che però non riesce ad arginare il problema del rilascio closed di roba nata libera.
almeno la licenza BSD non ha vincoli legali di alcun genere e non se ne preoccupa proprio.
ti chiarisco il mio pensiero: la GPL è la licenza più bella del mondo.
se fosse usata da tutti il mondo sarebbe un posto migliore. ma non è così, purtroppo.
là fuori si ha a che fare con licenze chiuse, o incompatibili con la GPL.
è il motivo per cui nascono licenze diverse (oltre agli interessi economici, di tutti, GPL inclusa).
la GPL non ti fa rilasciare facilmente (in alcuni casi è impossibile) il tuo codice con licenza libera quando il resto del tuo ecosistema non lo è, mentre la BSD sì. è un vantaggio per lo sviluppatore che rilascia il suo codice che altrimenti dovrebbe essere rilasciato closed.
che il mondo sia sbagliato, è un dato di fatto, ma bisogna averci a che fare.
Certo, ci sono molti progetti di successo licenziati con MIT e BSD, pero' per ora nel mondo OSS il SO che ha avuto piu' successo, anche commerciale (nonostante i detrattori della GPL) e' stato linux. E questo nonostante SO similari '' commercialmente piu' appetibili '' con licenze BSD o MIT abbiano avuto le loro chances. Magari tra 10 anni il sistema piu' diffuso sara' Redox o una variante di BSD, chi puo' dirlo.. Ma per ora stando alla storia questi sono i fatti.
beh, che linux sia l'OS più diffuso è assolutamente vero. che i vari sistemi BSD siano meno diffusi è anche vero, ma continuano ad essere molto sviluppati ed utilizzati in tantissimi ambiti molto specifici, dove linux non arriva (per esempio hardware legacy che netbsd supporta ancora, non a caso è usato dalla NASA sui satelliti, shuttle e stazioni spaziali)
Certo, anche quello e' un grosso problema. Pero' sicuramente se devi piantare una backdoor nel SO e' molto piu' semplice se hai la possibilita' di nascondere quello che fa il kernel.
E, ripeto, dare la possibilita' di chiudere ulteriormente non mi sembra la soluzione a quello che hai scritto sopra.
non vuole essere una soluzione, ma un'alternativa meno vincolante.
alternativa che non piace a molti, lo capisco. come ti dicevo, preferisco la GPL, ma non sempre è usabile ovunque.
Ingenui no, noncuranti si(ovvero noncuranti del fatto che un'azienda possa prendere il loro codice, patcharlo e rivenderlo senza nulla in cambio).
Poi se questo sia un qualcosa di importante dipende dal singolo sviluppatore.
ripeto: il codice è lì, nessuno te lo può togliere, tutti possono usarlo. in fondo, rilasci software libero perché ti interessa che la gente lo usi e lo migliori. o lo fai per evitare che le aziende facciano soldi con il tuo codice? in tal caso mi sembra più un atteggiamento anti-business che pro-freesoftware.
credo sia normale essere infastiditi se qualcuno prende il codice per farci soldi e non contribuire a nulla, però così come ci sono quelli che sfruttano il codice, ci sono tante persone che cercano di contribuire. in fondo, il software libero è questo: dare la possibilità a tutti di contribuire, in qualsiasi modo.
poi, se al mondo ci sono persone cattive, possiamo solo cercare di migliorarlo e non è certamente con l'imposizione che lo si fa.
Per i BSD.. come sopra. Nonostante siano SO tecnicamente validi non mi sembra che negli ultimi anni la loro situazione dal punto di vista tecnico, economico e di community sia cosi' rosea...
mah, dal punto di vista tecnico non mi pare che la situazione sia come la descrivi tu...
Ok.. ma la soluzione a questo non penso che sia tornare al Far West, ma trovare una soluzione legale per far rispettare con ancora piu' forza la volonta' dell'autore.
Mi dispiace, mia deformazione culturale, ma ragionamenti che usano la buona volonta' di corporation private come presupposto, saranno sempre dubbi ai miei occhi (e a quelli di molte altre persone).
ci stanno provando con la GPLv3, ma non mi pare che stia avendo un grandissimo successo.
La FSF la pensa allo stesso modo. Si accorsero pure che con i brevetti potevano rigirare completamente la frittata, cosa che ha spinto per l'uscita della GPLv3.
come dicevo poco più su non mi pare che la GPLv3 sia sto gran successo, molti progetti sono rimasti alla GPLv2 (tipo Linux)
Appunto, si aggiungono ostacoli per indurre le aziende a cooperare. Poi e' risaputo che fatta la legge si trova l'inganno e chi e' proprio determinato a fare il portoghese lo fara' lo stesso. Ci sono esempi lampanti in Cina di aziende che semplicemente fanno finta di non capire gli articoli della GPL e la violano bellamente.
ma tanto sono ostacoli in alcuni casi molto semplici da bypassare... è come se non ci fossero. a volte sono più gli ostacoli che ha il singolo sviluppatore che le aziende.
Molto ingenua la parte del consorzio che dovrebbe schiacciare il monopolista. Ci possono essere casi in cui e' impossibile perche':
1. le aggiunte sono proprietarie
2. le aggiunte rappresentano quantita' di codice abnorme
3. disinteresse da parte degli altri soggetti/calcolo economico
4. le aziende sono piu' propensi a formare oligopoli e cartelli, piuttosto che "far trionfare" la giustizia
come dici tu ci possono essere casi in cui è impossibile
Voglio dire, se e' tutto cosi' semplice e bello perche' FreeBSD si e' ridotto ad importare tecnologie Linux a iosa?
ovvero? quali tecnologie freebsd ha mutuato da linux? se fai riferimento alla compatibilità binaria con gli ELF di linux, beh, è una cosa che si porta dietro da anni ed ora è anche disabilitata di default.
PS: vorrei che sia chiaro che io non sto facendo flame, non è mia abitudine e son utente di questo forum da veramente tanto tempo (sono iscritto dal 2001); sto cercando di effettuare un ragionamento che non è certamente semplice senza attacchi personali di alcun tipo.
eclissi83
04-07-2017, 15:03
????? No guarda questo e' falso. Su Android lato APP non hai limiti su come licenziare il software. Puoi mettere la licenza che piu' ti aggrada indipendentemente da quello che c'e' sotto, come del resto accade su GNU/Linux.
Non mi viene in mente nessun motivo per cui qualche parte dell' ecosistema GPL Android sia limitante a scrivere applicazioni in una licenza libera.
credo tu abbia travisato quel che ho cercato di esprimere: io ho detto che se ti trovi a scrivere roba in un ecosistema che NON è libero, probabilmente avrai difficoltà a rilasciare il tuo codice sotto GPL.
poi sei fossilizzato su Android, che ho usato come esempio per far capire quanto la licenza GPL sia facilmente bypassabile: pensa, invece, a un qualsiasi sistema embedded dove devi usare librerie di terze parti che hanno una licenza incompatibile con la GPL.
probabilmente, dovrai integrare il tuo codice in un prodotto già esistente e con la GPL non potresti farlo, mentre con la licenza BSD sì. in questo modo, il tuo codice sarebbe comunque libero, senza intaccare l'altro codice, librerie di terze parti etc etc.
Vedi.. questa e' una di quelle cose che apprezzo di meno della BSD.
Le aziende non sono 'cattive'. Le aziende fanno solo il loro interesse ed e' naturale che facciano cosi', ed e' naturale che tendano a formare monopoli o a cambiare strategia quando cambia il vento.
Non e' un discorso di bonta' e' un discorso di come naturalmente tendono ad andare le cose.
Io non voglio che nessuna azienda guadagni rivendendo il MIO lavoro gratuito senza dare nulla in cambio. E' un atteggiamento anti-business? puo' darsi, ma d'altro canto perche' dovrei fare l'elemosina a delle aziende private?
il tuo problema sembra essere solo che qualcuno faccia soldi con quello che hai scritto. e se tu i soldi su quello che hai scritto li avessi già fatti? puoi rilasciare software libero (GPL o BSD) anche dietro compenso, mica solo perché ti va di scrivere qualcosa nel tempo libero.
Che per certe cose i BSD siano fermi al palo e' un dato di fatto. E con questo non voglio dire che siano brutti sistemi.. anzi.
tipo? su quali cose FreeBSD è al palo rispetto a Linux?
Beh, e' gia' qualcosa.
purtroppo quando gli stessi utilizzatori della GPL non passano alla sua versione successiva (c'è tutto uno sproloquio di Torvalds riguardo al fatto che lui non sarebbe mai passato a v3), beh forse bisogna anche chiedersi il motivo..
Figurarsi.. siamo qui per parlare.
;)
eclissi83
04-07-2017, 17:15
... mi sembra si stesse parlando di Android (ed hai iniziato pure tu parlando delle sue applicazioni chiuse!), non sono io che mi sono 'fossilizzato'.
non proprio. ho usato Android come esempio per mostrare come la viralità della GPL non funziona ovunque.
Comunque esistono tante situazioni differenti. Se sono 'obbligato' a usare un sistema BSD perche' il sistema closed sottostante lo impone e penso che quel sistema sia essenziale su quella piattaforma li allora OK.
Ma nella pratica questo non avviene mai. Sia perche' c'e' praticamente sempre l'alternativa free, sia perche' la GPL ammette l'utilizzo di API standard anche se l'implementazione sottostante non e' libera.
purtroppo non è proprio così, ci sono vari casi in cui sei costretto a lavorare su hardware non di uso comune e di cui non esistono librerie rilasciate in GPL. perciò ho usato l'esempio dei sistemi embedded, dove questa cosa diventa più importante.
Vabbe', posso fare tante cose.. quindi? Se sto lavorando dentro un'azienda oppure voglio vendere il mio codice non potro/vorro' licenziare il mio codice sotto GPL. Se lavoro 'per la community' il discorso e' differente
beh, io ho lavorato in un'azienda dove il codice che gli sviluppatori scrivevano era rilasciato sotto GPL. venivano pagati per farlo e la roba era quasi sempre (alcune cose non le rilasciavano perché o troppo banali o non proprio di alta qualità) a disposizione della community di riferimento.
redhat rilascia la quasi totalità del suo software in GPL, eppure ci fa business, così come aziende come MySQL (ok, rilasciano anche roba non GPL), Canonical, Qt, etc etc.
la maggior parte delle aziende, purtroppo, non vede nel software libero un possibile mercato.
Driver? Sottosistemi di qualsiasi tipo?[che non elenchero' per ovvi motivi] Non ti sto dicendo che i vari *BSD non funzionino ma che come sviluppo siano indietro rispetto a linux.
beh, la quantità dell'hardware supportato è sicuramente inferiore a quella presente in Linux.
che intendi per "sottosistemi"? mi sa che devi elencare qualcosa perché non ho capito :|
Cioe' basta rapportare le dimensioni e i finanziamenti delle due community per rendersene conto. E gli sviluppatori dei vari *BSD per quanto siano bravi non possono fare di certo le magie.
Si tratta puramente di una questione di numeri
indubbiamente, per le magie bisogna attrezzarsi :D
Poi se uno si trova bene con questi sistemi buon per lui. Anzi per certe cose BSD ha pure un'architettura piu' lineare.
yep, io dove posso sui server installo FreeBSD, dove invece ho dei vincoli (per esempio l'uso di Docker) installo Linux
Beh, ovviamente quando si ha a che fare con una licenza pensata mi sembra normale che ci siano delle discussioni e delle divergenze di vedute. Ma a me sembra una cosa positiva rispetto a una situazione in cui si fanno andare bene le cose 'cosi' come sono'.
beh, RMS è decisamente integralista ed è anche grazie al suo integralismo che le cose si sono mosse in un determinato modo e sono arrivate a quel che abbiamo ora.
bisogna solo cercare di far andare bene la v3 a chi sostiene ancora la v2...
pabloski
05-07-2017, 08:49
Es:
Wayland mi sembra sia ancora in work progress ad esempio.
Il sottosistema audio e' ancora OSS (e non mi sembra ci sia gran voglia di cambiarlo)
E questo su FreeBSD
E' il naturale corso degli eventi in un ambiente estremamente permissivo. Lo stesso problema lo dovra' affrontare Redox se e quando diventera' qualcosa di piu' di un esperimento. Del resto, per ora, e' un lavoro portato avanti da una singola azienda ( System76 ).
Riguardo le licenze permissive, ne abbiamo visto i risultati ( nel bene e nel male ) nel corso degli anni '70-'90. Corporations come Microsoft o Apple hanno preso a iosa codice BSD, public domain, ecc... e c'hanno costruito sopra imperi miliardari senza contribuire ne' economicamente ne' in termini di codice.
In teoria quelle licenze invogliano a contribuire. Pure il comunismo invogliava ad essere solidali, altruisti e a concentrarsi sull'evoluzione intellettuale. Tuttavia gli uomini preferirono concentrarsi sulla materialita' e sfruttare quel sistema per accrescere potere e ricchezze.
In soldoni, il porco ( scusate il termine ) va preso per la collottola. cosa che Stallman ha capito fin troppo bene.
E per quanto ad alcuni possa sembrare paradossale, le licenze permissive hanno maggiori possibilita' di successo oggi piuttosto che ieri. Perche' oggi s'e' diffusa la cultura della comunita', per cui collaborare fa figo e migliora il PR.
pabloski
05-07-2017, 10:10
Non so, ma per poter fare una cosa del genere devono avere davvero pochi driver..
Soprattutto hanno pochi utenti e quasi nessuno di questi e' un utente desktop o comunque comune.
Se consideri che OpenBSD e' principalmente usato come piattaforma su cui basare ulteriori tecnologie commerciali ( i router high-end sono famosi ), non sembra strana quella decisione. Una multinazionale come Cisco si suppone che sappia compilare un kernel.
Quello che piuttosto non mi trova d'accordo e' che nel 2017 ancora ci si ostini a seguire la strana dei kernel monolitici, a fronte di svantaggi rilevanti che questi ultimi presentano.
Siamo nell'era della sicurezza, il kernel monolitico ne e' l'antitesi. Oltre a non sfruttare i meccanismi della memoria virtuale per migliorare la sua stessa stabilita' e robustezza.
Qualcuno dira' che parliamo di riscrivere milioni di righe di codice, o affrontare un'operazione di porting e migrazione colossale. Hanno ragione ovviamente per quanto riguardo i kernel preesistenti. E' folle che alcuni avviino nuovi progetti ( quasi sempre amatoriali e senza sbocco ) basandosi ancora su architetture monolitiche.
Almeno questi di Redox hanno preso una strada completamente diversa. E' gente che evidentemente ne capisce e ha idee ben chiare.
eclissi83
05-07-2017, 10:34
Boh, ci sta, ma continua a essere un problema piu' di una azienda che di una community (e se la cosa interessa per davvero a un certo punto le parti critiche vengono riscritte in GPL). Mai ritenuto che fosse un problema cosi' diffuso..
quando non hai le specifiche di un prodotto hardware per riscrivere le librerie che ti fornisce il produttore devi fare reverse engineering, che non sempre è una strada indolore.
Vabbe' ok, ma non e' comunque lo sviluppatore che decide la licenza del codice che produce. E Canonical, Oracle, Intel, Google etc. rilasciano il loro software su GPL perche' gli conviene economicamente, non perche' sono 'buone'.
puoi anche essere tu sviluppatore singolo a scrivere codice GPL e venderlo, non c'è alcunché di sbagliato...
Es:
Wayland mi sembra sia ancora in work progress ad esempio.
Il sottosistema audio e' ancora OSS (e non mi sembra ci sia gran voglia di cambiarlo)
E questo su FreeBSD
ok, perdonami per non aver compreso la cosa subito.
wayland non è ancora supportato di default da molte distro: su arch che è rolling c'è il supporto, ma io sto usando tranquillamente Xorg...
per l'audio c'è pulseaudio dal 2006, almeno stando a freshports: https://www.freshports.org/audio/pulseaudio
Riguardo le licenze permissive, ne abbiamo visto i risultati ( nel bene e nel male ) nel corso degli anni '70-'90. Corporations come Microsoft o Apple hanno preso a iosa codice BSD, public domain, ecc... e c'hanno costruito sopra imperi miliardari senza contribuire ne' economicamente ne' in termini di codice.
non mi sembra però che i vari sistemi BSD siano stati schiacciati. nel senso che loro avranno anche fatto imperi, ma sembra che FreeBSD (così come Open, Net ed altri che sono nati un po' dopo, tipo Dragonfly) stia ancora là vivo e sviluppato.
certo FreeBSD (probabilmente il più seguito dei progetti BSD), ha un seguito minore ed ha un numero di sviluppatori decisamente inferiore a Linux.
E per quanto ad alcuni possa sembrare paradossale, le licenze permissive hanno maggiori possibilita' di successo oggi piuttosto che ieri. Perche' oggi s'e' diffusa la cultura della comunita', per cui collaborare fa figo e migliora il PR.
purtroppo è vero che ora fare "community" fa figo, senza considerare che fare "community" è figo... :(
pabloski
05-07-2017, 11:10
Si e no.. nel senso che e' vero che i kernel monolitici hanno degli svantaggi, ma anche dei vantaggi (semplicita' e prestazioni).
Riguardo le prestazioni e' un argomento molto sopravvalutato e distorto. Ad esempio si puo', grazie all'IOMMU, avere dei driver in userspace che interagiscono direttamente con l'hardware. Riducendo in questo modo il numero di context switch tipici delle operazioni di I/O dei microkernel in ambiti senza IOMMU.
E c'e' ovviamente l'aspetto robustezza e sicurezza che credo, ad oggi, pesi come un macigno. Perdere un 3-5% in termini di prestazioni e' accettabilissimo a fronte degli enormi vantaggi in termini di modularita', sicurezza, scalabilita', robustezza.
In buona sostanza i monolitici vanno meglio solo nei benchmark!
Certo in generale in quanto a feature meglio un microkernel, ma diciamo che personalmente non ne sento cosi' enormemente l'esigenza (magari altri si..).
In passato mi sono interessato a L4::Fiasco (http://os.inf.tu-dresden.de/fiasco/) un microkernel sotto GPL della famiglia L4, ma e' passato nella 'pila dei progetti'.
Oddio, ci sono anche ( molti ) manager IT che non ne sentono l'esigenza, salvo poi lagnarsi quando le loro aziende vengono bucate selvaggiamente.
Il problema e' che ormai ragioniamo solo in termini di vantaggi di breve periodo e nessuno vuole spendere soldi per gettare le basi per sistemi che daranno vantaggi nel lungo periodo.
eclissi83
05-07-2017, 11:36
Giusto in questi due giorni ho scoperto ad esempio che OpenBSD e' stato rimosso il supporto ai loadable-kernel module nel 2014. Per carita', per il target a cui si rivolge ha perfettamente senso, ma fa impressione sia che una feature abbastanza normale nei SO di oggi manchi, sia che tutti i driver di Openbsd siano compilati e linkati staticamente nel kernel!. Non so, ma per poter fare una cosa del genere devono avere davvero pochi driver..
Yep, OpenBSD ha un supporto hardware abbastanza ristretto perché non hanno molto hardware su cui provare le cose :D
compra anche tu dell'hardware per openbsd: https://www.openbsd.org/want.html
pensa che le conf di openbsd spesso sono confondibili con le conf dei possessori di thinkpad :D
Soprattutto hanno pochi utenti e quasi nessuno di questi e' un utente desktop o comunque comune.
Se consideri che OpenBSD e' principalmente usato come piattaforma su cui basare ulteriori tecnologie commerciali ( i router high-end sono famosi ), non sembra strana quella decisione. Una multinazionale come Cisco si suppone che sappia compilare un kernel.
sicuro che Cisco usi OpenBSD?
eclissi83
05-07-2017, 11:39
Per wayland molte distro non lo supportano ancora, ma e' piu' una questione di packaging e di scrivere qualche patch. Da questo punto di vista FreeBSD mi sembra a uno stadio precedente.
Fonte: https://wiki.freebsd.org/Graphics#Roadmap
ben più che stadio precedente direi, ci sta qualcosina ma nella pratica è inutilizzabile.
Riguardo le prestazioni e' un argomento molto sopravvalutato e distorto. Ad esempio si puo', grazie all'IOMMU, avere dei driver in userspace che interagiscono direttamente con l'hardware. Riducendo in questo modo il numero di context switch tipici delle operazioni di I/O dei microkernel in ambiti senza IOMMU.
E c'e' ovviamente l'aspetto robustezza e sicurezza che credo, ad oggi, pesi come un macigno. Perdere un 3-5% in termini di prestazioni e' accettabilissimo a fronte degli enormi vantaggi in termini di modularita', sicurezza, scalabilita', robustezza.
In buona sostanza i monolitici vanno meglio solo nei benchmark!
Cosa che Tanenbaum ripete da prima che nascesse Linux, scatenando le ire di Torvalds. :D
Gli posso regalare un LEMOTE per farli soffrire :D
Lo Yeelong? Quello che fu di RMS? :D
eclissi83
05-07-2017, 13:36
Gli posso regalare un LEMOTE per farli soffrire :D
che cattiveria
https://www.cambus.net/openbsd-loongson-on-the-lemote-yeeloong-8101b/
:sofico:
Perche' no? ma con Red Flag linux preinstallato :D
Interessante. :D
Non fosse che era una ciofeca già anni fa, sarebbe pure carino :P Leggero :P
il thread 'storico' volevo relinkarlo io, che in effetti... :D
btw gli ultimi post mi hanno fatto ricordare che devo farmi ritornare un fiammante tp x41, ovviamente solo per il gusto di rimetterlo in funzione...
pabloski
05-07-2017, 17:00
sicuro che Cisco usi OpenBSD?
Che io sappia no. Ho tirato in ballo Cisco per indicare una generica multinazionale del settore.
Cosa che Tanenbaum ripete da prima che nascesse Linux, scatenando le ire di Torvalds. :D
All'epoca poteva aver ragione Linus sulla questione prestazionale. Ad oggi veramente c'e' poco o niente da perdere passando ad un microkernel.
Tutto vero, ma nella pratica i tentativi open e closed di fare microkernel ad uso desktop sono falliti(in realta' apparte i sistemi safety critical, non so bene dove vengano utilizzati i microk).
Oddio, veramente su desktop e' fallita qualsiasi cosa che non fosse Linux, Windows o macOS.
L'inerzia del settore desktop ( e workstation ) e' mostruosa. Non che il settore server e compagnia siano messi molto meglio. Gli unici settori in cui si fa un po' d'innovazione sono appunto quelli legati all'embedded, specialmente in settori critici come l'automazione industriale.
Pero' c'e' un posto dove i microkernel brillano ed e' nei processori baseband dei sistemi di telecomunicazioni ( smartphone compresi ). E parlando di telefoni, c'e' stato un sistema microkernel con diffusione di massa ed era Symbian. E c'e' QNX che e' molto popolare nell'elettronica per le automobili. Che poi per un certo periodo e' stato anche l'OS su cui era basato Blackberry.
Di certo migliorerebbe la situazione avere la superficie di attacco inferiore. Pero' ecco la maggior parte dei problemi di sicurezza che abbiamo adesso non credo dipendano dall'avere un kernel monolitico. Poi non essendo un sysadmin magari mi sbaglio eh!
Un kernel monolitico non mina tanto la sicurezza quanto la stabilita' del software. Se i produttori di cpu ci offrono strumenti per proteggere il software da se' stesso e dai suoi bug, sarebbe gentile usarli. Un monolitico non li usa, ficcando tutto in un unico spazio d'indirizzamento.
Poi e' naturale che si potrebbe approcciare il problema in maniera totalmente differente. Ad esempio facendo uso di linguaggi safe, tipo Rust ma anche Haskell, OCaml e altri. Oppure seguire la strada di Singularity e CosmosOS e sfruttare tutti i vantaggi di una VM come quella di .NET. Singularity ad esempio usava un singolo spazio d'indirizzamento, in cui giravano programmi, kernel, driver, ecc... La protezione non era fornita dalla cpu ma dalla VM.
eclissi83
05-07-2017, 18:00
Che io sappia no. Ho tirato in ballo Cisco per indicare una generica multinazionale del settore.
ah ok, sì una qualsiasi azienda con un minimo di esperienza sistemistica è in grado di compilare un kernel :D
comunque, Juniper utilizza FreeBSD per le sue appliance..
pabloski
06-07-2017, 09:13
non vengono percepiti cosi' terribilmente limitanti
Nah, e' solo che in questo settore qualsiasi tipo di problema non viene proprio percepito. L'importante e' lavorare il meno possibile ( i programmatori sono sfaticati per natura ) e riutilizzare quello che esiste fino all'impossibile.
Voglio dire, pure il C e' limitante, molto limitante, eppure ci sono ancora interi settori in cui spopola ( Redhat docet ).
Ovviamente non e' che i limiti non esistano, e' che si preferisce risparmiare soldi e tempo. Che poi con bug e vulnerabilita' ci si procura pure altro lavoro :D
o che i vantaggi dei microkernel non appaiono cosi' necessari a fronte di una difficolta' di programmazione maggiore
Se cosi' fosse non sarebbero nati progetti come FUSE. E' evidente che comprendono bene i vantaggi, ma l'attrazione per il legacy e' troppo forte.
E anche questo 3 - 5% in meno di velocita' rispetto ai monolitici deve essere contestualizzato e vedere quali compromessi sono stati fatti.
Tempo fa girava un benchmark prodotto dagli sviluppatori di seL4. C'era dentro pure Singularity. seL4 faceva il pelo a parecchi kernel. Addirittura Wombat ( Linux su L4 ) presentava tempi di context switch inferiori.
L'epoca in cui un microkernel implicava necessariamente una perdita significativa di prestazioni, aumento delle latenze, ecc... e' ormai passato. Le cpu moderne danno una grossa mano.
Dico solo che visto che visto che chi programma SO(anche progetti piu' piccoli di quelli che hai citato te ma comunque con una certa utenza) fino ad oggi ha scelto prevalentemente architetture monolitiche o ibride, evidentemente i microkernel non sono solo 'rose e fiori'
Legacy. Immagina il costo di sostituire Linux con qualcos'altro. E' la stessa ragione per cui i BSD stanno portando tecnologie ( anche quelle dalle dubbie qualita' ) da Linux. Haiku sta lavorando nella stessa direzione. Un OS nato seguendo un'architettura diametralmente opposta a quella di Linux, si sta Linuxizzando.
Apparte Rust che e' un linguaggio di basso livello, considero i kernel fatti con linguaggi garbage collected e managed piu' come esperimenti (sicuramente utili e interessanti) che come qualcosa che puo' essere utilizzato da un largo pubblico.
Certo un thread su Cosmos su questo forum. Fano ha descritto il progetto, soffermandosi su vari dettagli, tra cui proprio l'implementazione di .NET che hanno fatto quelli di Cosmos. Basti dire che non si tratta del tipico runtime .NET pesantemente basato sul garbage collector. Ed e' ovvio, un kernel non puo' mettersi a giocherellare con le latenze introdotte da un garbage collector.
Pero' di .NET sono state conservate tutte le caratteristiche che permettono l'implementazione di programmi piu' robusti.
Certo, anche qui esistono workaround, ma non so se alla fine questo possa portare a un'architettura pulita, semplice, elegante e robusta che questi progetti si prefiggono.
Personalmente ho un'unica riserva, ovvero che tra garbage collector e compagnia, siamo gia' a milioni di righe di codice, in cui si possono annidare bug pure gravi.
Questa cosa venne analizzata nello studio su seL4 che citavo prima e i ricercatori esprimevano proprio questa preoccupazione. Per la serie: "se c'hai la PM fornita dalla cpu, perche' reinventare la ruota in software?"
eclissi83
06-07-2017, 09:21
E' la stessa ragione per cui i BSD stanno portando tecnologie ( anche quelle dalle dubbie qualita' ) da Linux.
quali tecnologie BSD sta importando da Linux?
Cosmos è attualmente in alpha quindi la lentezza che vedi non è dovuta a C# o a GC, ma è appunto che è compilato in debug!
X# è usato solo ed esclusivamente durante le fasi di boot e per scrivere / leggere sulle I/O Port (ma viene poi messa a disposizione una classe e C# le usa come se fosse codice suo...), in IL2CPU per convertire l'IL in assembler, ma per il resto direi il 99% Cosmos è scritto in C# ;)
Ma per Cosmos c'è il thread apposito parliamone là... sto Redox OS qualcuno di voi l'ha provato? Dovrebbe esserci già una ISO "precompilata" no?
Una nota su kernel monolotici / microkernel... Linux e i kernel derivati da Unix (copiati se preferite!) sono gli unici rimasti negli anni '50 / '60: Windows è un kernel ibrido, Mac OSX anche (MACH era un microkernel, ma Next l'ha un po' "sporcato"), ecc...
Cosmos come Singulary e Midori rientrano difficilmente in questa categoria ed è necessario inventarne un'altra "Language Based System": https://en.wikipedia.org/wiki/Language-based_system
pabloski
06-07-2017, 17:32
quali tecnologie BSD sta importando da Linux?
KMS, DRI/DRM, praticamente tutti i driver grafici open
qualche folle ( Hubbard ) colpito da systemdite voleva portare launchd e tutta l'api per il messaging di macos
un buon numero di driver wifi pure sono portati da linux ( atheros in particolare )
oddio per i driver non e' un problema, il problema e' che si vuole accomodare il sistema per importare pezzi d'architettura di linux
questo e' francamente raccapricciante, anche se ci si guadagna in termini di supporto hardware
al prossimo giro che faranno? integreranno pure alsa? perche' pure li' ci sono parecchi driver
questo e' francamente raccapricciante, anche se ci si guadagna in termini di supporto hardware
Concordo... forse pure ORRIPILANTE :eek:
eclissi83
06-07-2017, 18:22
oddio per i driver non e' un problema, il problema e' che si vuole accomodare il sistema per importare pezzi d'architettura di linux
beh, immagino facciano i porting dei driver, anche perché - a parte le ragioni tecniche - non potrebbero redistribuire quel codice.
non credo, inoltre, che launchd (systemd mi sa che è quasi impossibile da portare) verrà portato su FreeBSD, sebbene ci sia già in TrueOS e in NextBSD.
come si può vedere nel wiki relativo - https://wiki.freebsd.org/launchd - gli ultimi update sono del 2015...
Io temo faranno la cosa più "veloce" una specie di finto kernel Linux in modo da poterli usare direttamente i driver di Linux e via! Non so come faranno per la licenza satanica GPL sinceramente...
eclissi83
07-07-2017, 10:48
Io temo faranno la cosa più "veloce" una specie di finto kernel Linux in modo da poterli usare direttamente i driver di Linux e via! Non so come faranno per la licenza satanica GPL sinceramente...
sinceramente mi sembra molto una porcata... per come sono gli sviluppatori di freebsd (ne conosco qualcuno personalmente) la vedo una cosa decisamente difficile... anche perché pare che linux cambi molto rapidamente (e con esso i driver) e quindi stargli dietro è difficile..
Se lo scopo è di usare i driver di Linux senza doverli ricompilare / fare porting non è che vedo molta alternativa a fare un "emulatore" di Kernel Linux...
eclissi83
13-07-2017, 15:07
Se lo scopo è di usare i driver di Linux senza doverli ricompilare / fare porting non è che vedo molta alternativa a fare un "emulatore" di Kernel Linux...
è che io non credo affatto che vogliano portare i driver così come sono..
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.