Redox OS

[eclissi83]

Originariamente inviato da Bellaz89

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

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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 :|

Originariamente inviato da Bellaz89

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

Originariamente inviato da Bellaz89

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

Originariamente inviato da Bellaz89

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]

Originariamente inviato da Bellaz89

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]

Originariamente inviato da Bellaz89

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]

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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

Originariamente inviato da Bellaz89

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

Originariamente inviato da pabloski

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.

Originariamente inviato da pabloski

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]

Originariamente inviato da Bellaz89

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!

Originariamente inviato da Bellaz89

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]

Originariamente inviato da Bellaz89

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

Originariamente inviato da pabloski

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]

Originariamente inviato da Bellaz89

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.

[GTKM]

Originariamente inviato da pabloski

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.

[GTKM]

Originariamente inviato da Bellaz89

Gli posso regalare un LEMOTE per farli soffrire

Lo Yeelong? Quello che fu di RMS?

[eclissi83]

Originariamente inviato da Bellaz89

Gli posso regalare un LEMOTE per farli soffrire

che cattiveria



https://www.cambus.net/openbsd-loong...eeloong-8101b/

[GTKM]

Originariamente inviato da Bellaz89

Perche' no? ma con Red Flag linux preinstallato

Interessante.
Non fosse che era una ciofeca già anni fa, sarebbe pure carino :P Leggero :P

[s-y]

il thread 'storico' volevo relinkarlo io, che in effetti...
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]

Originariamente inviato da eclissi83

sicuro che Cisco usi OpenBSD?

Che io sappia no. Ho tirato in ballo Cisco per indicare una generica multinazionale del settore.

Originariamente inviato da GTKM

Cosa che Tanenbaum ripete da prima che nascesse Linux, scatenando le ire di Torvalds.

All'epoca poteva aver ragione Linus sulla questione prestazionale. Ad oggi veramente c'e' poco o niente da perdere passando ad un microkernel.

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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]

Originariamente inviato da pabloski

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
comunque, Juniper utilizza FreeBSD per le sue appliance..

[pabloski]

Originariamente inviato da Bellaz89

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

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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.

Originariamente inviato da Bellaz89

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]

Originariamente inviato da pabloski

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?

[fano]

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]

Originariamente inviato da eclissi83

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

[fano]

Originariamente inviato da pabloski

questo e' francamente raccapricciante, anche se ci si guadagna in termini di supporto hardware

Concordo... forse pure ORRIPILANTE

[eclissi83]

Originariamente inviato da pabloski

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