#illumos

Initial port of OpenBSD's iwm(4) driver to #illumos (tested on a Thinkpad X260 running OmniTribblix). WPA2+CCMP work ongoing. Packet loss has been observed so it's not ready for use yet, just wanted to let it be known that some work has been started! Patch pre-release: https://github.com/lex0de/illumos-iwm/releases/tag/iwm-wpa2-pre-1 Tree: https://github.com/lex0de/illumos-iwm/tree/iwm-x260 #Tribblix #OpenIndiana

SmartOS: The illumos Way of Thinking About Servers A practical look at SmartOS, illumos, zones, LX compatibility and the way this operating system approaches servers. Not a complete guide, just enough to understand why I like it. https://it-notes.dragas.net/2026/09/28/smartos-the-illumos-way-of-thinking-about-servers/ #SmartOS #illumos #Hosting #Server #IT #SysAdmin #OwnYourData #ITNotes #Tutorial

I want to publicly thank @dch@bsd.network The FreeBSD port of littleFedi was already ready at release time, and it’s really well done. One of the peculiarities of littleFedi is that it was developed and tested first on the BSDs, then on illumos, and only later on Linux. The first public instance, my own @stefano@rpi0w.stefanomarinelli.it account, runs on a Raspberry Pi Zero W with NetBSD. I don’t think many social platforms have started out on NetBSD in recent years. #ThankYou #RunBSD #NetBSD #FreeBSD #OpenBSD #illumos #OwnYourData #Fediverse #littleFedi

SmartOS: The illumos Way of Thinking About Servers https://it-notes.dragas.net/2026/09/28/smartos-the-illumos-way-of-thinking-about-servers/ #ITNotes #NoteHUB #hosting #illumos #ownyourdata #server #smartos #tutorial #zones

Post your #NeverSlop tech stack! I'm thinking... OS: #NetBSD, #Illumos, #Haiku, #RedoxOS or #9frontEditor: #ed, #nvi, or #VimClassiceBooks: #clbre??? (Doesn't seem to have any downloads yet); #arcalibre?Social: (egad, #Mastodon is already sloppified?!?) #GoToSocial, #snac2, hopefully #LittleFediAudio editing: #TenacityBrowser: #KonformBrowserImage editing: libvipsData/file encryption: #LibreSSL, ccryptPassword Manager: #ChiPassTerminal Multiplexer: GNU #Screen and #OpenTmuxEmail: #aerc, #clawsMail (I haven't tried all of these yet)

Upgrades to Tribblix m35 on SPARC now available, bringing gcc10 to the party. This is a synthetic release, with updated applications atop m34 as the underlying OS. https://www.tribblix.org/relnotes.html#m35-sparc #tribblix #illumos #sparc

Time for my occasional reminder that the #illumos ptools are amazing and highly productivity enhancing.

On my MacOS workstation this is a common work flow:

ssh $ILLUMOS 'pwait pgrep something' ; say {-a other-speaker} SOMETHING IS DONE

Can work on other things until I hear shouting.

New experiment: BourneCore is live! A OpenIndiana (illumos) live USB for sysadmins who miss real Unix. Boots straight to shell, packed with nmap/netcat/tshark & friends. Heads up: it's beta and a bit rough around the edges 😅 built it mostly for fun. If you poke at it and hit bugs, I'd genuinely love the feedback! https://bashcore.org #OpenIndiana #illumos #Unix #Solaris #Sysadmin

Fable dishing out the compliments that those of us running these systems for decades have always known and advocated for. "That DTrace trace was the whole game, by the way — owner identity from mdb plus lock/unlock pairing found one orphaned acquisition in 55k events and its exact stack. Nice platform to debug on." #illumos #dtrace #smartos

Some of our #OpenBSD anti-ROP #research ended up on lobsters: https://lobste.rs/s/xclcel/final_return_for_openbsd_anti_return #BSD #FreeBSD #NetBSD #DragonFlyBSD #Linux #Unix #Illumos #compiler #compilers #GCC #LLVM #Clang

The recording of the June 25th, 2026 #bhyve Production User Call is up: https://youtu.be/sfjpe8oDZCE We discussed the updated #illumos ‘dladm modify-vnic’ feature, the bhyve balloon driver, the nyetboot hobby firmware, SeaBIOS support, Netgraph, GNU/#Linux vs. #FreeBSD for vendors, VPP, VirtualBox to bhyve migration, and more! "Don't forget to slam those Like and Subscribe buttons." You can support all Call For Testing efforts via BSD Fund: https://bsdfund.org

watching the football game Netherlands-Sweden powered by Firefox running on #OpemIndiana #illumos

