Wednesday, April 08


Daily News Stuff 8 April 2020

Mighty Hunter Edition

Tech News

  • I downloaded Nim and installed it on WSL and compiled a trivial test application and...  It worked.  Completely painless.  Compiles in roughly a second, most of which is spent loading the compiler because WSL is kind of slow at initialising binaries.

    The compiled size for a trivial app that just reads some text from the user and responds is 90K.  75K stripped, 41K upxed.  (upxed binaries don't work on WSL1 though.)

    That's pretty acceptable; I'll rewrite my Crystal system monitoring agent in Nim and see how it goes with a simple real-world app (it needs, for example, HTTPS support).  On advantage I'm hoping to see from the C back-end is a smarter linker than Crystal has.

    The problem with using either one seriously at my day job is the state of the MongoDB drivers, since we have many terabytes of MongoDB databases we aren't about to migrate.

    Both come with MySQL and PostgreSQL drivers, and Elasticsearch is a REST API and therefore not a problem, but we need solid MongoDB support.

    Update: With the HTTPClient and SSL libraries pulled in - and working, since I had it actually download this page - the binary is 287K in full or 97K stripped and upxed.  That is entirely acceptable.  It's an order of magnitude smaller than the Crystal equivalent.

    Update Two: Wait, is that really a static binary? My usual test is to drop it on a horribly out-of-date Linux box and see if it still works, but I just turned off all of those.

    The documentation suggests that Nim builds static libraries by default, but that's awfully small if it's really pulled in OpenSSL.  I suspect that it might be "static except for OpenSSL" or some such nonsense.  But then, that's pretty much what Crystal does on Mac.

  • Replace the innards of your Gamecube with a Ryzen 3200G-based Gamecube emulator.  (Tom's Hardware)

    Because why not?

  • So in what sense is OpenVMS open?  (Legacy OS)

    The final hobbyist licenses for OpenVMS will expire at the end of 2021.

  • A look at the Xeon 5220R.  (Serve the Home)

    Wait, didn't we just do that one?  Oh, that was the 6226R?  Okay.

    This is a 24 core Xeon at a sharply reduced price compared to last year, as Intel struggles to find a way to compete with AMD.  And mostly fails, to be brutally honest.  It's beaten soundly by the 24 core Epyc 7402, and in many cases, by the 16 core Epyc 7302.

    Where the 6-series supports up to four sockets, the 5-series only supports the more common two.  Although the 6226R also only supports two sockets, so there's not a huge difference here.

    In short, it's a much more cost-effective chip from Intel if you're stuck with Intel.  If you're not stuck with Intel and don't need a ton of RAM per sever, there are faster better cheaper options.

Video of the Day

Reassuringly, these things are tiny...  Mostly.  The Spanish dancer, the bright orange swimmy swimmy one in the video, can grow to as much as three feet in length.

Disclaimer: And lots and lots of feet in feet.

Posted by: Pixy Misa at 10:17 PM | Comments (5) | Add Comment | Trackbacks (Suck)
Post contains 529 words, total size 4 kb.

1 I was pretty impressed with WSL1 in some regards.  I threw XMing on there last year and tried a handful of X apps:  XScreensaver (don't tell Jamie Zawinsky), XEyes, Emacs, Chromium, etc, all worked fine, although they ran at godawful software-accelerated speeds and I didn't bother to try to see if proprietary driver blobs would fix that.  I know there are issues some people ran into but for everyday stuff it ran everything I threw at it. I would suspect most Linux devs could use it for their day jobs.  Haven't tried WSL2 yet.  Is UPX the "Ultimate Packer for Executables"?

Posted by: Rick C at Thursday, April 09 2020 01:05 AM (Iwkd4)

2 Yes, that UPX.  There are a few odd corners like that, and memory-mapped files, where WSL1 falls down completely.

Posted by: Pixy Misa at Thursday, April 09 2020 02:01 AM (PiXy!)

3 Possibly-silly question:  in this age of cheap storage, is exe crunching that important, practically speaking?

Posted by: Rick C at Thursday, April 09 2020 03:45 AM (Iwkd4)

4 Rick C.: I've heard tell that smaller executables fit better in cache, which for some workloads is what you would hypothetically want.
And, yeah the "Open" in OpenVMS is the same use as XOpen (the group that would sue you for using unix in the 1990s).  It just indicates that the thing adheres to some broadly published standard, unlike MS-DOS, MS-Windows, all that IBM stuff like MVS, etc etc.

Posted by: normal at Thursday, April 09 2020 04:20 AM (obo9H)

5 When the binary is hundreds of kilobytes, UPX isn't really important.  But Crystal pulls in the whole of every library you link, and automatically generates specialised versions of functions that take variable parameter types, so it rapidly grows into multiple megabytes.

Posted by: Pixy Misa at Thursday, April 09 2020 09:36 AM (PiXy!)

Hide Comments | Add Comment

Apple pies are delicious. But never mind apple pies. What colour is a green orange?

53kb generated in CPU 0.016, elapsed 0.205 seconds.
58 queries taking 0.195 seconds, 346 records returned.
Powered by Minx 1.1.6c-pink.