Ah. I think my plan9 user detector must have been confused by the air of smugness, and the appearance of desiring Murray Hill purism, something plan9 users have that illumos users don't (SMF, for one, isn't Murray Hill at all in style).
So long as you don't attack my beloved sexprs in your attack on XML, I don't care.
I like the fathers of UNIX, it's true; I think the way they think, and over the course of the last 30 years of using computers, I've discovered that my experience with computers matches their experience. I can see why they came up with the tenets they did. It all makes sense.
As for XML in SMF, that is a sad part of history: at the time, Sun Microsystems had the guy who invented XML (Tim Bray, was it?) on the payroll, and suddenly, XML started forcefully infiltrating everywhere into UNIX, whether it was appropriate or not. I don't know anyone who's happy about having XML SMF manifests. All of us from the Solaris / illumos community would rather we never speak of that embarrassment again, I think.
On LISP: I would love to use it, except getting it to run on Solaris / illumos sucks ass, and when one does get it to run, it's only 32-bit, and it likes to coredump a lot. And I'm not going back to GNU/Linux just to be able to run LISP. Other than that, I find LISP cool. I think that reentrant functional programming with no state machine is the way to go, and I like the fact that one can run LISP both interpreted and compiled into a binary executable.
I actually wasn't talking about XML, I was talking about the general design of SMF. Murray Hill purists, champions of worse is better, would call SMF's architecture overly complicated and call for the use of BSD init, daemontools, s6, or runit. As a linux user, I see SMF as the good bits of systemd (service management, etc), without a lot of the bad bits (creeping scope, gradual introduction of lock-in, kills your screen sessions for no reason, sinister plans for world domination...). It's almost like Lennart has an instinct for getting good ideas exactly wrong.
As for Lisp on Illumos, which Lisp did you try? For Common Lisp, CLISP, CMUCL, and SBCL all claim to support Solaris. SBCL is the most popular of the three, but its solaris binary is a little out of date, so you'll have to use it to compile the latest sources. Instructions at http://www.sbcl.org/getting.html.
However, I am primarily a schemer, and if you're excited about lisp-1s, hygenic macros, tail calls, call/cc, and case sensitivity, you may want to look into scheme. Because of the minimally defined spec, every scheme is a little different. Chicken scheme, my favorite implementation, claims to run on x86 solaris, although it hasn't been tested on the latest versions. It may still work. MIT scheme explicity claims to run on any posix system, but it's kinda dead. Guile will probably run, as GNU projects usually try to be reasonably platform independant, but it's hard to tell. As both the above are GNU, so you'll need GCC, but I assume that's already installed on your system.
Chibi Scheme, Gambit, and Chez Scheme are also worth a shot, although they have less libraries than the above.
Finally, Racket, which isn't really a scheme so much a a new programming language descended from Scheme (as I understand it, many of the Racket implementers backed the ill-fated R6RS, but wanted to go even further, and got sick of compromising with Scheme). I don't personally like it, but you may, and it also claims POSIX.
If none of the above run at their latest version, which I very much doubt, you could always try lx zones as a last resort.
sexprs is an abreviation for s-expressions. They're what make up a lisp program, and how lispers store data: Typically, in a lisp program, your config file won't be a unixy .cfg, but instead a lisp program, which is much more powerful. However, like XML, it's kinda hard to grab data with regex, although unlike xml, it's trivial to parse.
Best i can tell, Poettering, much like Gnome devs (and the first mailing list entries i can find attributed to him indicates he was using Gnome back in the day), finds his inspiration from Apple.
Pulseaudio, Core Audio.
Avahi, Basically a straight reimplementation of the Zeroconf/Bonjour protocol.
Systemd, Launchd.
Frankly i would not mind, except that by getting Freedesktop on his side he is able to push his vision of the Linux stack onto other distros.
Now before I get into the details, let me just state for the record that I've ported 200+ (if not more) freeware packages to Solaris, and I modify, compile and link a lot, so this was not my first "walk in the park"...
First I tried CMUCL. And after some patching, I got it to work. But only 32-bit. And it would core dump a lot. Because the GCC compiler at the time didn't support DWARF 2 (it seems to support it now, but I'd have to build GCC again), compiling with -g was basically worthless for debugging, so I ditched it, because I didn't feel like disassembling x86 assembler that day.
Then I tried CLISP, and that was a lost cause, it was so busted that it wouldn't even build. The last thing I tried was Steel Bank Common LISP, SBCL. Unfortunately, just like other LISP's, SBCL isn't self hosting, and it requires a working LISP to build itself. In my case, that would have been CMUCL, except that I abandoned that a while ago when it became clear that it would only work 32-bit and that it crashed. It's a shame, I really think that ANSI Common LISP is the future.
However, I am primarily a schemer, and if you're excited about lisp-1s, hygenic macros, tail calls, call/cc, and case sensitivity, you may want to look into scheme.
My understanding is that Scheme is not 100% LISP compatible, but even worse, that it runs as bytecode on a Java virtual machine. As soon as I see a language running on a virtual machine of any kind, I'm done. That won't enter my systems or my network. If I cannot compile it into straight machine code binary executable, that's it, it's out of the window, and never to return. Not on my watch! Is my finding correct, or is there a Scheme to ELF machine code binary executable compiler out there?
If none of the above run at their latest version, which I very much doubt, you could always try lx zones as a last resort.
I created an lx-branded zone for the first time a few days ago and was just absolutely speechless with regards to how everything just works. The Linux applications literally think they're running on Linux. The only things which gave it away as not being Linux was the completely made up kernel version and /native, containing native illumos binaries that would be in /usr/{bin,sbin} on illumos. It blew my mind.
First off, does the x86 solaris binary for SBCL work? You can bootstrap off that if it does.
>My understanding is that Scheme is not 100% LISP compatible, but even worse, that it runs as bytecode on a Java virtual machine. As soon as I see a language running on a virtual machine of any kind, I'm done. That won't enter my systems or my network. If I cannot compile it into straight machine code binary executable, that's it, it's out of the window, and never to return. Not on my watch! Is my finding correct, or is there a Scheme to ELF machine code binary executable compiler out there?
...ummm... wow. It's history time.
Lisp isn't a language or a standard. It's a family of languages. When you say Lisp, you're talking about Common Lisp, which is one of the two popular lisp standards today. The other is Scheme RnRS, with R5RS and R7RS being the most widely implemented. Scheme isn't Common Lisp compatible, as it is a totally different language, although still a Lisp. Some people believe that Scheme shouldn't be regarded as a lisp, but those people are crazy.
Scheme prides itself on minimalism, originating in academia, and designed for PL research and education, and so, much like POSIX, every implementation extends it in a different direction. Some Schemes are suitable for Real Work, others are not.
As scheme is a standard, it has been implemented for a variety of architectures. While it does run on the JVM, that implementation isn't very good. You're probably thinking of Clojure, which is JVM.
There are several schemes that compile to native code. Gambit and Chicken are the most popular. While Guile uses ELF, it uses it as its bytecode format, and while native compilation is planned, we probably won't get it for a good few years. Chibi is bytecode, and will probably stay that way, although it has a decent FFI. If you can live without native compilation, Guile, at least, is worth looking at.
As for Chicken vs Gambit, it's pretty evenly stacked. I know Chicken better than I know Gambit, but I'll try to give a good comparison:
FOR CHICKEN:
-Chicken uses Cheney-on-the-MTA compilation meaning that re-entrant continuations (think setcontext/setjmp but better) are no slower than any function call.
-Chicken has a really, really good library repository. For a scheme, anyway.
-Chicken has fairly good POSIX integration
-Previous versions of Chicken have definitely compiled on OpenSolaris.
-Chicken has an almost ungodly helpful maintainer and community, with active mailinglists and IRC.
AGAINST CHICKEN:
-Chicken isn't reentrant
-Chicken has no pthread support, only supporting fork(2) and pre-emptive coroutines.
-Chicken has a really good compiler. You'll see why this is a mark against it in a minute.
FOR GAMBIT:
-Gambit has compiler that generates really, really, really good native code.
-Gambit is, I think, reentrant
-Gambit has okay POSIX
-Gambit has Termite, which is erlang-style coroutines, in addition to a Chicken-like system. Guile is the only scheme I know that has pthread support, and it's not in this comparison.
AGAINST GAMBIT:
-Gambit's continuation implementation is slower and more limited than Chicken's.
-Even with BlackHole and SchemeSpheres, the two module sets it has, Gambit is behind Chicken in modules
-Gambit's FFI is harder to use than Chicken's.
-I don't know how well Gambit supports Solaris.
First off, does the x86 solaris binary for SBCL work? You can bootstrap off that if it does.
One of them didn't work for either i86pc (that's what we call the x86 and x86_64 platform on Solaris) or sparc, and my requirement is that it has to build and run on both exactly the same, as 50% of my server park is UltraSPARC, and 50% various forms of intel-based processors. But I'd have to look at that again. Something didn't work, or else I would be running SBCL by now.
While Guile uses ELF, it uses it as its bytecode format, and while native compilation is planned, we probably won't get it for a good few years. Chibi is bytecode, and will probably stay that way, although it has a decent FFI.
Now see, that is a severe step back for me: I had bytecode back in 1984, except then the "virtual machine" was called "Commodore BASIC", and "bytecode" was known as tokens, which is what they really are when you learn about AST parsers and trees in computer science at the university. So when I see "bytecode", that's a throwback. And a very bad, bad throwback, masked with pure brute force in terms of massive amounts of memory and processing power. It was a very bad and inefficient, slow solution then, and even with all this processing power and memory, it's a very bad and inefficient, slow solution now. I have never, and will never tolerate that. No amount of programming pleasantness and syntactical sugar will change that.
The way forward is clear to me now: ANSI Common LISP.
...Did you miss the 1/2 of my post where I talked about two of the best native-code compilers scheme had to offer? Gambit and Chicken are both fantastic, and compile to C, no bytecode anywhere.
Also, your understanding of bytecode is deeply, deeply wrong. It's accurate to an extent, true, but Bytecode isn't the same thing as an interpreter, and can be much faster.
But even if bytecode is unacceptable to you, as it does indeed sacrifice performance and I won't deny that, I just gave you 2 native code compilers.
Did you just not notice that, or is there a reason you found them unacceptable?
First off, the standard extension for scheme files is .scm
Not really relevant, but I thought you'd want to know.
Since Chicken's non-reentrance only matters if you're passing callbacks into C code, I'll assume you're doing that. It should be noted that Chicken can sort-of have callbacks, so it may be acceptable for your use-case. Either way, be careful to return from C calls in the same order you entered them: not doing so will crash your program. It might seem hard not to do this, but call/cc makes it very easy, and having another thread return into C causes the same problem, since scheme execution threads are pre-emptive coroutines, and are thus one thread from C's perspective.
The problem with the code above is that by default, Gambit generates a shared library for use in other compiled scheme code or a repl. To get an executable, you must specify -exe:
gsc -exe t.scm
Note also that Gambit's configure script option page (http://gambitscheme.org/wiki/index.php/Configure_script_opti...) provides some handy options to feed to the configure script to speed up the interpreter, notes the reccomended use of GCC (although GCC is not necessary!), and also specifies how to use Sun's compiler to generate 64-bit code on SPARC architectures, if you want to do that. If you're using GCC, this shouldn't matter.
Also, I'd reccomend reading both gambit's manual and the R5RS standard. Knowing the standard and your implementation's deviations and extensions to it is important. Be sure to read the wiki as well, as gambit's manual is not as complete as the wiki.
schemers.org and the scheme wiki have a lot of aids for learning scheme, especially some of the stranger parts, like call/cc.
The Scheme Programming Language Third edition (not the 4th edition, which covers the much-maligned R6RS), and The Little/Seasoned/Reasoned Schemer series can help you think like a Schemer. Scheme is thoroughly multi-paradigm, so this is important.
Finally, there's a lot of gambit libraries all around. The Black Hole and SchemeSpheres module systems contain most of them, although some of SchemeSpheres is linux-specific. You may also take advantage of SLIB, one of the few portable scheme libraries, which contains a wide variety of handy utilities, and SXML, for processing and outputting HTML/XML without the hell.
Whatever you do, you'll probably have to write a lot of FFI code, because the library you want probably isn't wrapped. It's a little better in other schemes, mostly Chicken, but not really that much. It's just the price you pay for using a less popular language.
Are you a Plan9 user, by any chance?