A message from the BSD gods?

[lgrant]

I’ve been interested for a while in trying OpenIndiana, since it comes from the other side of the Unix tree, and it would be interesting to see how it differs from the BSDs.

I am running into all sorts of problems trying to install it, and I am beginning to wonder if this is the BSD gods sending me a message.

 

[Beastie7]

What exactly are you trying to figure out? Aside from a few fundamental differences (or features); BSD and System V are essentially cousins. BSD being an extension to original Research Unix.

 

[bakul]

You may get more help elsewhere. Try https://www.reddit.com/r/OpenIndiana/

 

[lgrant]

Actually, I wasn't looking for help; I was venting (and expressing my affection for FreeBSD). But thank you, nonetheless. And all is good now.

 

[lgrant]

What exactly are you trying to figure out? Aside from a few fundamental differences (or features); BSD and System V are essentially cousins. BSD being an extension to original Research Unix.

The startup system looks more like Linux (IIRC, I haven't used Linux in a while). In any case, I have always heard good things about Solaris, so I wanted to see what it looks like. But I have been using FreeBSD for a while, so I'm not planning to change.

 

[Alain De Vos]

openindiana is dead.

 

[cracauer@]

The Solaris derivatives today seem to lack sufficient personpower for the large and complex codebase they have. Just my observation. I would have concerns about keeping up with security for starters.

Also, SunOS 4 forever!

 

[Cath O'Deray]

openindiana is dead.

June:

Raresh Rus (nmariusp) is a senior C++ developer who started programming for the KDE community in April 2022.

Other videos by nmariusp include:

• Install FreeBSD 14.1 and KDE Plasma 6 in QEMU VM tutorial - June 2024 - 2da0c933

---

Two days ago:

 

[BaronBS]

From that part of the unix family I'm really interested in Tribblix, but just as a side project.

 

[mer]

The Solaris derivatives today seem to lack sufficient personpower for the large and complex codebase they have. Just my observation. I would have concerns about keeping up with security for starters.

Also, SunOS 4 forever!

I think this can be said of almost every opensource project at some point. OS stuff like kernels, keeping up with hardware changes I think suffer the most.
But looking at logs and such, the derivatives are slow, but how many arguments about FreeBSD release schedules have we had?

As technology, Solaris is kind of interesting. A lot of it's advances (like fully preemptible kernel) have made there way into others; maybe done differently, maybe not as complete, but still there.
Solaris init is not old school BSD init, I think a bit more advanced than sys-v especially in relation to the user tools manageing init.
ZFS and Boot Environments came from Solaris don't forget.

 

[cracauer@]

Oh I never forget all the achievements that Sun had.

Before Oracle came in...

 

[fmc000]

Oh I never forget all the achievements that Sun had.

Before Oracle came in...

Yeah, so sad. Solaris has been a huge part of my professional career, more than twenty years. Sun will always bring me sweet memories.

 

[mer]

Oh I never forget all the achievements that Sun had.

Yep I figured a lot of folk here know and won't forget and I agree Oracle shares the title of most evil with SystemD .
I had the privilege of working on original SunOS and different generations of SPARC (Solaris) hardware and I'm still amazed at how much was possible based on the specs of the hardware (Just like the original Macs with the 9inch screen and floppy drive).

A team dedicated (financially and time) to working on keeping illumos core updated on new hardware; how good could it be? Heck would be a great opportunity to bring CDE back in

 

[Beastie7]

The startup system looks more like Linux (IIRC, I haven't used Linux in a while).

SMF is a really cool technology. It'd be a nice addition to FreeBSD.

 

[cy@]

I’ve been interested for a while in trying OpenIndiana, since it comes from the other side of the Unix tree, and it would be interesting to see how it differs from the BSDs.

I am running into all sorts of problems trying to install it, and I am beginning to wonder if this is the BSD gods sending me a message.

I installed in in a VM but haven't had a chance to use it yet.

However, having spent 16 years working on Solaris, professionally (after my 19 years on MVS), Solaris (and OpenIndiana) is based on AT&T SYSVR4.2. You will notice command syntax being very different.

But unlike other SYSV systems, like AT&T NCR, DG-UX, and HP/UX, /usr/ucb contains the command line utilities we in the BSD world are familiar with. Programming is a different matter. Though similar the API is clearly SYSV, while TCP/IP sockets are replaced by SYSV streams (to emulate sockets).

You can think of SYSV as east coast UNIX and BSD as west coast UNIX. (I read that somewhere.)

I installed it in a VM that supported a CSM BIOS. I don't know if Illumos (the source for OpenIndian and others) supports UEFI.

I'd suggest installing in a VirtualBox VM to start, just to get a feel for OpenIndiana. Then try it again on bare metal.

 

[cy@]

SMF is a really cool technology. It'd be a nice addition to FreeBSD.

I was planning on importing it into FreeBSD but was discouraged because other developers told me that its CDDL license isn't something we'd want for our init. Even though it doesn't replace init, init hands off control to smf, we'd need to rewrite our rcng scripts to smf services and that would require every FreeBSD system would need to use smf, it woudn't be optional.

Considering the above, it doesn't make sense to effectively replace init (even though it doesn't actually replace init) with a CDDL licensed tool.

 

[Alain De Vos]

openzfs , cdrtools are also cddl. And openzfs is used in ubuntu. I'm not a lawyer so it is unclear for me where is the real problem.

 

[lgrant]

Yep I figured a lot of folk here know and won't forget and I agree Oracle shares the title of most evil with SystemD .
I had the privilege of working on original SunOS and different generations of SPARC (Solaris) hardware and I'm still amazed at how much was possible based on the specs of the hardware (Just like the original Macs with the 9inch screen and floppy drive).

A team dedicated (financially and time) to working on keeping illumos core updated on new hardware; how good could it be? Heck would be a great opportunity to bring CDE back in

I saw a video about the history of Solaris, and it sounded like there was not a lot of management; the developers just figured out what needed to be done and did it. I have never worked for a shop that trusted its developers that much.

 

[cy@]

Yep I figured a lot of folk here know and won't forget and I agree Oracle shares the title of most evil with SystemD .
I had the privilege of working on original SunOS and different generations of SPARC (Solaris) hardware and I'm still amazed at how much was possible based on the specs of the hardware (Just like the original Macs with the 9inch screen and floppy drive).

A team dedicated (financially and time) to working on keeping illumos core updated on new hardware; how good could it be? Heck would be a great opportunity to bring CDE back in

Or better yet, OpenLook. Quirky but certainly pretty cool.

The first UNIX workstation I used was a Sun 3/60 running SunOS 4.1.3. One of the pizza box machines. It didn't even have enough RAM to run OpenLook. I had to use GNU screen instead. Primitive but functional.

 

[Beastie7]

I was planning on importing it into FreeBSD but was discouraged because other developers told me that its CDDL license isn't something we'd want for our init. Even though it doesn't replace init, init hands off control to smf, we'd need to rewrite our rcng scripts to smf services and that would require every FreeBSD system would need to use smf, it woudn't be optional.

Considering the above, it doesn't make sense to effectively replace init (even though it doesn't actually replace init) with a CDDL licensed tool.

From my own limited research; it seems SMF is somewhat tied to the kernel. Specifically for features like service contracts and instances. Being able to run multiple versions of the same application, or completely restart userland without touching the kernel is pretty useful.

I figured having to convert all rc scripts from users and ports in the tree would be another blocker; a similar issue was brought to Jordan Hubbard when he tried to persuade core to adopt launchd. Although I think converting to (UCL based?) SMF manifests would be less of a hassle IMO.

I think a from scratch, BSD licensed implementation, with some sort of curated list of manifest converted rc scripts, or built-in rc compatibility would be ideal IMO. If I had the chops, i'd do it myself.

 

[Beastie7]

openzfs , cdrtools are also cddl. And openzfs is used in ubuntu. I'm not a lawyer so it is unclear for me where is the real problem.

Although we have first class support for ZFS. We still lack proper ARC/VM subsystem integration (which Oracle Solaris has); which greatly affects write IO performance. The majority of that disparity is technical, but part of that is licensing.

I believe a rewrite of the VM subsystem would allow this, but would screw with UFS however. Someone feel free to correct me on this.

 

[cy@]

From my own limited research; it seems SMF is somewhat tied to the kernel. Specifically for features like service contracts and instances. Being able to run multiple versions of the same application, or completely restart userland without touching the kernel is pretty useful.

I figured having to convert all rc scripts from users and ports in the tree would be another blocker; a similar issue was brought to Jordan Hubbard when he tried to persuade core to adopt launchd. Although I think converting to (UCL based?) SMF manifests would be less of a hassle IMO.

That's one of the reasons I dropped the project.

I think a from scratch, BSD licensed implementation, with some sort of curated list of manifest converted rc scripts, or built-in rc compatibility would be ideal IMO. If I had the chops, i'd do it myself.

Then we're looking at something like Apple's launchd, which IMO is more suited to a laptop or workstation.

systemd was created for the desktop. And the latest systemd service, systemd-homed, which maintains an encrypted home directory blob that only the owner can access isn't suited for servers. We looked at it at $JOB. Poettering's focus while at Red Hat (last I heard he worked at M$) was the desktop.

 

[cy@]

openzfs , cdrtools are also cddl. And openzfs is used in ubuntu. I'm not a lawyer so it is unclear for me where is the real problem.

OpenZFS is in a contrib directory while cdrtools is in ports. The idea is that a company/user can use FreeBSD without whatever is in contrib. Though IMO it would certainly be difficult. A case in point might be embedded systems, like in your Sony TV.

 

[Beastie7]

Then we're looking at something like Apple's launchd, which IMO is more suited to a laptop or workstation.

systemd was created for the desktop. And the latest systemd service, systemd-homed, which maintains an encrypted home directory blob that only the owner can access isn't suited for servers. We looked at it at $JOB. Poettering's focus while at Red Hat (last I heard he worked at M$) was the desktop.

I don't like how launchd cobbles a lot of daemons together but I understand why Apple did it. For devices that require dynamic power management (laptops, tablets, etc.); I believe that was the motive behind its design. IIRC SMF allows compatibility with running rc scripts, but you're limited in how you can administer them.

SMF would be great for FreeBSD; but I'm not up to snuff on how it interacts with the kernel in the illumos implementation. I'd wager it'd have to be from a from scratch implementation with BSDisms in mind for FreeBSD. Another feature that I like, is that all manifests are kept in a configuration repository. Reminds me of docker images/registry, but for services only and all built-in. Combined with ZFS; it really helps streamline service administration.

Transitioning to something like this would probably take a few years though.

 

[bakul]

OpenZFS is in a contrib directory while cdrtools is in ports. The idea is that a company/user can use FreeBSD without whatever is in contrib. Though IMO it would certainly be difficult. A case in point might be embedded systems, like in your Sony TV.

/usr/src/contrib and /usr/src/sys/contrib are files originally from contributed software to BSD but now are required components. That is, they are typically developed outside of the BSD source tree. One *may* have been able to run 4.4BSD without its contrib directories but that was 30+ years back!