[HN Gopher] Tribblix - The Retro Illumos Distribution
___________________________________________________________________
Tribblix - The Retro Illumos Distribution
Author : bilegeek
Score : 86 points
Date : 2025-08-09 06:46 UTC (16 hours ago)
(HTM) web link (www.tribblix.org)
(TXT) w3m dump (www.tribblix.org)
| hulitu wrote:
| > lightweight window managers are preferred over heavy desktop
| environments, the primary desktop option is Xfce, and MATE and
| Enlightenment are also available, plus many others
|
| I would expected CDE as a first class citizen and maybe OpenLook.
|
| And it says that it it maily for 32bit SPARC and 32bit X86 and
| later that "Important: 32-bit hardware support now completely
| removed.".
| cheaprentalyeti wrote:
| I've been looking for a linux distribution that has olwm
| available but have had little luck. The closest I can find is a
| theme for icewm.
| CTOSian wrote:
| me as well, olvwm was last time in Debian Jessie, now only on
| NetBSD as package
| pabs3 wrote:
| Looks like Debian removed olvwm/olwm because they were
| incompatible with 64-bit and unmaintained.
|
| https://tracker.debian.org/pkg/xview https://tracker.debian
| .org/news/1000764/removed-32p14-282-fr...
| https://bugs.debian.org/911787
| ptribble wrote:
| It's never going to be maintained...
|
| But there is a 64-bit port (which I ought to bring in to
| Tribblix)
|
| https://github.com/ggodd/xview-64bit
| ch_123 wrote:
| They have an overlay for both:
|
| http://www.tribblix.org/overlay-cde.html
|
| http://www.tribblix.org/overlay-openlook.html
| ptribble wrote:
| There are over 30 desktop options (including quite a few of the
| older window managers, which is a bit of a blast from the
| past).
|
| I do include CDE and Open Look (the window manager and toolkit,
| at least). In both cases the add-on tools that were present in
| Solaris (like the whole of the DeskSet suite) aren't available,
| because they were never released in source form.
| gr4vityWall wrote:
| The Illumos' family is an interesting one. I wish it was easier
| to get it installed on modern hardware. Any of my attempts with
| distros like OpenIndiana, Tribblix and OmniOS didn't go further
| than the boot menu.
|
| I wonder how far a compatibility layer for Linux drivers could go
| to help other UNIX kernels' usability. Maybe the Oxide folks know
| more of what would be involved in such an effort.
| JdeBP wrote:
| That's the wrong solution to the problem, as it means learning
| a second kernel and all of its stuff and making compatibility
| shims, whilst _still_ facing the _real_ problem that is not
| software at all.
|
| The right solution is actually explained the headlined WWW
| site, where Peter Tribble points out (in the About page and in
| the Use guide) that the significant constraint is that xe does
| not own the actual physical hardware to develop against. It's
| the usual story with small projects: good donated hardware, and
| developer time (and workspace, and food, and water, and
| housing, and electricity supply (-:), needed.
| gr4vityWall wrote:
| I agree with you in principle, and I understand the existing
| constraint. But I don't see developer time scaling up without
| those operating systems reaching (again) critical mass, and
| then having upstream wanting to write drivers for even more
| operating systems.
|
| Which is fine per se. But I wish people could buy relatively
| new hardware (say, last 3 years) and be able to run FreeBSD
| or Illumos with most things working.
| ori_b wrote:
| > _I wonder how far a compatibility layer for Linux drivers
| could go to help other UNIX kernels ' usability_
|
| This isn't very interesting. It means you're constrained to the
| Linux design decisions, and you're wasting time debugging
| mismatches and poor design decisions.
| msgodel wrote:
| It also creates a licensing issue. Part of the reason Linux
| has so many drivers is because the GPL requires all of the
| kernel code be provided to users under the GPL as well. If
| you link to that in your OS/distribution now all of your code
| must be published in the same way.
| gr4vityWall wrote:
| Can't an hypothetical cross platform driver be MIT licensed
| and be part of both?
|
| Although I'd be more than happy with other
| OSes/distributions defaulting to GPL.
| yjftsjthsd-h wrote:
| > Can't an hypothetical cross platform driver be MIT
| licensed and be part of both?
|
| Yes, but if the goal is to reuse existing code that
| already exists in Linux then there's no reason to expect
| it to be under a permissive license. Some of it actually
| already is if I recall correctly, but you shouldn't
| expect that.
|
| > Although I'd be more than happy with other
| OSes/distributions defaulting to GPL.
|
| Illumos isn't GPL and and in the legal views of many
| people can't be compatible with it; CDDL/GPL
| (in)compatibility is a very long running issue, usually
| in the other direction with CDDL ZFS drivers in the GPL
| Linux kernel. (IANAL; I'm not asserting specifically that
| it is or is not actually compatible, just that a lot of
| people consider it to be incompatible)
| yjftsjthsd-h wrote:
| > I wonder how far a compatibility layer for Linux drivers
| could go to help other UNIX kernels' usability.
|
| It might be easier to take them from NetBSD; it wouldn't
| introduce the GPL licensing issue, and courtesy of their rump
| kernel system they're actually kind of designed for it.
| sunshowers wrote:
| I run our (Oxide's) Helios distribution on a headless Ryzen
| 7900x with an ASRock Rack B650D4U motherboard. I use an Intel
| X520 NIC for 10GbE.
|
| In general I'd expect Zen 3 and 4 to work, and Zen 5 either
| right now or very soon.
|
| See https://github.com/oxidecomputer/helios-engvm
| gr4vityWall wrote:
| Thanks for the reply, I appreciate the link! Do you know if
| people are using it for workstations?
| sunshowers wrote:
| Not entirely sure what you mean (do you mean Threadripper,
| which some of use?), but this is purely a work machine for
| me. I regularly build and test our software on my Helios
| box.
|
| It isn't exactly the same as our production machines (as
| you can imagine we have shared environments for this), but
| we've written in-memory simulators for most of our hardware
| components so it's good enough for most use cases.
| gr4vityWall wrote:
| Oh my bad, I meant "workstation" as in, a full desktop
| with a working desktop environment like XFCE, audio
| support, GPU acceleration for AMD iGPUs, etc.
|
| Thanks again for the informative reply.
| sunshowers wrote:
| Ah gotcha! I asked internally, and the initial answer is
| "no", but if someone says yes I'll let you know.
| rollcat wrote:
| I was just thinking this morning, to write a blog post with a
| small tour of niche-but-functional operating systems. Tribblix
| and Dragonfly BSD were at the top of my list. I've been also
| thinking Haiku, RISC OS, 9front, MINIX... They've all been around
| for decades, and usually fly under the radar.
| shrubble wrote:
| I really like (and have used in production) the ability to run
| Solaris Zones (containers) and "LX zones" which are Linux
| containers side by side on the same hardware.
|
| Many installation problems show up in the handling of USB3 and
| related quirks; I have a lovely AMD 8350 system that I can't
| install from USB onto because of some XHCI problem. The USB stick
| will boot the kernel, but then the kernel can't properly handle
| the USB stick after it has booted and can't see the installation
| media. I suppose I should bite the bullet and burn a CD to boot
| from, which should fix it.
| ptribble wrote:
| That shouldn't be a fundamental problem with current Tribblix -
| due to this sort of problem the installer got modified so that
| once the bootloader has pulled the ramdisk off the usb stick it
| doesn't need it again (although if it can't see it it won't be
| able to install any packages from it, falling back to dragging
| them across the network).
| 0xCafeBabee wrote:
| Sometimes it feels like keeping old systems alive is harder than
| keeping an old car running.
| Crontab wrote:
| One thing I am curious about is its version of ZFS. Would it be
| incompatible with OpenZFS from a Linux/FreeBSD system?
| unixhero wrote:
| Zfs on linux is its own project with a lot of development to
| make it run well on Linux
|
| That answers the Linux part of your question
| ndiddy wrote:
| ZFS on Linux has effectively taken over as the standard
| version of ZFS. It got renamed to OpenZFS a few years ago
| after the FreeBSD project chose to start using it for their
| ZFS support rather than upstream illumos ZFS due to how much
| more active the ZoL project was than upstream.
| sugarpimpdorsey wrote:
| Solaris was the reference implementation of ZFS. Are you
| wondering if you could migrate disk pools from BSD/Linux to
| Solaris ZFS?
| yjftsjthsd-h wrote:
| Illumos hasn't been Solaris for a long time. In particular,
| illumos uses pool version 5000 plus feature flags, while the
| proprietary version is still on version 28 or so without
| feature flags. OpenZFS is also much closer to the exact code
| in illumos, as far as I know there are some differences these
| days because they don't stay exactly in sync but they're
| close-ish.
| ndiddy wrote:
| You would have to look at the feature flags that your pool uses
| and see whether they match the flags that illumos supports.
| OpenZFS's feature flags are a superset of illumos's, so you'd
| be able to use a pool created on illumos on Linux/FreeBSD if
| that's what you're asking. https://openzfs.github.io/openzfs-
| docs/Basic%20Concepts/Feat...
| vermaden wrote:
| You can create ZFS pools that are more or less compatible with
| anything.
|
| Details here:
|
| - https://vermaden.wordpress.com/2022/03/25/zfs-compatibility/
___________________________________________________________________
(page generated 2025-08-09 23:01 UTC)