Why do they always comment on gcc not the latest as a bad thing?
The base compiler needs to be stable. Newer releases might be faster and better on edge cases, but also have much more bugs. Many of them serious.
7 is a good choice, 8 might also work. everything since 9 is very experimental. 10 even crashes on the simpliest of my testcases. how fc32 managed this is a miracle.
To all the people who will now let us know that GCC crashes for them (and I've no doubt it does, I'm not questioning your honesty), do you put in bug reports?
Using the latest features. Like -O4 -flto=4 cef retpoline and such.
But mostly it's the simple things, like the string library, which broke in 9. Only 50% of the added bugs fixed so far. They are moving too fast.
I'm using SmartOS (and Triton) with minimal SmartOS images in production for hosting mixed services.
In general, I really like it. My biggest frustration at the moment is the age of packages in pkgsrc. Second would be the lack of support for Illumos in third-party packages. These frustrations are manageable.
I have fond memories of a few decades of using/managing Solaris machines, and I've often considered running OpenIndiana on a Thinkpad. Has anyone tried this? How is the OpenIndiana support for commodity laptop hardware?
Run it in VMs. The Qubes OS is optimized for this use case. Then Solaris sees a very stable device environment, removing most of the work in keeping an OS fresh.
30K+ users according to the Micah Lee video on their website.
I didnt know CubesOS till ncmncm posted about it in this thread, but it looks interesting enough to test drive for a while. If you want to learn more, recommend watching the video here: https://www.qubes-os.org/video-tours/
I use both Qubes and SmartOS (like OpenIndiana, an illumos derivative) although not together. One advantage to using OpenIndiana directly on the laptop -- and I've not tried this, maybe it's too much pain -- would be you should get much more memory efficiency out of zones than you do out of QubesOS. Qubes relies on a type 1 hypervisor (Xen) so it is not nearly as efficient at reclaiming memory as an illumos/Solaris derivative, since Solaris zones are OS level virtualization (they are not under the illusion they have a whole machine to themselves so they are handling memory as flexibly, pretty much, as an application process). Qubes is notoriously memory hungry which can be an issue, especially on an ultralight laptop (the ThinkPad X1 for example still tops out at 16GB RAM which can actually be a little tight for Qubes). (There does seem to be some degree of memory reclamation which I assume is due to hosted OSes and maybe Xen itself evolving over time to respond intelligently to frequent changes in "installed" ram.)
The downside I imagine would be 1> you don't get Qubes' security measures of isolating USB and the network stack into their own VMs, away from dom0 and 2> from what I gather there just isn't the same extent of specialized plumbing in OpenIndiana for a single user trying to do work across vms/zones - qubes has for example a little menu to redirect arbitrary usb devices into particular qubes, there is a gui flow for moving files securely between zones with explicit dom0 prompts/approval, there is a secure system for moving clipboards between vms, etc.
17 comments
[ 1.8 ms ] story [ 52.9 ms ] thread7 is a good choice, 8 might also work. everything since 9 is very experimental. 10 even crashes on the simpliest of my testcases. how fc32 managed this is a miracle.
latest is not always best, mostly worst.
For llvm it's pleasent.
In general, I really like it. My biggest frustration at the moment is the age of packages in pkgsrc. Second would be the lack of support for Illumos in third-party packages. These frustrations are manageable.
I didnt know CubesOS till ncmncm posted about it in this thread, but it looks interesting enough to test drive for a while. If you want to learn more, recommend watching the video here: https://www.qubes-os.org/video-tours/
The downside I imagine would be 1> you don't get Qubes' security measures of isolating USB and the network stack into their own VMs, away from dom0 and 2> from what I gather there just isn't the same extent of specialized plumbing in OpenIndiana for a single user trying to do work across vms/zones - qubes has for example a little menu to redirect arbitrary usb devices into particular qubes, there is a gui flow for moving files securely between zones with explicit dom0 prompts/approval, there is a secure system for moving clipboards between vms, etc.