Addio a Solaris e SPARC: Oracle licenzia i team. La fine di un'era

Addio a Solaris e SPARC: Oracle licenzia i team. La fine di un'era

Oracle licenzia in tronco i team che si occupavano di sviluppare i processori SPARC e il sistema operativo Solaris. Si chiude così un'epoca iniziata nei lontani anni '80, sotto la guida della defunta Sun, in un lungo declino che durava ormai da anni e i cui prodromi erano già ben visibili subito dopo l'acquisizione della società da parte di Oracle

di pubblicato il nel canale Processori
OracleSun
 
25 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
fano22 Settembre 2017, 09:47 #21
Ai tempi ero attivo sui loro forum / newsletter ed ero uno di quelli che avevo "combattuto" per i bundle in stile Apple quella sì che era "la soluzione" non fare cose esotiche come un filesystem virtuale... tutto questo per "Python" che voleva installare la sua "bratta" in directory con nomi senza senso tipo "/usr/shared"? Cioè invece di fare porting decenti e l'OS che si deve adattare alle applicazioni?

@s-y
Quelli in camice bianco sì che erano "I veri programmatori":

http://nonciclopedia.wikia.com/wiki/Vero_programmatore
s-y22 Settembre 2017, 10:56 #22
ma si dai, era solo per 'condire' il concetto
cmq sono anche d'accordo che c'è troppa 'roba', lo scrivo non avendo più tempo (in passato si) per 'smagrire' la distro che uso, cosa che non andrebbe mai male, per certi versi. (però almeno si può fare, che non è scontato)
fano22 Settembre 2017, 11:05 #23
Almeno con la CentOS non è così banale "smagrirla" visto che ho visto casi imbarazzanti di dipendenze incrociati tipo vuoi rimuovere CUPS e tutta la bratta delle stampanti (nei miei sistemi le stampanti usano il protocollo ESC/POS e sono collegate su RS-232 :eek e mi chiedeva di rimuovere l'intero Gnome!

D'altra parte farsi la "propria" disto ritagliata per davvero (partendo dal kernel compilandoselo a mano e poi aggiungendo a mano solo la "bratta" necessaria) è un rischio visto che poi devi fornire il supporto al cliente del tuo "sistema (in)operativo".
s-y22 Settembre 2017, 12:13 #24
beh si, dipende dal contesto e dall'uso (questo sempre per qualunque os)

mi par cmq di capire, anche da altri post, che tu sia 'costretto' a usare la centos per lavoro, e per questo la 'odi', e pure questo ci può stare (poi d'altra parte il dependency-hell non è un concetto nuovo, e che ha sia lati positivi che negativi) cmq ad es con una slackware te ne liberi, al prezzo di una config manuale, o anche, in parte, con una arch ad esempio, che nonostante systemd mantiene una modularità decente. poi appunto dipende dal fine etc etc

(stesso per me cmq per lavoro, anche se per altre cose)
fano24 Settembre 2017, 16:15 #25
Vedi il fatto è che se per esempio sui PC Desktop ci facessero usare Windows con installato Microsoft Word[1], un browser che non si blocca di continuo, uno WindowManager decente... tanto mica ho il Desktop con CentOS 7 per compilare codice! Mi devo sempre collegare via ssh a 100 macchine di sviluppo diverse (è sì perché alcuni progetti usano CentOS 5.4, altre 6.6, 6.9... 7.0 e col c*volo che codice compilato su CentOS 5.4 gira sulla 7!).

Tanto Ximing per Windows funziona perfettamente (meglio del vero "X" quindi cosa cambierebbe?

Il mio sogno "quasi" bagnato sarebbe di compilare su Windows con Visual Studio (usando Net Core) e vedere Linux solo come "target"...

Quello totalmente bagnato è ciò che leggi in firma

[1] Son stufo di dire ai mie clienti che non riesco a leggere la documentazione! Dai è ridicolo... è l'MSDN e Office lo abbiamo pure, ma è solo per "fortunati" avere Windows
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^