1. 1

    This is a really interesting article for FVWM3. Not too much seems to be tied to NetBSD other than installing packages and things like the exact volume control commands.

    Also it’s maybe obvious, but a screenshot of the result is at the very bottom.

    1. 1

      What’s up with the shrunken “mc” and “vi” windows (?) on the left of that screenshot — I’ve long since forgotten anything I ever knew about mwm… does it shrink/dock windows like that?

      1. 4

        twm-like window managers often minimize windows by putting an icon on the root, I think that’s just a preview of a minimized window.

        1. 1

          This says a lot about users of the desktop today… goodness me.

          1. 1

            It says a lot that I haven’t used CDE since the 1990s? There’s a lot I’ve forgotten in the past 25 years :-)

      1. 3

        You do always have the option of making tmux your login shell – as tmux understands this. It’s what I’ve done for years and that way I’m never not in tmux. Until it crashes, but that’s very rare these days.

        1. 28

          Unix was never as simple as we’d like to remember – or pretend – that it was. Plenty of gotchas have always been lurking around the corners.

          For instance, newlines are totally legit in filenames. So in the absence of insane names, ls |foo will write filenames with one name per line to foo’s stdin. Usually it’s fine to treat ls output as a series of newline-separated filenames, because by convention, nobody creates filenames with newlines in them. But for robustness and security we have things like the -0 argument to xargs and cpio, and the -print0 argument to find.

          For a system that is based on passing around data as text, the textual input and output formats of programs are often ill-suited to machine parsing. Examples of unspecified or underspecified text formats are not difficult to find. I’m really glad to see some venerable tools sprouting --json flags in recent years, and I hope the trend continues.

          1. 5

            Anything but JSON. If plain text is being used because of its readability, JSON is largely antithetical to that purpose.

            1. 14

              JSON fits a nice sweet spot where both humans and machines can both read and edit it with only moderate amounts of anguish. As far as I can tell there is not a good general-purpose replacement for JSON.

              1. 8

                a long article promoting JSON with less than a full sentence for S expression

                1. 4

                  What? It’s marked to-do. Here, I’ll just do it. Check the page again.

                2. 3

                  What about Dhall?

                  1. 2

                    You might consider including EDN, I think it makes some interesting choices.

                    Another point: the statement that JSON doesn’t support integers falls into a weird gray area. Technically it’s not specified what it supports (https://tools.ietf.org/html/rfc8259#section-6). If you’re assuming the data gets mangled by a JS system, you’re limited to integers representable by doubles, but that’s a danger point for any data format.

                    1. 1

                      I actually like this quite a bit, thanks!

                    2. 1
                      1. 7

                        Looks fine, but it’s binary and schema-defined, so it makes very different design tradeoffs than JSON does. It’s not an alternative to JSON, it’s an alternative to protobuf, cap’n proto or flatbuffers, or maybe CBOR or msgpack. There’s a plethora of basically-okay binary transfer formats these days, probably because they prevent people from arguing as much about syntax.

                        1. 4

                          I won’t go into details about where, but at work we have used stateless tokens for the longest time. For us, it’s been a terrible design decision and we’re finally moving off it. Why? Decryption is CPU bound, so it doesn’t scale nearly as well as memory lookups, which is what stateful tokens represent. Moreover a lot of our decryption libraries do not seem to be particularly consistent (high variance if we assume that the distribution is somewhat normal) in their timing. This poses a problem for optimizing the tail end of our latency. At small to medium scales stateless tokens are fine, but as we took on higher scale it just didn’t work. Memory lookups are fast, consistent, and scale well.

                        2. 1

                          You should post this as an article! A few comments:

                        3. 3

                          Anything but JSON.

                          Careful what you wish for…

                          1. 1

                            FreeBSD has had libXo for a while: https://wiki.freebsd.org/LibXo

                          2. 4

                            You can also legitimately give a file a name that starts with a dash, making it challenging to access or delete unless you know the trick.

                            1. 3

                              I remember reading a book on UNIX back in the day (1994? around then) which talked about this issue. The given solution in this professional tome was to cd up and then delete the whole directory.

                              (Asking how to handle this problem was also a common question in interviews back in the day, maybe still today I don’t know.)

                              1. 4

                                That’s… Wrong, at best. rm ./-rf always worked, even when the tool is buggy and doesn’t support -- argument parsing termination.

                                1. 3

                                  The man page for (GNU coreutils) rm now mentions both methods prominently. I believe you’ll get a prompt if you try it interactively in bash too.

                                  1. 6

                                    Yeah but kids these days don’t read man, they google, or at best, serverfault.

                                    </oldmanyellsatcloud>

                                    1. 14

                                      No wonder they google. Have you tried reading a man page without knowing Linux inside and out? They all pretty much suck. Take the tar man-page for example. It says it’s a “short description” of tar, while being over 1000 lines long, but it fails to include ANY examples of how to actually use the tool. There’s examples on how to use different option styles (traditional and short options), a loooong list of flags and what they do in excruciating detail, a list of “usages” that don’t explain what they do and what return values tar can give.

                                      I mean, imagine you need to unpack a tar.gz file, but you have never used tar before and you are somewhat new to Linux in general, but you have learned about the man command and heard you need to use tar to unzip a file (not a given really) so you dutifully write man tar in your terminal and start reading. The first line you are met with looks like this:

                                      tar {A|c|d|r|t|u|x}[GnSkUWOmpsMBiajJzZhPlRvwo] [ARG…]

                                      Great. This command has more flags than the UN headquarters. You look at it for a couple seconds and realise you have no idea what any of the switches mean, so you scroll a bit down:

                                      tar -c [-f ARCHIVE] [OPTIONS] [FILE…]

                                      Cool. This does something with an archive and a file (Wouldn’t it be helpful if it had a short description of what it does right there?). What it does is a mystery as it doesn’t say. You still have to scroll down to figure out what -c means. After scrolling for 100 lines you get to the part that lists out all the options and find -c. It means that it creates an archive. Cool. Not what we want, but now that we are here maybe we can find an option that tells us how to unpack an archive?

                                      -x, –extract, –get

                                      Sweet! We just found the most common usage at line 171! Now we scroll up to the top and find this usage example:

                                      tar -x [-f ARCHIVE] [OPTIONS] [MEMBER…]

                                      The fuck is a MEMBER? It’s in brackets, so maybe that means it’s optional? Let’s try it and see what happens. You write tar -x -f sample.tar.gz in your terminal, and hey presto! It works! Didn’t take us more than 10 minutes reading the man page and trying to understand what it means.

                                      Or, if you understand how to use modern tools like Google to figure out how to do things, you write the query “unzip tar.gz file linux” into Google and the information box at the top says this:

                                      For tar.gz. To unpack a tar.gz file, you can use the tar command from the shell. Here’s an example: tar -xzf rebol.tar.gz.

                                      You try it out, and what do you know? It works! Took us about 10 seconds.

                                      It’s no wonder that people search for solutions instead. The man files were obviously not written for user consumption (maybe for experienced sysadmins or Linux developers). In addition, this entire example assumes you know that tar can be used to extract files to begin with. If you don’t know that, then you are shit out of luck even before you open the man file. Google is your only option, and considering the experience of reading man files, no surprise people keep using Google instead of trying to read the “short description” that is the size of the fucking Silmarillion!

                                      /rant

                                      1. 4

                                        I don’t disagree with the general sentiment here, but I think you’ve found a man page that is unusually bad. Here’s some excerpts from some random ubuntu box.

                                         

                                        it fails to include ANY examples of how to actually use the tool.

                                        EXAMPLES
                                             Create archive.tar from files foo and bar.
                                                   tar -cf archive.tar foo bar
                                             List all files in archive.tar verbosely.
                                                   tar -tvf archive.tar
                                             Extract all files from archive.tar.
                                                   tar -xf archive.tar
                                        

                                         

                                        Cool. This does something with an archive and a file (Wouldn’t it be helpful if it had a short description of what it does right there?).

                                        Mine has, comfortably within the first screenful:

                                          -c, --create
                                                create a new archive
                                        

                                         

                                        Not what we want, but now that we are here maybe we can find an option that tells us how to unpack an archive?

                                        Something like 20 lines below that:

                                          -x, --extract, --get
                                                extract files from an archive
                                        

                                         

                                        Anyway, I don’t think man pages are intended to be good tutorials in the general case; they’re reference materials for people who already have an idea of what they’re doing. Presumably beginners were expected to learn the broad strokes through tutorials, lectures, introductory texts etc.

                                        I think that split is about right for people who are or aspire to be professional sysadmins, and likely anyone else who types shell commands on a daily basis—learning one’s tools in depth pays dividends, in my experience—but if it’s the wrong approach for other groups of people, well, different learning resources can coexist. There’s no need to bash one for not being the other.

                                        1. 2

                                          This is a GNU-ism, you’re supposed to read the Info book: https://www.gnu.org/software/tar/manual/tar.html

                                          But that also lacks a section detailing the most common invocations.

                                          OpenBSD does it better: https://man.openbsd.org/tar

                                          Of course, on the 2 Debian-based systems I have access to, info pages aren’t even installed… you just get the man page when you invoke info tar.

                                          1. 1

                                            I was just going to bring up info. I believe in many cases manpages for GNU tools are actually written by downstream distributors. For example Debian Policy says every binary should have a manpage, so packagers have to write them to comply with policy. Still more GNU manpages have notes somewhere in them that say “this manpage might be out of date cause we barely maintain it; check the info documentation.” Really irritating. Honestly I never learned how to use info because man is Good Enough™. I mean, come on. Why must GNU reinvent everything?

                              2. 1

                                I don’t think the author has to deny this, the difficulty of teaching doesn’t have to be the same as using. The difficulty in using, complicates the system, that then make it harder to teach – for example because of --json flags.

                              1. 3

                                Nice, but can it run fvwm95? I kid, and am glad that this wm is continuing to see development. What I would be interested in learning about is what the roadmap is for FVWM3.

                                1. 0

                                  “FvwmPrompt – a new module written in golang.

                                  That’s a radical change in direction, and an unfortunate one, considering they’re deprecating the c code this replaces.

                                  1. 3

                                    I think you’re reading too much into a very small change. The Developers doc doesn’t even mention golang:

                                    Programming Languages

                                    The following programming languages are allowed:

                                    • ANSI C
                                    • Perl
                                    • Portable /bin/sh scripts for examples.
                                    1. 2

                                      They sey

                                      ./configure --enable-golang needed at compile time

                                      So it’s not only is the module not compiled in by default, the support for go is off by default. I agree with the sibling; I wouldn’t read too much into this.

                                      1. 1

                                        Their plan is still to remove the c tool this replaces.

                                        1. 1

                                          I’m not intimately familiar with FVWM (I might have used 2, I’m not sure) but are Modules considered to be part of the core window manager? Or are they “nice to have” add-ons?

                                          1. 1

                                            These are modules that are built with fvwm. If this was e.g. a separate repository, there’d be no concern.

                                            1. 2

                                              Weirdly, I can’t find the source of FVWMPrompt in this directory

                                              https://github.com/fvwmorg/fvwm3/tree/master/modules/FvwmConsole

                                              Also this entry made me smile

                                              Changes - Renamed fvwm2 to fvwm almost everywhere (except file names). - 21 years ago

                                              1. 3

                                                21 years ago

                                                Nice find.

                                      2. 1

                                        Interesting take on something which is currently opt-in.

                                        No I am not deprecating C modules at all. What I am doing though is making it easier for modules to be written in any language without specific language bindings to a really bad API as we have now in the form of perllib in Fvwm.

                                        With FvwmMFL, this module spits out JSON down a socket to whichever module written in any language is listening on. Since it’s just data, you can use any language as long as it understands talking to unix domain sockets. This is what FvwmPrompt (written in Go) is illustrating.

                                        I do plan on increasing the amount of modules which are written in Go, in to Fvwm3, hence why I started with FvwmPrompt – but that’s just a preference, and is in no way indicative of any sort of C deprecation.

                                        Be careful, ethoh, in your thinking next time.

                                        – Thomas

                                        1. 1

                                          I do plan on increasing the amount of modules which are written in Go, in to Fvwm3, hence why I started with FvwmPrompt – but that’s just a preference, and is in no way indicative of any sort of C deprecation.

                                          What I said is that the module it replaces (which was written in C) is deprecated, which is accurate.

                                          Be careful, ethoh, in your thinking next time.

                                          My thinking was right, and your post does pretty much confirm what I already knew.

                                          If you think otherwise, feel free to reply and explain how my thinking was not right and/or elaborate on why you believe that I should be more careful in my thinking next time.

                                          1. 1

                                            Ah, right. I suppose you can view it like that. Yes, if you use --enabke-golang then this won’t build FvwmConsole so it is a replacement. That said, if you do nothing, then FvwmConsole still exists and can be used. I suppose the point I’m trying to make is that FvwmConsole isn’t going to be receiving any more love and attention, but I do plan on evolving FvwmPrompt in to something more, hence why I see it as a worthy successor, even now.

                                            As for separate repositories – it’s an interesting one. I could do this, and FvwmPrompt did start off like that in its own repository, but it does make users’ and package maintainers’ lives harder, as the functionality is then spread out all over the place.

                                            – Thomas