Announcement

Collapse
No announcement yet.

FreeBSD Picks Up Support For ZFS ZCP: Carry Out Admin Tasks Via Lua Scripts

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FreeBSD Picks Up Support For ZFS ZCP: Carry Out Admin Tasks Via Lua Scripts

    Phoronix: FreeBSD Picks Up Support For ZFS ZCP: Carry Out Admin Tasks Via Lua Scripts

    FreeBSD 12.0 will have initial support for ZFS Channel Programs (ZCP) for running administrative tasks on the file-system via Lua...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Correct me if I'm wrong but it looks like this involves embedding a complete lua interpreter in the kernel, possibly in a form that limits it to these zfs channel scripts. I was rather sceptical about NetBSD's inclusion of lua in the kernel. Does anyone know how that's turned out? Does it get much use and if so, what for?

    Comment


    • #3
      I very much like Lua and I think it's a sweet little language and interpreter, but why would you ever switch to Lua when you have perfectly well working shells on UNIX and for several decades? Seems like the developers got bored out of their mind, are clowning around or taken some mushrooms and have forgotten "the ways of the UNIX".

      Comment


      • #4
        Lua is much easier to write in than shell (FreeBSD does use (t)csh by default not bash btw), it's fast (much faster than shell scripts), very portable, small, embeddeable, easy to integrate with C/C++ because it has very good C API et cetera. It has it's flaws as well but pros far outweigh the cons.

        Comment


        • #5
          Originally posted by aht0 View Post
          Lua is much easier to write in than shell (FreeBSD does use (t)csh by default not bash btw), it's fast (much faster than shell scripts), very portable, small, embeddeable, easy to integrate with C/C++ because it has very good C API et cetera. It has it's flaws as well but pros far outweigh the cons.
          Lua also tends to be far easier to sandbox than shell scripts

          Comment


          • #6
            Originally posted by sdack View Post
            have forgotten "the ways of the UNIX".
            I'm sure Pottering was involved then.

            /sarcasm

            Comment


            • #7
              Doesn't that sounds like something that SMF illumos services (on Openindiana) like time-slider and filesystem/zfs/auto-snapshot should be doing?

              I see it's approved by: Garrett D'Amore , one of illumos founders , so knowing OpenZFS "Feature flags" ease of extensibility and compatibility, no doubt that feature could be available on all OpenZFS supported platforms.

              Comment


              • #8
                Hmm, I can see how you could write all kind of useful stuff with this but my alarm bells are ringing like crazy at the same time.

                Comment


                • #9
                  Originally posted by cen1 View Post
                  Hmm, I can see how you could write all kind of useful stuff with this but my alarm bells are ringing like crazy at the same time.
                  Lua interpreter is extremely deployed in the embedded and videogame sector, videogame designers love it and say it's far easier for non-programmers to use it than the rest of languages plus it's considerably efficient. You can make it fly with LuaJIT, I had hopes in the ParrotVM support but it seems like a somewhat dead project.

                  DynASM could be very interesting too: Kernel, drivers (even graphics ones), compilers...

                  There's another scripting language that is even more efficient than Lua, but not sure how easy it is and the resources (libraries, etc) it has It's Pawn (previously known as SMALL). Despite is considerably less known, it's quite used in games both officially and unofficially.

                  It's so lightweight that is suitable for very small power and very small processing capabilities devices such as microcontrollers.

                  Examples of use of PAWN :
                  - Devices Apple iPod...
                  - Videogames: Baldur's Gate: Dark Alliance...
                  - Other software: Enlightenment (but calls it Embryo)...

                  This would require extensive testing and sandboxing, plus modify it to the scope and probably making it a very focused subset. I see both NetBSD and FreeBSD/OpenZFS something a lot more interesting than people think and something it should be deployed extensively.

                  It could be very interesting for Packet Filer too...

                  Comment


                  • #10
                    Originally posted by timofonic View Post
                    This would require extensive testing and sandboxing, plus modify it to the scope and probably making it a very focused subset. I see both NetBSD and FreeBSD/OpenZFS something a lot more interesting than people think and something it should be deployed extensively.

                    It could be very interesting for Packet Filer too...
                    Most of the people would go by the assumptions: ncurses (or worse:text) installer, no effort at eyecandy - must be more primitive and drop the idea of tryin' right there.

                    I am getting more and more interested in DragonFlyBSD myself. It has OpenBSD's pf (FreeBSD's pf is pretty much dead-end in regards of OpenBSD pf's upstream, though it surpasses Linux's iptables), HAMMER 2 is arriving, Linux ABI in regards of video drivers is at Linux kernel 4.6, hybrid kernel, transparent disk encryption (incl ability to handle LUKS and TrueCrypt (100% compatible)), context-sensitive symlinks, fully SMP-aware disk subsystem, swapcache (smt like BCache on Linux) new network stack etc.. ton of stuff waiting to be discovered.

                    Downsides: spotty documentation, smaller amount of devs and users - software (ports) are more often buggy than on FreeBSD.

                    Comment

                    Working...
                    X