1. 9

    This is essentially the same argument that Tom Scott made in his video ‘The Art of the Bodge’ [1]. I remain sceptical that better solutions could not be achieved in Linux, but at the end of the day it’s about what tools work for you.

    [1] https://www.youtube.com/watch?v=lIFE7h3m40U

    1. 2

      That was a fantastic listen and you should submit it as an actual article.

      1. 2

        It was a great video. I can relate to the why’s and benefits of bodging.

        Although, I have to say that bodging the safety-critical situation they did the way they did was the most opposite of all high-assurance principles I’ve seen in production in a while. Glad it worked out. I’d have probably drawn the bodging line there switching to cheap and lazy approaches that were extra careful.

        1. 2

          one of my more.. dubious of bodgings with durden went something like this:

          /global/settings/timers/periodic/add=yeah:1=/global/display/region/ocr=0,0,300,100 /global/settings/timers/periodic/add=dont:60=/windows/group/remote/clipboard/paste

          now, hypothetically, there might have been an RSA SecureID token hanging in front of a webcam ..

      2. 2

        I expect the lack of a standard GUI API on Linux would make something like AutoHotKey more difficult to achieve. AHK relies a lot on low level aspects of the Windows API to select windows, activate them, send them messages, send keys, read the clipboard, etc. I would think that would be more complex to do in Linux.

      1. 2

        “Work”: Because I committed one of the unforgivable sins of entering dashes with my SSN into my state’s unemployment system, I have to call a helpdesk to fix it at random times and hope I get a connection that doesn’t automatically ring to a “too many calls, goodbye click” message.

        So I’ve made my animation tools project my “work” in lieu of any other solid job connections. This now involves:

        • relearning Windows configuration to run and study tools like Source Filmmaker in a stable environment.
        • writing a Nix derivation for arcan to use it in my daily-driver OS.
        • mapping out the Blender 2.8 source with doxygen and other introspection tools.
        1. 2

          If you are not on the IRC already, poke me there if you run into any issues. Finishing up the next networking transparency bits then the test/record/write/release process.

        1. 1

          With libraries like imtui, I may start using the mouse more. I’m using it to write a small debugger/stepper for my emulator and it’s been a pleasure.

          1. 2

            I didn’t know about imtui, that’s cool! (I’ve heard of Dear imgui).

            What motivated this question is trying to find a good front end for GDB. I’m now tempted to try to write one with a framework like imtui…

            Because Eclipse crashed (and even locked up my entire computer), and GDB’s TUI mode gets confused when the debugged program prints to stdout! And I couldn’t get gdbgui to work.

            Of course whatever I write would be just as unstable, although maybe the imgui model would help that? I think “inverted” control flow is harder to get right. But I’ve never used imgui so it could have different problems.

            Yeah looking at imtui more, this is a very tempting project. GDB has quietly gotten super powerful over the last decade, and it needs a small and fast UI. And imtui even has mouse support, which is awesome! Debugging really benefits from mouse support.

            And it runs in the browser! (though I saw some glitches). I have a hunch that gdbgui’s concurrency problems could be made simpler with imtui… or maybe it would hang the UI. I’ll have to think about it (and get familiar with GDB’s machine interface)

            1. 2

              so I share the same sentiment and need for a better gdb/lldb TUI. Debugger capability is in a quite interesting state factoring in RR etc. but the HCI is, to this day, not even at the level of Turbo Debugger.

              If you want an OK abstraction with all the python on top of it, save the effort and go for voltron, gdb MI (and lldb-dev for that matter) leaves … much to be desired and, if python can be tolerated, voltron has done some of the heavy lifting.

              When I am finished with a neovim UI, my next target for arcan-tui is gdb/lldb to finish the chain of leveraging the display server to improve debugging by dipping into LLDB/GDB. Happy to collaborate.

              1. 1

                Thanks for pointing out Voltron! I didn’t know about it, but that is the first TUI I’ve seen that uses GDB’s MI? Well I suppose emacs does it too.

                It doesn’t seem like Voltron exposes GDB’s Python pretty-printing plugins, which I just used and found essential! [1] But I will try it and see. I’ve wanting to write a blog post called GDB quietly got awesome in the last 10 years :-) I was surprised now nicely and tightly integrated the Python plugins are with GDB.

                I had some grand thoughts about shell being TUI for “outside” processes and a debugger being a TUI for “inside”. The GDB command language is of course very shell-like, and the TUI shows relevant state, although there’s a lot more room for improvement.

                (I also played with rr recently [2], but then I discovered that GDB’s has its own reversible debugging, which could be efficient enough for a shell.)

                And it does seem Arcan is relevant to this thread in multiple ways. For one, it appears that using a mouse with terminal apps isn’t completely normal or well-adopted. Apps support the mouse in different ways, and fight for the mouse.

                I do think a better TUI interface could help with that, although I don’t know how it will get adopted.

                I read the blog post and watched the video, but I only have a hazy idea of it. I agree with the general idea that terminals and TUIs are sort of an archaic and old display server. And debugging is a great use case where the state of the art needs improving. I remember reading about Arcan a few years ago and being impressed with its scope and ambition.

                Personally I have been coloring outside the lines a little too, and have have this fork for over a year :-(


                I guess that is analogous to your neovim patch – to fix apps on the other side of the wire.

                I’ve also been brainstorming better UIs for shell (over on https://oilshell.zulipchat.com/ , all are welcome there). And a lot of shell is limited by terminals. But I’m still struggling trying to meet existing use cases, rather than coloring outside the lines. But brainstorming never hurts :-)

                I should refresh my knowledge of Arcan. Looks like you’ve made some great progress lately!

                [1] https://github.com/oilshell/oil/blob/master/devtools/oil_gdb.py

                [2] https://github.com/mozilla/rr/wiki/Using-rr-in-an-IDE (it works under Ecliipse for me)

                1. 1

                  For one, it appears that using a mouse with terminal apps isn’t completely normal or well-adopted. Apps support the mouse in different ways, and fight for the mouse. do think a better TUI interface could help with that, although I don’t know how it will get adopted.

                  I think there is a ‘mouse protocol’ for any possible permutation and range for each possible type of input that a ps/2 class mouse can deliver. The only universal is that the one you need won’t be implemented correctly by the terminal emulator you have, the client you are using, or both.

                  Problem with adoption is that if things stop at just replacing ncurses (and there are quite a few such replacements) we never get further with latency, integration and so on. If actually attacking the entire chain (emulator, shell, application) getting adoption is much, much, harder.

                  The tactic I am settling with is:

                  1. arcan + the included ‘console’ WM [1] running with the SDL backend (OSX, X11, other Wayland compositors, Old FBdev embedded etc.) works as a substitution for the ‘terminal emulator’ kind of use case, and there is a terminal emulator for the shell to use.

                  2. arcan-tui library can do server-side rendering these days, packing updates into a wire format.

                  3. (incomplete) taking shmif-server library (for the IPC setup), compositing and rendering the format from (2). allows for an application that can then composite back into ncurses/regular terminal as well as translate input, solving the other part of the legacy chain. There is a simplified arcan build that only provides the libraries for this.

                  4. arcan-net tool handles runtime network redirection

                  As for writing new shells and autocomplete, some changes has been made for that case recently.

                  In afsrv_terminal (the terminal emulator in arcan that renders using tui, has a ‘cli’ mode where you get the readline prompt and the setup for launching new clients from there as either legacy terminals or arcan-tui applications, but they spawn as discrete objects on the WM level, detached from the shell as such. This cli mode could outsource the analysis and querying to oil,

                  If launched as an arcan-tui application, it is expected to have an argument eval mode where the shell can interactively submit arguments and expect completion in return or parser feedback as to failing argument and offset. The hooks are there, some more UI magic before this is working completely. This means the ‘shell’ can be implemented on either the level of the ‘tui-shell’ or the wm level of the application arcan is running.


                  1. 1

                    OK interesting, it sounds like you have a path, and we are thinking along the same lines.

                    This discussion clarified to me that Oil should have a configuration / mode that’s completely separate from a terminal. After all, a language like Python, Ruby, or JS is also separate from the terminal.

                    And GDB is an engine that’s separate from the terminal too.

                    So hopefully Oil can do its bit to get rid of some legacy, or at least it can not lock us in further to legacy :)


                    So I think there could be an oil-tui, oil-native-gui, oil-web-gui, oil-arcan-tui, etc. If we design for the first 3, then the last one should be feasible, though I’d be interested if you think there are reasons that wouldn’t be true.

                    On a related note, my head spins when I think about Arcan, because it is such a big task.

                    For context I’ve been working on Oil for 4 years, and just recently one of the first patches to run a shell script with it landed upstream [1]. In contrast, the bash-completion fork I made over a year ago has languished. I don’t have time to upstream it, and others won’t be motivated to until they use Oil. Of the users that have the motivation, only a small fraction have the knowledge.

                    It sounds like you are addressing a lot of real problems so I hope that it can be adopted. My experiences with gdbgui and Eclipse wrapping GDB makes me think that the status quo could be a lot better. Then again, there are the rare good GUIs here and there that use existing tech, but core tech like debuggers are especially short on develoopers.

                    I think if I want to make concrete, short-term improvements to my debugging experience, I should look into patching GDB, or writing plugins. Unlike bash code, which I think is unsalvageable, it seems like GDB is pretty modular and hackable? I like the Python API, even though Python isn’t my first choice for embedding. It makes good use of Python’s object model. Crossing my fingers :)

                    [1] http://www.oilshell.org/blog/2020/04/release-0.8.pre4.html#the-highlights


                2. 1

                  FWIW, after thinking about it, I filed this issue for Oil:


                  Basically the idea is that you could have a shell running in something that’s not a terminal. It would have some kind of RPC / IPC interface to execute commands, get responses and error messages, and respond to completion queries, history queries, etc.

                  Oil is pretty modular so I think this will be possible: http://www.oilshell.org/blog/2020/04/release-0.8.pre4.html#dependency-inversion-leads-to-pure-interpreters

                  This also “offloads” a lot of work I’m struggling to finish… i.e. Oil will provide a basic bash-like interactive experience out of the box, but a lot of people want more than that. So I think it’s useful to have UIs as separate projects, whether TUIs or GUIs, etc.

            1. 2

              $WORK: N/A, +set mode weekend

              $RELAX: Time to build some more toys for the puppy, she is getting restless. Since I forgot last post, here is more puppytax to make up for it. Begging for a piece of my chicken, Playing fetch the ball on a string. Incidentally the GFYcat shortname, ‘quaintlivelydrongo’ is darn descriptive.

              $RESEARCH: Trying to generalise some sandbox escapes through Wayland to add to the infosec presentation buffer or CTF/pwnable challenge pile. Vuln+Infoleak is easy, robustness much harder. Also playing with libsignal-protocol-c and neovim UI api.

              1. 9

                $WORK: Negotiating new contracts after being laid off, can afford to be picky so taking it slow.

                $PLEASURE: Took the tactic of ‘keep calm and adopt a puppy’ so a lot of puppy training.

                $RESEARCH: Side-channels on remote desktop protocols and related crypto designs.

                1. 2

                  We need a puppy picture here.

                1. 3

                  I’m juggling with two projects this week so there’s not much time left for non-essential things. So here’s what I’ll probably postpone:

                  • Fixing our espresso machine. It’s a clunky, unpretentious thing but it’s one of the first presents I got for my wife when we moved to our apartment years ago, so there’s no way I’m giving up on the little bugger.
                  • Playing with wlroots, which I really like. I’m piling hacks on top of tinywl in the hope of eventually producing something that resembles the old Workbench interface. Wayland (and the tools around it) are finally stable enough that I can realistically stay on top of Wayland-related code even if I don’t touch it for weeks at a time.
                  • More of the cryptopals challenges, *sigh*.

                  On the other hand I’m pretty happy with the projects that I’m involved in right now, I don’t mind cranking up the pace for a few weeks/months.

                  1. 2


                    If water canal is clogged: use formic acid (which is often used by central heating professionals to decalcinate the hydronic parts of cast furnaces, but you can also buy it especially for espresso machines, at a premium). rinse with deionized water or destilled water and compressed air. caution: formic acid is not kind to skin or eyes, wear safety glasses, gloves and old, long sleeved stuff. But it only goes after the calcium and not after the chrome. it may happen that the clog compund was calcium and some form of biofilm. formic acid will only remove the calcium, the rest of the biofilm will still be there. in my case the pressurized ait got out everything, but you could use some lye out of demineralized water and dishwasher tabs (these have enzymes which eat up proteines, also proteines of biofilms. Rinse even more after using the dishwasher lye! You could also use pipe cleaners, but I found these harder to come by than the chemicals.

                    1. 1

                      Oh, thanks! Formic acid was one of the things my mind raced to but I thought it would be overkill for a silly espresso machine. Good to know it’s not. I’d rather avoid things that require me to put on safety glasses, but if it turns the deposit is too nasty, formic acid it is!


                      As luck would have it I actually do smoke pipe, and have a handy supply of these!

                      FWIW, any place that also sells pipe tobacco is bound to carry them. Not just tobacco shops – I get mine at a fancy wine shop that’s pretty near to my place (I don’t really like the place but I regularly run out of pipe cleaners and it’s the closest place where I can get them). They aren’t advertised anywhere and they don’t sell pipes, either, I asked on a whim.

                    2. 1


                      as in this style: https://www.youtube.com/watch?v=3O40cPUqLbU

                      or one of the fancier new ones?

                      1. 1

                        I’m aiming for something that’s closer to what you could get in 3.9, something like this or like this, for example.

                        The rate at which it’s happening is about one weekend per month, though, so it should be out just in time for the new Amiga :).

                    1. 2

                      digging into next-gen desktop network transparency, likely crypto bits and key management - https://www.youtube.com/watch?v=_RSvk7mmiSE for current state.

                      1. 3

                        I really like this work and it goes to show that a lot of places where people use C are not because they need to be fast, close to the metal, or unsafe: they just need to tightly interop with code that has those requirements. There’s a huge amount of code in any monolithic kernel that is not performance-critical (though often is safety- and security-critical), that doesn’t need to do anything that would violate type safety in a type-safe language, but ends up being written in C. There’s also a load of code doing things the wrong way in C because it was prototyped in C and it was too hard to refactor later: Starting with a crappy Lua implementation, getting the algorithms the right shape, and then replacing it with a C/C++[/Rust/whatever] implementation with custom optimised data structures would get you to a much better place quickly.

                        1. 2

                          Yes I agree, that is basically how I’m writing Oil shell, e.g.


                          In other words bash is 140K lines of C code. But really it’s about 100K lines of “groveling through backslashes and braces one-at-a-time in C”, which is hard to maintain and error prone, and it’s not even that performance sensitive. (bash has basic bugs in parsing in 20+ year old language constructs.)

                          I focused on the algorithms first and then I was able to speed it up by translating to C++. If you look at the C++, it looks far from “optimal” – not what you’d write by hand – yet it ended up faster than bash and much faster than zsh.

                          I believe that’s because nobody can write 100K lines of C optimally. You always end up making compromises and making a mess. Writing 1K lines of C optimally is easy (and pretty fun in its way), but writing 100K lines is close to impossible. You need multiple hands in the program at that point. (Rare execptions like sqlite took over a decade to reach 100K lines.)

                          And kernels have that property too. There’s a mass of code that does pretty basic/repetitive things and is not performance sensitive.

                          So I wish there were a language that’s tightly integrated with C (and C++) but that’s not so tedious. Most languages have FFIs which are not that pleasant, or wrapping tools that are OK for common cases, but fall down for complex things.

                          1. 1

                            Having used Lua as the ‘safe’ keyword for C code since the early 2000s, I can (mostly) only agree. There are some ergonomics that are troubling (repeatedly needs to say to myself ‘now it’s base + offset’ and ‘now it is index’ when switching between the two), I would also happily take a reduced version that deals away with metatables and that jazz, as well as a switch to same:ish symbols and syntax. With the fragmentation caused by LuaJIT and some of the other decisions post 5.1 - I am now somewhat inclined to consider a secondary position.

                            1. Use Lua C API as the binding format.
                            2. Have a compile-time switchable ’binding outputs msgpack-rpc as an alternate implementation of ‘lua_’ (push | pop | pcall)
                            3. Let [2] interface with other languages (or even Lua) out of process.

                            Ideally this means that one can still use the C software in the Lua fashion, but to elevate security (seccomp/pledge with stricter profiles) / stability (attach / detach the high-level side) / debugability (not mixing language runtime semantics and stdlib in the same process) and language choice.

                          1. 3

                            Experimenting with some of the concepts from userland. People musing about the various CLI benefits in recent threads should definitely take a look at hisham’s work (and thesis) the infrastructure itself is a dead end but the rest holds some promise.

                            When dull from that I’ll dust off some input device work, currently on the lookout for an (time, two or three analog axes, 1..5 digital inputs) trainer + classifier that does not rely on throwing numbers at (A)NNs but actually has thought put into it ..

                            1. 3

                              Why do you think the infrastructure is dead end? I tried to get through the source but the lack of comments makes it slow for me, and haven’t properly read the thesis yet.

                              OTOH, I’m mulling over an idea of adding a feature that would make it possible to write userland modules controlled over a pipe-based interface (akin to language server protocol), to make it possible to write them in any language. I’d love to be kept in loop with your experiments if somehow possible, by the way. Also, I’d love even more if you could consider including a pipe-based plugins interface in them! Though I’m not sure if it can work with the “flow” ideas from the thesis, esp. as I only skimmed it…

                              1. 2

                                The cool thing with this, in my opinion, (warning, my academic former self talking) is the whole spatial-modelling processing chains in multiple dimensions; how ‘spreadsheets’ are used as a language to cross-reference and stitch data flows together, and modify/run/repeat workflow. That it also lends itself well to a ‘zooming’ WM is just icing on an already delicious cake.

                                As to why I consider the infrastructure a ‘dead end’ comes with how poorly the data processing scales, how frail it is, and the division of responsibility. All real processing and computation is done within the UI process - this will be janky like nothing else when you dip into 2-3 digit number of steps.

                                ( For background / bias, though don’t punish yourself by reading through it, just showing that I’ve done my homework: https://github.com/letoram/arcan/wiki )

                                Now, way before all that, I had pretty much the same engine / processing structure, and a marginally less terrible API/rendering model than Love2D (resource management was at least asynchronous, GPGPU not an afterthought, and the Lua-VM price isn’t payed ‘per frame’). The wall I hit (2006-2007ish but things have not changed) is that reliable/portable GL forces you to do much on the main thread (context juggling was/is just inviting driver bugs), image parsers are crashy garbage and the multimedia side exponentially so. You really want process separation here, and a lot of it. Which means there need to be an IPC system that can juggle multimedia, interactively. Fsck, that’s a “display server”. Then the world got much darker.

                                As for being kept in the loop, First as a standalone WM that can be integrated in my bigger one as a plugin. That’ll likely just be in the open as a git. As for a pipe based interface, there already is. Poke me on IRC/Wire if you want a solution, for hints, read the ‘writing a WM’ article, and look at the documentation for the ‘bond_target’ lua api call.

                                1. 2

                                  Oh my, I didn’t have a slightest suspicion you’re the author of Arcan! That puts things in a very different perspective :) I don’t use Wire and rarely connect to IRC (and I already have Keybase, Signal, and a few others on my phone…), so maybe I’ll try pestering you on private lobste.rs messaging, FWIW…

                              2. 2

                                Wow wow userland looks AWFULLY cool. It’s like somebody took the ideas behind Jupyter notebooks and went 4D :)

                                When I first saw that I wondered if it was Dave Winer’s “Userland Frontier” which I can’t even find references to on the web anymore. Needless to say this looks much more interesting :)

                                1. 2

                                  the spreadsheet tactic has quite a lot of merit to it, with some zoom in/out controls, paging etc. it can likely be quite effective - it gets a bit grittier when the input outputs aren’t 1:1 though, don’t immediately see how that doesn’t devolve into a ‘graphedit’ of win32 media-fame.

                              1. 19

                                I do not agree with the last point. Debuggers are useful and use of one does not point to poor code quality.

                                1. 5

                                  I agree. I don’t see how using a debugger is any different from one of the suggested alternatives:

                                  Use print statements

                                  If I see code littered with echo or printf or logging statements, it says to me that you’re not sure what the code is doing there and you want some insight.

                                    1. 2


                                      I think this only holds if you know all the ways in which the code is driven from the outside. Many of the bugs I find, at least in my code, are the result of emergent behavior I didn’t completely foresee. They are bugs in their own right, sure, but they tend to be manifest themselves only when my code runs in the scpoe of a larger system.

                                      In such a case I find it immensely useful to have prints, logs or traces all over the place so that I can see how the system is driven into an error state. Having the prints can also mean you’re not sure how your code is being used.

                                    2. 5

                                      95% of the time I have to use a debugger, it is because the code is not written in a simple and obvious way.

                                      The other 5% of the time it’s because “some other weird thing is going on.”

                                      Having to use a debugger to understand what code is doing is absolutely a sign of a poor code. Good code can be read on its own and understood with a very high degree of confidence.

                                      Of course, as a programmer working with other people’s code and legacy systems, knowing how to use a debugger is important. But it still usually means you’re working with code that is overly complex.

                                      1. 2

                                        You can also completely understand how a piece of code works, but don’t understand why it exhibits certain behavior. This happens when your code is used in a big opaque system, and it happened to me a lot. For example:

                                        class Person {
                                            public Person(string name, int age) {
                                                if (name == "" || name == null || age < 0 || age > 150)
                                                    throw new Exception("Invalid person.");

                                        If the exception is thrown, it is obviously the caller’s fault. But if this exception shows up, it’s not immediately clear where something is going wrong. You would need to read through the whole code to see what’s happening.

                                        Especially in languages with pointers or references, it is possible that a reference/pointer is copied somewhere in an unrelated function, and aliases with data you use. This way, data can be overwritten when you don’t expect it to be. I usually debug this by stepping through the code and watching the data.

                                        … and yes, it does mean that the code is not perfect. But hey, mistakes do happen.

                                        1. 1

                                          The problematic code in this case – from the perspective of my original comment – is the system code.

                                      2. 2

                                        Debuggers are symptomatic of not understanding the code. Agree or disagree?

                                        1. 11

                                          Oscilloscopes are symptomatic of not understanding the circuit.

                                          1. 2

                                            Yes. If you understood what they were doing, you wouldn’t need instrumentation.

                                          2. 4

                                            Debugging is symptomatic of not understanding the code.

                                            I think Hintjens is saying your (understanding of the) code & recent change should be so clear you don’t need a debugger, while c-jm is saying debuggers can be useful even when your code is clear and your changes were small. Both are obviously true.

                                            1. 2

                                              I think they are orthogonal really, code can be clean and hard to debug all at the same time.

                                              Elements of “clean” code can also lead to making debugging harder. The more functions you have to do smaller things while more easily readable always introduces context shifts etc.

                                              As with everything there are costs and benefits to every decision, all my point was is that in terms of a code quality the need to debug is not a good metric.

                                            2. 1

                                              What’s “the code” though. Abstractions layered upon abstractions. Finding bugs without debugging in legacy code or multi-threaded code is almost impossible without debugging.

                                              1. 2

                                                I don’t dispute that.

                                                Yet if you indeed are able to understand your code without a debugger, that’s a very good thing.

                                            3. 1

                                              Often you need to debug code somebody else wrote.

                                              1. 1

                                                “Need” is the key part. Debuggers are super useful, but if I require them to do my job, then something is wrong.

                                                1. 1

                                                  In my mind, debuggers are a great tool to validate and to enhance your understanding of how the code actually works. I have sympathy with the thought that it should not be necessary to run your code with a debugger to understand it. What I find weird is that the author puts this in a list together with “If your language offers a REPL that’s cool. “ which is for me in the same category of exploratory tool.

                                                1. 3

                                                  I want a physical button on my keyboard named “LOCAL”. It’s a modifier. And I want there to be no mechanism for sending any “local” codes to a remote machine. In fact, I want the specifications for any interstitial infrastructure to explicitly forbid the transmission of such codes. They’d be of extremely limited use, because of that. Perfect.

                                                  1. 3

                                                    do elaborate, why would you want this?

                                                    1. 9

                                                      I want a key that is just mine. I don’t want RET ~ . to terminate a ssh session. That strange invocation is required because all the other keys are being sent to the remote. I want LOCAL+c (like ctrl+c, but guaranteed to be received and handled locally). I bet I could find more uses for it, too.

                                                      edit: fix typo: terminal –> terminate

                                                      1. 2

                                                        ah I see, thought it was something in the more eccentric side where similar phrasing has been used, but there the meaning was about input modes that was used to taint tag input to prevent it from crossing certain boundaries (oops I pasted the password thing into the wrong window that happened to be networked).

                                                        1. 1

                                                          That’s in the ballpark, I guess. (I have a passing familiarity with ‘taint mode’ from perl?)

                                                          The first example I was thinking of was something like “7-bit ascii” vs “8-bit ascii”.. (See https://en.wikipedia.org/wiki/8-bit_clean I guess.) But, the control codes are all represented within the first five bits so, not the example I was thinking it was!

                                                          The second example is Private Address Spaces. 192.168.*.* and friends don’t get passed between routers. Sure, some manufacturer or crazy admin could break that rule, but they’d be “wrong, wrong, wrong!”, and everybody would know it.

                                                          I want a button reserved for private use. Now that I thought it through, my idea is clearly not about terminals. Sorry OhhhhYeaaaaah. :)

                                                  1. 4

                                                    This is a nice writeup! It’s a long game and it makes me happy that people care about playing it.

                                                    1. 3

                                                      He might be offering it at select places (Recon, …) but his training on safer C is quite interesting, especially some of the political commentary about how the power dynamics work within such a seemingly boring standards group.

                                                      1. 1

                                                        Interesting, are they accessible to people with mediocre C experience? (or maybe even recommended?)

                                                        1. 2

                                                          intermediate to advanced - you get a lot of patterns to memorize / look out for auditing code - and enough self study to last for a while, also a fair bit of posix parts as well, it’s kindof necessary to combine the two. It is quite pricey though.

                                                    1. 5

                                                      Beating Dark Souls (for PS3! Yep, people are still playing) after like 2 years. Just beat Gravelord Nito and fighting Demon Firesage. This game has been SO hard because I ended up 1. Killing the Blacksmith in Undead Parish and 2. Thought fighting Sif the Wolf at level 24 was the normal thing to do 3. Having no idea what the stats REALLY do and how weapon scaling worked. I grinded levels to make the game bearable and now I’m 81 with Smough’s Armor and Gravelord Sword +4 since I had so much Demon Titanite saved.

                                                      I would like to maybe try rushing out this memory game idea I had. I’m playing with ggez (Rust graphics library inspired by LOVE from Lua) as a precursor.

                                                      1. 2

                                                        I started out DS1 by going down the graveyard and skeleton path, and instead of taking every possible hint to explore elsewhere I got really good at exploiting AI pathing weaknesses. Got all the way down to the gate block before taking the hint that maybe, maybe take the other road from the shrine. The game got much more enjoyable after that.

                                                        1. 1

                                                          Yeah after awhile, I think majority of players that finish the game who had a hard time end up being better than most, because you’re forced to have totally dissected how the AI code is working, and also you end up with this really good sense of direction and can “see” the level design eventually. I think I got through 2/4ths of the game now in like less than a month of on/off playing.

                                                          Got all the way down to the gate block

                                                          Heh, about 5 minutes further and you could’ve had the Gravelord Sword early.

                                                          1. 1

                                                            Been on a roguelike binge (isaac, gungeon, dead cells) for a while now, but every Soulsborne marathon I start DS down there for the great scythe.

                                                      1. 2

                                                        I’ve queued up a number of USB HID devices that needs some reversing. To step out of my normal ‘script for open + send report read and pipe into xxd’ flow and comfort zone, I’ve started writing a TUI tool to handle collection, fuzzing, diffing, visualization and note taking. The tool is about ‘good enough’ now that I am going to start testing it.

                                                        1. 2




                                                          1. 7

                                                            I experimented with this a while back as a possible lossless carrier for remote desktop- style applications for window contents that had lossless,interactive as requirements.

                                                            Some really nice choices in this one, including YCoCg as colorspace and the ability of being able to progressively render the contents on slow network links - which meant the user could get enough visibility to make input decisions and cancel the ongoing image transfer in favour of the next one on input.

                                                            The downsides at the time, as with bootstrapping any new image compression really, is that it was too slow to be practical over accepting lossy on back pressure, ramping up the bitrate and go with h264 I-frames from hardware encoder.

                                                            1. 1

                                                              Got a Go on the cheap a few days ago, intended as a dev machine for input method work {touch, pen, dial}. Added a little homebrew wireless usb-to-ble dongle made from an arduino and some motherly love (some extra security featurer over a normal bluetooth keyboard) to get a decent mini mechanical keyboard. it’s is shaping up as my favorite mobile devstation.

                                                              Currently running linux (void), problems with the regular suspects (sensors, wifi).

                                                              Only thing I miss from my normal laptop setup is eye tracking,

                                                              1. 2

                                                                Finally made some progress getting the HP Reverb to a usable state for VR desktop dev. work so a lot of that going on. Still need to forward the USB to a windows guest VM to get it to do the initial setup foreplay, but quality wise it’s decent enough for longer sessions now.

                                                                Heading over to 36C3.

                                                                1. 2

                                                                  Chipping away at the article draft bin that is overflowing, got some interesting things to put out there before EOY, maybe as early as next week. Submitted something for a conference, the aftermath anxiety tend to bring out some good ol’ insomnia so there’s that. PoCing a vulnerability or two. Finishing an open source proposal @ work. Processing the death of a friend and fellow explorer.

                                                                  1. 3

                                                                    Work: Heading over to Tokyo for some change of work scenery, and (a little later) PacSec. Finishing up some blog posts that have been pending for embarrassingly long and, relatedly, continuing some experiments on cleaner ways of setting up a process for debugging (friends don’t let friends sudo -p).

                                                                    Social: With anata no warehouse closing down soon, there’ll be some classic arcade entertainment there and at mi-ka-do.