Linked by Thom Holwerda on Mon 1st Jun 2009 17:50 UTC, submitted by poundsmack
Sun Solaris, OpenSolaris The team at Sun behind OpenSolaris has unleashed OpenSolaris 2009.06 upon the world. This new release comes packed with new features, changes, improvements, and fixes, and is the first release of OpenSolaris for SPARC, adding support for UltraSPARC T1, T2 (Sun4v), and UltraSPARC II, III and IV (Sun4u). Read on for some of the improvements that stand out.
Thread beginning with comment 366928
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[13]: Pay or run unstable
by cade on Thu 4th Jun 2009 06:11 UTC in reply to "RE[12]: Pay or run unstable"
cade
Member since:
2009-02-28

---------------------------------------------
It was mentioned ....

"Errrrrrrrrrrrr, the point being that no one should have to upgrade their entire installation to get security updates and no one has to."

Says who ?
A Linux user or an (Open)Solaris user ?

OpenSolaris is not Linux, but a real UNIX.
Linux is not OpenSolaris, but a unix-clone.
The two are different and that is abundantly obvious.

OpenSolaris patching/updates/upgrades/what-ever are confined within a new "boot environment" that can be activated on reboot of system. This way, if the upgrade is erroneous (e.g. from the source) then a rollback can occur and so the system is not comprised. See, if you have not figured it out yet, OpenSolaris gives you a fallback scenario. What's Linux's solution after a stuffed up upgrade/patching and no way to uninstall the erroneous software. I have experienced a failed Linux upgrade and it is not a pleasant experience especially when (unlike OpenSolaris) you cannot "flip a switch" and revert the system to a previous state. Also, these boot environments are lightweight/optimised. Even upgrading an entire installation (if need be) is a trivial task with ZFS/BootEnvironment/Rollback/etc framework.
---------------------------------------------

Do not forget that Linux' number of years being in the "wild" are much greater than the relatively new OpenSolaris codebase. As such, some of your concerns related to OpenSolaris' update-ability may be related this difference. Then again, if needs be, this is something that should be able to get fixed as the OpenSolaris community is a vibrant one.

Also, remember that the OpenSolaris codebase represents the amalgamation of many innovative technologies that have been open sourced and that other operating systems (including Linux) are cloning these innovative technologies.

As such, the OpenSolaris community also devotes it's time to trend-setting innovation and I am thankful that this sort of innovation still exists. Since this this innovative detail is able to be pumped out by the OpenSolaris community then I would think that the upgrade-related issues you mentioned would eventually be sorted out (if need be).

Reply Parent Score: 1

Windows Sucks Member since:
2005-11-10



OpenSolaris patching/updates/upgrades/what-ever are confined within a new "boot environment" that can be activated on reboot of system. This way, if the upgrade is erroneous (e.g. from the source) then a rollback can occur and so the system is not comprised. See, if you have not figured it out yet, OpenSolaris gives you a fallback scenario. What's Linux's solution after a stuffed up upgrade/patching and no way to uninstall the erroneous software. I have experienced a failed Linux upgrade and it is not a pleasant experience especially when (unlike OpenSolaris) you cannot "flip a switch" and revert the system to a previous state. Also, these boot environments are lightweight/optimised. Even upgrading an entire installation (if need be) is a trivial task with ZFS/BootEnvironment/Rollback/etc framework.


?

To configure yum to save rollback information, add the line tsflags=repackage to /etc/yum.conf.

To configure command-line rpm to do the same thing, add the line %_repackage_all_erasures 1 to /etc/rpm/macros.

Install, erase, and update packages to your heart's content, using pup, pirut, yumex, yum, rpm, and the yum automatic update service.

If/when you want to rollback to a previous state, perform an rpm update with the --rollback option followed by a date/time specifier. Some examples: rpm -Uhv --rollback '9:00 am', rpm -Uhv --rollback '4 hours ago', rpm -Uhv --rollback 'december 25'.

This is old info I am sure it's more easy or set by default on RedHat Enterprise Linux.

Transactional Rollbacks

Early in 2002, Jeff Johnson, the current maintainer of RPM, began to remedy the rollback problem when he included the transactional rollback feature into the 4.0.3 release of RPM. This feature brought with it the promise of an automated downgrade of a set of RPMs. Like many new features, it was rough around the edges and completely undocumented, except for a few e-mails on the RPM mailing list (rpm-list@redhat.com). Over the past year and a half, transactional rollbacks have matured steadily. In the current RPM 4.2 release, which comes with Red Hat 9, transactional rollbacks are quite usable.

