Threads for hspak

    1. 2

      Go 1.16 got a new feature that can replicate a similar behavior:

      1. 2

        I don’t think that this is really comparable, you still need to compile the Go binary for each ARCH/OS combination and adding or adjusting resources will require a recompilation.

    2. 3

      I think something like will fit what you’re looking for.

      1. 1

        This looks interesting. I had heard of Consul before but I didn’t put two and two together. Thanks!

        Have you used Consul in production before? How often might it fail, and how often do you need to update it due to a critical need (e.g. security vulnerability)?

      2. 1

        Also I think Consul is meant to be natively integrated into Kubernetes…and EKS costs something like $0.10 / hr which is $72 / mo…without factoring in EC2 costs on top of that. My budget is something like $5-10 / mo. for personal projects.

    3. 2

      Linux support on Thinkpads have always been pretty good. I wonder if this announcement means that Lenovo is putting more resources into linux support for their Thinkpads or if this has been an ongoing process and they’ve just recently hit a threshold.

    4. 3

      I’ve been using for several years. It’s a paid service, but I’ve been a happy customer!

    5. 2

      I think with the rise of Kubernetes and Docker. Golang become very popular.

        1. 0

          True Soon it will become the most sought out skill in devops

    6. 2

      While it’s great Microsoft is finally adding features to the Windows console, I’ve been a happy user of whenever I wanted a real terminal on Windows.

      1. 7

        The problem isn’t just what terminal to use: Most Windows Applications use the console API which sucks because it doesn’t support basic functionality that UNIX-based environments have had for years or map real-world expectations (e.g. the powershell example), and there’s nothing you can do about it except rewrite all the programs.

        The good news is that’s exactly what Microsoft is suggesting now:

        This issue further amplifies the recommendation to start writing (or update existing) Command-Line apps to emit VT enriched text, rather than calling Win32 Console APIs to control/format Console output: VT-enabled apps will not only benefit from rendering improvements like those described above (with more on the way), but they’ll also enjoy richer features available via VT-sequences, like 24-bit color support, and default foreground/background color support.

        That’s big news, and hopefully it’ll get more publicity than the closing remarks of a very long (and self-congratulatory) blog post, since it’ll only make tools like cmder better.

        1. 6

          Most Windows Applications use the console API which sucks because it doesn’t support basic functionality that UNIX-based environments have had for years

          As a developer, I often feel the opposite. The unix terminal is a crippled mess, while the Windows console works fairly easily. Look at keyboard input, for example. The Windows API will return nice key codes with modifier flags. It’ll even tell you key up events if you care! Unix terminals can only send you character events easily, and the rest of the keyboard is a mix of various sequences that may or may not give you the modifiers. Assuming the sequences are all xterm or using ncurses etc kinda sorta takes care of the various sequences. Kinda. Sorta. They still frequently don’t work or get broken up or have awkward delays (you can’t assume the esc char is the escape key without checking for more input). Some terminals send stuff you cannot detect without a full list.

          Oh, and try to treat shift+enter differently than enter in a Unix terminal program. Some terminals send codes to distinguish it… which can make programs do random stuff when they don’t recognize it.

          On Windows, the structs are tagged. You can easily skip messages you don’t want to handle. Of course, both Windows and unix are based on some underlying hardware and I appreciate the history of it, but…

          …I loathe the VT “protocol”. …but alas, rewriting all those programs isn’t going to happen, so I get it. And I know there’s some advantages. I like the pty thing as much as the next person - it is cool to be able to easily redirect all this stuff, and it is reasonable efficient in terms of bytes transferred, and the cooked mode has potential to massively decrease latency (though most programs turn that off as soon as the can since it sucks in practice)… I just wish we were redirecting a sane, well-defined protocol instead, and I prefer the console API as the base features.

          Oh well. Hopefully everyone will at least just agree to use xterm escape sequences everywhere.

          1. 1

            If they are referring to non-interactive programs with color output, and even shells with readline-style editing, then it’s better to port to standard VT protocols. Input is not much an issue for such programs, benefits are using more standard interface and being usable from SSH.

            For heavyweight TUI programs it might be better to stay with WinAPI, for the same reason that many users of Emacs prefer its GUI version (even on unixes).

            1. 3

              readline-style editing has a lot to gain by using a sane input system, too. No more ^[[3~ showing up when trying to edit something!

              But on ssh, note that Microsoft are actually handling this: they are putting a layer in the OS console driver to translate api calls to VT sequences when used through a pty. So it is still possible to use those programs over ssh. They are covering a lot bases here - I am excited to try it (my computer refuses to take the windows update with the new pty stuff so far though, so I gotta wait a lil longer. But I can test both my terminal emulator and terminal client library with it and see how it works - and I expect it will be cool to mix and match.)

    7. 2

      The Q&A get’s abruptly cut at the end. :(

      1. 3

        It’s on the Mozilla livestream:

        That’s a very clunky video link, though, requiring a livestream and an exception for it to create a popup.

      2. 1

        I think that was the last question :-)

    8. 6
      1. They want to move DNS to Cloudflare. I’m sure there’s still hot debates happening on mailing lists. This also means the plan isn’t final.
      2. They want to change the default behavior. People who care can opt-out. I’d say majority of their users (non tech savvy) don’t even know what DNS is and would benefit from using Cloudflare over their ISP for DNS (Comcast, ATT, Verison come to mind – I’d trust Cloudflare over them anyday).

      Maybe there’s been too many click-baity articles published already that’s saying Firefox is going to be shoving this down our throats. I see this largely as a net gain, if it happens to pass. But that said, there’s no reason to be outraged. If you’re upset, it means you care. And if you care, you can opt-out. Easy.

      1. 2

        You’re still replying from an overly US-centric view though.

        (disclaimer: I’m a PowerDNS employee)

        1. 1

          It’s a pretty common issue. Even outside the US.

          (disclaimer: I’m European)

    9. 4

      Regarding the security of unikernels, I believe that there is a reasonable rebuttal from Bryan Cantrill:

      1. 1

        Nice read, but doesn’t sound like Cantrill is unbiased here.

        1. 4

          He might be biased (joyent/containers vs unikernels) but @bcantrill’s opinions are usually more driven by wanting stronger engineering practices than marketing.