ajarmst · HackerTrans

il y a 5 ansdiscuss

A couple of decades ago, I spent a few years teaching an introduction to network programming using C on an embedded board running uCLinux for Network Engineering students. While my primary text was Stevens, Beej's guides were an invaluable secondary reference for my students. There were many, many occasions where students who were were having difficulty understanding my explanations could recover using Beej's approachable, application-oriented notes. Eventually, I found myself frequently abandoning my own notes and just lecturing from Beej's work. I miss the days when I still worked with students that close to the metal, helping them build their own network devices. Thanks for the reminder of a time I still have fond memories of.

ajarmst

il y a 6 ansdiscuss

That's possibly fair---I am by nature sometimes overly brusque. But I will say that debugging on Linux is hardly a neophyte's realm. Even properly using the debugger in purposefully less obtuse interfaces like Visual Studio is non-trivial and generally requires the assistance of walkthroughs, manuals, and colleagues/instructors.

ajarmst

il y a 6 ansdiscuss

"The State of Linux Debuggers". This is ... not that. Perhaps "One inexperienced user on an uncustomized system briefly trying several default-configuration front-ends (some of which are apparently malconfigured or missing dependencies) to GDB, without resorting to any documentation whatsoever, and gauging them solely on layout and visual appeal."

Pro-tip. When working with a new debugging environment "I haven't found a way to display the backtrace, list local variables or view memory" would be where most would look at documentation or seek advice, not move on to the next tool. That the author didn't is more of a comment on the reviewer than the product.

ajarmst

il y a 6 ansdiscuss

And, of course, ed is the default editor. :-) I exert geek dominance over introduction to C students by demoing using ed to modify a source file. After which I amuse myself for the remainder of the term: "Source Control? Syntax highlighting? Luxury! When I was young we had to hand-magnetize knitting needles and edit files one bit at a time directly on a Winchester drive!"

More seriously, I think the 80 column width is just too constraining with more modern languages that aren't remotely as terse as C–not to mention a limit that aggressively militates against in-line commenting. We also have monitors and fonts with resolutions that permit easily reading much denser use of the visual display. I mostly go with 120 chars now (in practice, that means that lines still won't wrap when I print source code files) and however many lines fit into the display pane.

ajarmst

il y a 6 ansdiscuss

Yeah, I see it. I just don't get it. There's an awful lot of UX work being done to preserve an illusion that you have a bunch of fixed-size consoles that are arbitrarily arranged in a 2d space. Which, I guess, is the defining metaphor of GUI interfaces, but if that's what is desired, why create a console-only (if only in appearance) GUI? Text buffers in emacs or panes in screen or tmux can be made to have arbitrary size and dimension if you want to turn off wrapping and keep a longish scrollback. You can have as many buffers as you want, as many as your screen can accomodate visible at once and easily navigate them as you like. All you have to give up is the conceit that windows have independent physical size and location and embrace one that holds that you can have an arbitrary number of text buffers available to arrange, swap, hide, show, etc. Not trying to be nasty, but this feels like a bit of a cargo cult: someone stuck in the windows GUI metaphor trying to create a version of CLI metaphor they don't fully grasp. Of course, the fact that those of us who prefer the CLI metaphor are rapidly dying off is relevant here---but seizing all of the disadvantages of an all-text environment without any of the advantages seems ill-advised. That said, no one needs my approval. If this works for you (and I'll readily admit it's kind of cool), what do you care that I don't get it.

ajarmst

il y a 6 ansdiscuss

Same as any other WM (although I don't actually use exwm). Enable ssh for troubleshooting or use boot flags to boot to console.

ajarmst

il y a 6 ansdiscuss

Stumpwm would probably be attractive as well, because Lisp. http://stumpwm.github.io/

ajarmst

il y a 6 ansdiscuss

Agreed. But using an entire character-width for that purpose is extravagant in this example (use of background colour would be better. Right now, some of those windows are !0% border). In a larger area, you can use unicode or even the drawing characters in MS 8-bit ASCII for a single-pixel hairline plus padding for both windows' text). I guess my take is that this is sacrificing an awful lot of real-estate to simulate overlapping windows, which is a feature of dubious utility in a pure text environment. "Users expect them" is probably the most common and egregious excuse for bad UX design, but I do understand why.

ajarmst

il y a 6 ansdiscuss

The width of the display used in the screenshot appears to be less than 150 characters. Why would you add the clutter and distraction of transparent windows with frame decorations in such a limited environment? 30% of the real estate is consumed by elements that don't present any information to the user.

On a modern display, this could far more productively be replaced with (1) any number of tiling WMs with console terminals in the panes (I use stumpwm for this), or---and you don't even need a GUI/WM for these---tmux or screen, or even emacs -nw, which give you a much more configurable and robust text-only environment. My normal working environment is a pretty heavily customized tmux (including powerline and full 256-color/unicode support) running on a machine that doesn't even have a GUI installed. (I do cheat a bit by using kmscon---or fbcon in the past---to get colour and font support on linux vttys.).

comments