Reply Parent Score: 2

RE[15]: Pay or run unstable
by akrosdbay on Thu 4th Jun 2009 07:39 in reply to "RE[14]: Pay or run unstable"
akrosdbay Member since:
2008-06-09



To configure yum to save rollback information, add the line tsflags=repackage to /etc/yum.conf.

To configure command-line rpm to do the same thing, add the line %_repackage_all_erasures 1 to /etc/rpm/macros.

Install, erase, and update packages to your heart's content, using pup, pirut, yumex, yum, rpm, and the yum automatic update service.

If/when you want to rollback to a previous state, perform an rpm update with the --rollback option followed by a date/time specifier. Some examples: rpm -Uhv --rollback '9:00 am', rpm -Uhv --rollback '4 hours ago', rpm -Uhv --rollback 'december 25'.

This is old info I am sure it's more easy or set by default on RedHat Enterprise Linux.



Too complicated! On OpenSolaris it is:

beadm list
List all the Boot environments and pick one. If you already know the BE name just type the commands below.
beadm activate <be name>
reboot

Or use the GUI. Simple.

Transactional Rollbacks

Early in 2002, Jeff Johnson, the current maintainer of RPM, began to remedy the rollback problem when he included the transactional rollback feature into the 4.0.3 release of RPM. This feature brought with it the promise of an automated downgrade of a set of RPMs. Like many new features, it was rough around the edges and completely undocumented, except for a few e-mails on the RPM mailing list (rpm-list@redhat.com). Over the past year and a half, transactional rollbacks have matured steadily. In the current RPM 4.2 release, which comes with Red Hat 9, transactional rollbacks are quite usable


OpenSolaris does a file system block level rollback. Which is much safer than the package manager doing it. It is also much quicker takes a few seconds to clone (during install) and few seconds to rollback.

It works reliably already because ZFS makes it dead simple and bullet proof.

In fact I am updating my virtual box on my macbook pro install of OpenSolaris to 2009.06 right now. In fact when I was installing mac OS X 10.5.7 update I was really missing the OpenSolaris clone and update system. One can only hope snow leopard uses ZFS as effectively.

Edited 2009-06-04 07:45 UTC

Reply Parent Score: 1

RE[14]: Pay or run unstable
by segedunum on Thu 4th Jun 2009 10:43 in reply to "RE[13]: Pay or run unstable"
segedunum Member since:
2005-07-06

OpenSolaris is not Linux, but a real UNIX.
Linux is not OpenSolaris, but a unix-clone.
The two are different and that is abundantly obvious.

I've heard this refrain singing in my head for the past ten years. "Oh, Oh, Solaris is so stable and it's a real Unix that enterprises use!" Anyone who says that to me clearly has mental issues over what has happened to Sun and Solaris during that time and are unable to accept it.

OpenSolaris patching/updates/upgrades/what-ever are confined within a new "boot environment" that can be activated on reboot of system. This way, if the upgrade is erroneous (e.g. from the source) then a rollback can occur and so the system is not comprised.

You totally misunderstand - deliberately - because you want to paint over the fact that there are no security updates available.

Yer, I can create a new installation and yer I can roll back to my old one if the upgrade is erroneous, but if it is then I'm not going to get my security updates am I? Upgrading to a new version of a system has potential far reaching implications when all you want are some minor updates to software that will maintain compatibility. No sane person in their right mind who wants to run a stable system does that, regardless of how many times he can roll back.

Talking about Solaris's brilliant way of upgrading your system is irrelevant and totally orthoganal to the main point because there are people who clearly have mental issues accepting the current situation. How about providing security updates within a rollback system, eh?

Also, remember that the OpenSolaris codebase represents the amalgamation of many innovative technologies that have been open sourced....As such, the OpenSolaris community also devotes it's time to trend-setting innovation.......

Sorry. I just need to mop up after pissing myself with laughter. Where did you dig this up from? Sun Marketing 101 down the hall?

Reply Parent Score: 2

RE[15]: Pay or run unstable
by akrosdbay on Thu 4th Jun 2009 16:55 in reply to "RE[14]: Pay or run unstable"
akrosdbay Member since:
2008-06-09


You totally misunderstand - deliberately - because you want to paint over the fact that there are no security updates available.


Yes there are. They are in the support repo.


Talking about Solaris's brilliant way of upgrading your system is irrelevant and totally orthoganal to the main point because there are people who clearly have mental issues accepting the current situation. How about providing security updates within a rollback system, eh?


But they are available. You really have no point just more FUD and trolling.

Reply Parent Score: 1