• Please review our updated Terms and Rules here

Solaris 9 x86 - not really vintage, but certainly very obsolete - on a HP Compaq nc6000 laptop

If Linux was soo closely tied to Solaris way does it not use slices?

Because Linux was originally PC-centric, and on PCs logical subsections of a hard disk are called “partitions” and not “slices”. (Other than the terminology there are also technical reasons why Linux usually was set up in individual MBR-compatible partitions instead of slapping a BSD/Solaris style disk label down and creating Unix-proprietary slices inside it, like attempting to be more friendly with DOS/Windows disk repair tools.)

This is a really weird point to try to spring as a gotcha on someone. It’s not like disk formatting is a critical fundamental moving part to either OS. Linux *can* be set up to work with a BSD disklabel if that’s more appropriate, both OSes can run from network mounts…
 
I'm sure the OP would be grateful for your input.
The OP has used Xenix and SCO OpenServer, and knows how to use divvy (what a horrible tool).

I still don't get what you point is regarding how divisions/slices vs partitions makes classic Solaris any less the model old Linux tried to emulate.

I guess you don't like my Solaris 9 on an HP Compaq laptop project. That's fine, there are many other threads with totally different projects here for you to nitpick at will.
 
I'm sure the OP would be grateful for your input.

As the OP lays out above, he didn’t need it, and echoes my point that “slices” is a completely worthless thing to bring up. Solaris used BSD disk label partitioning because it was intended to be upwards compatible with the older BSD SunOS, and kept using the same portioning system on its x86 port no doubt because of inertia. There is nothing here that matters at all for the architecture of the operating system as a whole; to a UNIX system once it’s mounted a block device is a block device, the difference between BSD slices and MBR partitions is a few lines of code in a driver.

I’m sure when the OP said that Linuxes (mostly) emulated Solaris that was in reference to things like most Linux systems using SysV-style INIT structures (IE, the use of ”runlevels”, startup and shutdown script ordering, etc). (And even noted that there are exceptions to that rule, like Slackware.) And I agree with the OP on this point; there are other arguably “pure-er” SysV UNIXes than Solaris, which retains some BSD influences, but that actually serves to make it more like Linux because most GNU utilities are kind of a hodgepodge of SysV and BSD influence.

Again, I don’t see the point of bringing this up unless you were hoping to look smarter than the OP for knowing some piece of trivia that… wait, how would the OP not know that when they’re actually a Solaris user and that’s what the whole thread was about?

Whatever.
 
Having watched a project to "replace" a multi cpu sparc system running SAP with the best windows based x86 available at the time falter, leaving many red faces, as it wasn't capable of the tasks required.
The project was of course being driven by people with no sparc system experience.
I have Solaris 9 & 10, as well as linux, for my vintage Sun servers.
 
Solaris x86 uses slices inside of a primary partition, the standard limit of four primary partitions not being enough for normal Unix purposes. I don't know what the point of bringing it up was, either.

Why make Solaris more like linux? Use linux if you want linux. Appreciate Solaris for what it is. And take the effort to learn something about a system before you start spouting off ignorant nonsense about it on the internet. `ksh -o emacs` isn't bash but it works just the same (as far as that goes - and I much prefer -o vi anyway, even on bash) and guess what! It's something Solaris 2 has had since always. If I had a dime for every child of the FSF who is convinced they need vim for some feature that's worked just fine in vi since the '80s that they didn't even know how to use... who is convinced they need bash for "tab completion" when they haven't bothered to understand how wildcards would work just as well >90% of the time...

Anyway, as you were. I'll just be on my front porch, rocking in my chair and yelling at kids on skateboards.

(n.b. I deliberately did not reference any individual forum member, in this reply. It is a rant into the void.)
 
Last edited:
Solaris x86 uses slices inside of a primary partition, the standard limit of four primary partitions not being enough for normal Unix purposes.

And of course the PC-centric answer to that is extended partitions. Using a primary partition to host slices accomplishes the same thing, the argument for the Linux way is simply that it makes how you access ‘native’ and ‘foreign’ filesystem partitions on the block device a little more consistent, and it also makes the Linux partitions (which can be freely mixed with other filesystems in the extended partition if that’s really a use case you needed) “visible” to other OSes without them having to themselves understand your own particular flavor of BSD disk label.

(OSes running on PCs that use the slice methodology, like the various BSDs, have over the years used several different and sometimes confusing ways to present/number filesystems outside of the BSD container.)

But yes, materially, who cares? As long as the OS can figure it out it‘s fine.
 
And of course the PC-centric answer to that is extended partitions.
One of the problems with that is the way extended translation is done for DOS on drives >1024 cylinders. Many x86 UNIX systems expect untranslated geometry. Some of the ones that don't, or the ones that will at least tolerate extended translation, do the translation differently from DOS. And once you have logical drives in the extended partition (which takes up one of the slots for primary partitions, by the way), then you're forced to use DOS' translation method on the extended partition, or risk making a huge mess. Theoretically you can get away with defining your own primary partition with whatever translation you want, regardless of what else is already going on on the drive. In practice, of course, it's not that simple, but at least there's less to go wrong. I don't know the real reason hardly any x86 UNIX systems (besides Linux) makes use of logical drives in the extended partition, but I would not be surprised to learn that is a fair part of why.
 
To be clear, I’m not saying using the Extended partition is objectively the “right” way or that MBR partitioning didn’t have its flaws. (You actually have to work pretty hard to find another platform that over the years that suffered from more awkward growing pains as disks got bigger.) Just pointing out that there are advantages to suffering through it if your use case involves interoperability on the PC platform, which Linux usually did in the 1990’s. (At the cost of making your driver code more awkward, sure.) Every option on PC hardware sucked in the 1990’s, frankly, you had to choose your poison.

(And you don’t need to explain to me about the Extended partition consuming a primary partition, I am very well aware of it. If you *ever* have dealt with an MBR partitioned disk you know how the numbering works. The “advantage” of using it is it was the “PC standard” way of getting around the four partition limit, full stop.)

Doing it your own way in a proprietary stomping ground was no doubt simpler. And in the case of something like Solaris it might make administrators coming from another platform more comfortable to emulate the “standard way”... Although you have to admit that your UNIX-oid that lives in its own sliced partition will still have to have the code to understand the Extended partition properly anyway if it is going to allow mounting foreign filesystems, so in the end you’re *not* actually avoiding the problem, are you.

Again, and whole point here, it doesn’t matter at all once the system is set up or have any meaningful repercussions for the higher levels of the OS, so why argue such a stupid point to troll someone?
 
Last edited:
I would suggest trying the OpenIndiana distribution, it won't be any more "bloated" and is much more likely to have drivers for more things on the laptop; as well it will have modern userland and modern version of Firefox and possibly ungoogled-Chrome as well.
 
Back
Top