Meet #Starling, a lightweight #ActivityPub server for the #Fediverse, built with PHP and SQLite. Run your own decentralized social platform on shared hosting or a tiny VPS WITHOUT Redis, PostgreSQL, or complex infrastructure. What it makes so special to me? It looks awesome, comes with a great admin web interface and does not require a VPS instance where it can also be operated on a cheap shared hosting systems. By the given requirements, it also easily runs on a #RaspberryPI and all kind of systems, including #FreeBSD, #OpenBSD, #Illumos and more! This all makes it perfect to everyone and even beginners to run their own instance. With relay support (e.g., fedi-relay.gyptazy.com) it even can consume and post content over non-directly connected instances in the #fediworld! Kudos to the author of Starling: @df@s.dfaria.eu More information: GitHub project: https://github.com/dfaria-eu/Starling My blog post: https://gyptazy.com/blog/starling-simple-fediverse-server/ #fedi #fediwall #opensource #decentralized #social #socialmedia #alternatives #mastodon

@bytebro@mastodonapp.uk This is not a conflict of standards. None of those are standardized. Indeed, this is what you get for using all of these non-standard things instead of the thing that *is* standardized: pkgadd from magtape, per the System 5 Interface Definition. https://illumos.org/man/8/pkgadd (-: #Unix #Illumos #SVID

If you've ever built a non-trivial amount of software on Solaris / illumos you've almost certainly hit math function errors like this: error: call of overloaded 'log(int)' is ambiguous I got fed up of adding patches to pkgsrc, and I believe I have a patch that fixes this once and for all. https://www.illumos.org/issues/15209#note-4 I'd appreciate wider testing. I've already tested it in a full ~28,000 package bulk build, but changes like this terrify me, and you can't be too careful. #solaris #illumos #pkgsrc

@jperkin@federate.me.uk I'm not sure that this is the best fix. Since C++2011, there's been a template for std::log in that takes an integral type argument and so is the best match without ambiguity. https://cplusplus.com/reference/cmath/log/ vide libstdc++ https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/c_global/cmath;hb=HEAD#l322 and libc++ https://github.com/llvm/llvm-project/blob/main/libcxx/include/__math/logarithms.h#L35 Illumos's C++ support in isn't up to date with respect to C++ 2011 (unsurprisingly) and a fix that would actually improve and modernize the C++ support seems to be to add these templates for log and whatnot, in some fashion, with appropriate C++ version and type guards, to head/iso/math_iso.h where all of the other C++1998 overloads already are. That would remove ambiguity for both log(1) and std::log(1). #CPlusPlus #Illumos #gcc #clang

@jperkin@federate.me.uk If I had an #Illumos system to do such work on, I probably could. Your patch is breaking the uniform way that the library is designed, over a whole load of headers. In this design, all of the overloads are declared inside namespace std in some iso/*_iso.h header, which headers like and and so forth then pull into the global namespace with using declarations. Ironically, it's a far more full-on C++ way of doing things because it's even declaring the C library functions in namespace std, but with "C" linkage. namespace std gets 1 "C" linkage overload and 2 "C++" linkage overloads for the various functions. #CPlusPlus #gcc #clang

@jperkin@federate.me.uk Retaining that uniform, clean, system involves adding the stuff that's needed for more modern C++ anyway into the right iso/math_iso.h header. If I were doing that, head/iso/math_iso.h would gain something like template inline typename __illumos::__enable_if<__illumos::__is_integral<_T>::__value, double>::__type log(_T __v) { return log(static_cast(__v)); } inside namespace std, and #include at the top. There'd be an head/iso/type_traits.h with the well-known implementation of enable_if<> as __illumos::__enable_if<> and a suitable implementation of __illumos::__is_integral<> instantiated as appropriate. #CPlusPlus #gcc #clang #Illumos

@jperkin@federate.me.uk All that said, the big question to answer is whether there is still in use an #Illumos C++ compiler that does not use either GNU libstdc++ or LLVM libc++. (Likely yes if a compiler bootstrap uses C++ before it has its own library built.) Because the inlined "C++" linkage stuff declared by the Illumos library has a fallback to other inline functions if using libstdc++ or libc++, the very easiest patch of all would seem to be just conditionally compile out (only) the extern "C++" {} block of head/iso/math_iso.h when either _LIBCPP_VERSION or __GLIBCXX__ is defined. That way, anything building with libstdc++ or libc++ doesn't get the Illumos "C++" linkage overloads as overloads in the global namespace, and only gets the 1 "C" linkage overload. #CPlusPlus #gcc #clang

@jperkin@federate.me.uk You've missed two important bits. Your initial approach didn't test for _LIBCPP_VERSION or __GLIBCXX__. Your initial approach rather compiled all of this out except for one specific compiler. What I just described, in contrast, compiles everything in for all compilers except when libstdc++ or libc++ are used. It's library-sensitive, not compiler-sensitive. Because there's a stage at least in the GCC bootstrap where it is building itself with the pre-supplied compiler and library. In this mode, one does *not* want the #Illumos headers to have their C++ parts conditionally compiled out. One rather wants them to be fully natively functional the same as they are now. I also said *only* the extern "C++" {} block. Your initial approach went far beyond that and compiled out the declarations of a whole bunch of "C" linkage stuff. #CPlusPlus #gcc #clang