Why is this even news?
What is it about application designers that they completely ignore that the 64bit systems have been around for 20 years and are now a mainstream platform across all OS'? Are they so myopic that they can't tool up-front and save all the 'port' hoopla, pain and angst?
Long ago and far away I worked for DEC in the UNIX support team. We were spread out all over the world and had the normal complement of call history, system documentation and troubleshooting databases.
When we started using IRC to share real-time information about callers problems our time-to-close went down significantly and closes-per-day went way up.
The improvement was significant enough to get the attention of other departments and the IRC usage - along with several bots for integrating the call handling and mail response systems into the IRC channels - became wide-spread in the support group.
This system survived the DEC/Compaq merger and on into the HP buyout.
If I were to do the same thing again I'd use a jabber server rather than IRC but the principle is the same.
The review didn't address desktop vs. server and as a "lightweight" review doesn't look any deeper than the distro package for answers to the questions and objections raised.
OpenSolaris works well as a server OS - that/is/ it's heritage. It's easier to run OpenSolaris headless and on a serial console than any of the *BSD and Linux distros that I've used over the years. All of the "standard" server packages are available to run web and net services out of the box. For truly lights-out server rooms it's still necessary to choose hardware that implements some sort of remote power cycle or remote system monitor capability.
The ZFS filesystem is interesting for desktop installations - it does allow seamless use of the 1-2 terabyte desktop disk configurations that are now possible. ZFS was designed for the datacenter - eliminating the need for the time-honored but fragile combination of journaling filesystem over software volume manager (usually over HW RAID).
It's the first real innovation in filesystem architecture since journaling filesystems were developed.
Additional software packages are available from 3 well-known (in the Solaris community, at least) sites. Sun has it's own freeware site, blastwave.org and sunfreeware.com
http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml http://www.blastwave.org/ http://sunfreeware.com/
The package manager for blastwave.org is their own, the others use the standard Solaris pkgadd commands. The package naming convention is a long-standing convention - each vendor uses a different prefix, making it easy to differentiate the source of packages.
OpenSolaris commands, where Sun hasn't replaced stock UNIX commands with their own, reflect SVR5 standard rather than the more Linux-ish BSD syntax.
One of the places where Sun has replaced "normal" functionality is the init process. SMF is Sun's attempt at fixing the long-standing problems and in-efficiencies of the BSD or SVR5 init process.
Apple has launchd, there's openrc and gentoo's baselayout that all have similar goals. SMF works well and there's a fair amount of support on the net for integrating non-distro apps.
One of the "why OpenSolaris" answers is that there is value in running the same OS on the desktop as on the server. For Solaris shops OpenSolaris on the x86* servers provides a common platform that enables system management efficiencies to be extended.
I'm currently using MediaWiki in a two-pronged manner - I keep my daily and rough notes under my User: space - after 20+ years it's gotten to be a habit to make notes about/everything/ I do.
These notes become source material for the "real" Wiki entries that have all the nice (well - it's/still/ a wiki) formatting and complete information.
I've also used Forrest + Openoffice.org successfully in the past. Forrest accepts OOo XML as an input format. As long as you use the styles in the sample doc from the Forrest distribution it renders cleanly.
Forrest can then output in a variety of formats, including PDF, to make generating offline site documentation for disaster recovery guides a/much/ simpler task - which means there's a better chance of it staying current.
Fingergear sells Computer on a Stick (COS) that has a bootable Linux distro on a USB flash drive. The current version has about 30mb of writable space, some in a public area that can be read w/o booting linux and some in private fs area that is accessible after booting from the COS. The web site says 1GB and 2GB versions are coming soon.
The OS on the current version is write-protected for security reasons and local hard-drives aren't accessible.
http://www.fingergear.com/
The poster commenting re: qualified support matrices is correct, but I'd go further.
I'm migrating 40+ servers from Tru64 UNIX to Linux to support Oracle, Oracle Apps, WebLogic, Apache, ftp/sftp, Legacy data interchange, printing, fileserver, mail, etc.
I need (in no particular order) stable SAN connectivity w/ NSPOF, data and bare-metal backups w/ short time to recover, integration w/ 24x7 monitoring, qualified support from multiple vendors (no custom/3rd party drivers or kernel build), lights-out management capability, server cloning and deployment, on-line extendable filesystems w/ good performance into the terabyte file system range, cluster filesystem for both data and OS.
I have/all/ of this, out of the box, with Tru64.
I'm still struggling, after 14 months into the RH3 deployments, to get these features.
A couple years back a watermain opened up and blew a 2ft hole in the wall of our computer room. During the next few hours several million gallons of water entered the building through the main server room.
The force of the water blew the mounting bolts for the telco racks out of the floor and moved them about 10 feet where they ran into the SAN cabinets.
The power didn't go out until the UPS batteries shorted out.
Over the next three weeks we recovered the data from about 500 36GB hard drives that populated the SAN. Only 3 of them needed new electronics and only 4 disks were unrecoverable.
It's also possible that the source was on the disk of a machine that was scrapped or sent out for repair by Mainsoft. This would still be a breach of security but is more common than one might think.
This article brings up two thoughts...
1) What affect will IRM have on discovery during litigation? I can imagine that any document controlled by IRM will be/much/ more difficult to present in an evidentiary proceeding.
2) This TIATP* about file formats and compatability is already a known-moot point. The next generation of data store will be in a database-like structure integrated into the OS. All programmatic access to data will be through API's that/aren't/ fopen() anymore - and the DMCA + trade secret + patent, ad nauseum will ensure that only licensees of the API will be compatible.
* Tempest in a teapot
Slashdot Mirror
Courtesy of Gizmodo http://gizmodo.com/the-scariest-part-of-the-latest-nsa-revelation-is-this-1455050775
Why is this even news? What is it about application designers that they completely ignore that the 64bit systems have been around for 20 years and are now a mainstream platform across all OS'? Are they so myopic that they can't tool up-front and save all the 'port' hoopla, pain and angst?
Long ago and far away I worked for DEC in the UNIX support team. We were spread out all over the world and had the normal complement of call history, system documentation and troubleshooting databases.
When we started using IRC to share real-time information about callers problems our time-to-close went down significantly and closes-per-day went way up.
The improvement was significant enough to get the attention of other departments and the IRC usage - along with several bots for integrating the call handling and mail response systems into the IRC channels - became wide-spread in the support group.
This system survived the DEC/Compaq merger and on into the HP buyout.
If I were to do the same thing again I'd use a jabber server rather than IRC but the principle is the same.
The review didn't address desktop vs. server and as a "lightweight" review doesn't look any deeper than the distro package for answers to the questions and objections raised. /is/ it's heritage. It's easier to run OpenSolaris headless and on a serial console than any of the *BSD and Linux distros that I've used over the years. All of the "standard" server packages are available to run web and net services out of the box. For truly lights-out server rooms it's still necessary to choose hardware that implements some sort of remote power cycle or remote system monitor capability.
OpenSolaris works well as a server OS - that
The ZFS filesystem is interesting for desktop installations - it does allow seamless use of the 1-2 terabyte desktop disk configurations that are now possible. ZFS was designed for the datacenter - eliminating the need for the time-honored but fragile combination of journaling filesystem over software volume manager (usually over HW RAID). It's the first real innovation in filesystem architecture since journaling filesystems were developed.
Additional software packages are available from 3 well-known (in the Solaris community, at least) sites. Sun has it's own freeware site, blastwave.org and sunfreeware.com
http://www.sun.com/software/solaris/freeware/s10pkgs_download.xml
http://www.blastwave.org/
http://sunfreeware.com/
The package manager for blastwave.org is their own, the others use the standard Solaris pkgadd commands. The package naming convention is a long-standing convention - each vendor uses a different prefix, making it easy to differentiate the source of packages.
OpenSolaris commands, where Sun hasn't replaced stock UNIX commands with their own, reflect SVR5 standard rather than the more Linux-ish BSD syntax.
One of the places where Sun has replaced "normal" functionality is the init process. SMF is Sun's attempt at fixing the long-standing problems and in-efficiencies of the BSD or SVR5 init process. Apple has launchd, there's openrc and gentoo's baselayout that all have similar goals. SMF works well and there's a fair amount of support on the net for integrating non-distro apps.
One of the "why OpenSolaris" answers is that there is value in running the same OS on the desktop as on the server. For Solaris shops OpenSolaris on the x86* servers provides a common platform that enables system management efficiencies to be extended.
I've used this successfully on several occasions. It's available from CPAN and requires only Perl. Here's a write about extending it a bit to do joins. http://www.builderau.com.au/architect/database/soa/No-fuss-SQL-joins-without-a-database/0,339024547,320268666,00.htm
I'm currently using MediaWiki in a two-pronged manner - I keep my daily and rough notes under my User: space - after 20+ years it's gotten to be a habit to make notes about /everything/ I do.
/still/ a wiki) formatting and complete information.
/much/ simpler task - which means there's a better chance of it staying current.
These notes become source material for the "real" Wiki entries that have all the nice (well - it's
I've also used Forrest + Openoffice.org successfully in the past. Forrest accepts OOo XML as an input format. As long as you use the styles in the sample doc from the Forrest distribution it renders cleanly.
Forrest can then output in a variety of formats, including PDF, to make generating offline site documentation for disaster recovery guides a
Fingergear sells Computer on a Stick (COS) that has a bootable Linux distro on a USB flash drive. The current version has about 30mb of writable space, some in a public area that can be read w/o booting linux and some in private fs area that is accessible after booting from the COS. The web site says 1GB and 2GB versions are coming soon. The OS on the current version is write-protected for security reasons and local hard-drives aren't accessible. http://www.fingergear.com/
The poster commenting re: qualified support matrices is correct, but I'd go further.
/all/ of this, out of the box, with Tru64.
I'm migrating 40+ servers from Tru64 UNIX to Linux to support Oracle, Oracle Apps, WebLogic, Apache, ftp/sftp, Legacy data interchange, printing, fileserver, mail, etc.
I need (in no particular order) stable SAN connectivity w/ NSPOF, data and bare-metal backups w/ short time to recover, integration w/ 24x7 monitoring, qualified support from multiple vendors (no custom/3rd party drivers or kernel build), lights-out management capability, server cloning and deployment, on-line extendable filesystems w/ good performance into the terabyte file system range, cluster filesystem for both data and OS.
I have
I'm still struggling, after 14 months into the RH3 deployments, to get these features.
A couple years back a watermain opened up and blew a 2ft hole in the wall of our computer room. During the next few hours several million gallons of water entered the building through the main server room. The force of the water blew the mounting bolts for the telco racks out of the floor and moved them about 10 feet where they ran into the SAN cabinets. The power didn't go out until the UPS batteries shorted out. Over the next three weeks we recovered the data from about 500 36GB hard drives that populated the SAN. Only 3 of them needed new electronics and only 4 disks were unrecoverable.
It's also possible that the source was on the disk of a machine that was scrapped or sent out for repair by Mainsoft. This would still be a breach of security but is more common than one might think.
Burst vs. MS
This article brings up two thoughts... 1) What affect will IRM have on discovery during litigation? I can imagine that any document controlled by IRM will be /much/ more difficult to present in an evidentiary proceeding.
2) This TIATP* about file formats and compatability is already a known-moot point. The next generation of data store will be in a database-like structure integrated into the OS. All programmatic access to data will be through API's that /aren't/ fopen() anymore - and the DMCA + trade secret + patent, ad nauseum will ensure that only licensees of the API will be compatible.
* Tempest in a teapot
Wilhelmina Baird : Snowcrash, Clipjoint, Psykosis Also a reasonable list at : http://www.scholars.nus.edu.sg/cpace/scifi/cpunk.h tml