That reminds me about that one day in at Sun back in the late 90's when I compiled Solaris in debug mode and set up KGDB.

I was running a full Solaris kernel while anothe rmachine was running GDB and DDD. I was able to visualise all the kernel structures in realtime. It was significantly more usable that I would have imagined it to be.

Can you do something similar these days with Linux?

You could, but eBPF might be a more sensible way to get the same information: http://www.brendangregg.com/ebpf.html

That's comparable to DTrace. The Solaris kernel debugger, kmdb, is something else, and really worth knowing (if only it was universally adopted by C-coded kernels!).

With kmdb you get to write shell-like pipelines using powerful data structure traversal builtins, and it is safe (you can't crash the system by dereferencing NULL pointers). Really, it's quite fantastic.

curious - the Sun developers I saw in the late 90s had a multi-window debugger but the local variables Did Not Update, and had to be 'refreshed' manually; at the same time, I had MetrwoWerks IDE Debugger on a Macintosh, and easily had all locals, source code, stack, RAM inspection by structure and more, all updating with every change. The Sun devs were being PAID a LOT more, yet their tools looked primitive and the contextual knowledge to use them was much greater..

I'm not sure. I wasn't working as a kernel developer. I did have to debug stuff though to find bugs or explain certain behaviours.

I guess one reason it wasn't used much is because it was a hassle to set up, and I think it got a bit slow when you had a lot of information displayed. I do recall not using this setup much in practice, as just breaking into the debugger on the machine itself was faster and easier.

You had to lot of options when it came to working on the Solaris kernel, and the code was so easy to understand. In fact, I believe the Solaris code base is the best C code I've ever worked with. It's a pity what happened after Oracle took over.

Exactly my kind of experience learning UNIX, while coming from Amiga/PC/Mac IDE world, back in those days.

Yeah, kgdb has been mainlined for a while.

In Windows land, windbg has supported this setup for forevers too.

Of course.

I love the ability of ddd to plot 1d and 2d arrays in gnuplot, while you debug, updating the plot after each next instruction. Really handy for numerical codes. I have not found yet another tool with the same functionality. The python calls from gdb allows to do something similar but does not update automatically and you have to use much more code

Or to go more into the past, a modern day Zortech C++ debugger.

I still make use of DDD, one of the debuggers that made my UNIX development experience more enjoyable (vs PC/Mac tooling).

What prevents you from using DDD on a PC or Mac though? You may need to install an X server, but you should still be able to run it.

My point was that UNIX tooling did not match PC and Mac IDE based tooling and DDD helped to make it less painful.

Nowadays I focus on Apple, Microsoft, Oracle and Google platforms and languages, so DDD isn't something I miss.

What I don't understand with this "modernity" is these "black background shimmery text" themes.

Because that's what we had in bad old days before the monitors were able to show pixels -- the text consoles could actually show only text and the technology used was too poor to have nice pale background and black letters.

But why would somebody want this on the modern displays, except because he does that instead of properly adjusting the background light or because "the real cool guys look at black screens" is beyond me. Seriously, the displays aren't cheap eighties displays anymore. And even then the expensive ones already looked much better by default than these "modern" themes now.

/end of the old guy's lawn rant

Otherwise, I definitely like every debugging tool that tries to have a good GUI.

> What I don't understand with this "modernity" is these "black background shimmery text" themes.

Because we're mostly using emissive displays, and it turns out that trying to imitate what works on paper on an emissive display sucks for long term use (though it looks pretty at a glance, and if you are composing things for print WYSIWYG may be more important than what is most comfortable on the screen.) We tried light themes as the almost invariable rule for the first several decades of GUIs, but recently got over it.

(Light backgrounds are awesome on reflective media, and if eInk was cheap and fast enough to use for primary monitors for coding we’d do that.)

You are really just talking about your preferences as if they are scientific absolutes. It depends on your eyes including the amount of floaters you have and how imperfect the lens of your eye is away from its centre, the lighting conditions of your room, your monitor, your taste.

I am not sure exactly when the recent trend towards dark editor themes started but I wonder if it was around the same time that WLED LCD backlighting took over? I love white themes on my CFL monitor but not so much on my WLED laptop.

I also think maybe many people started preferring dark colour schemes because colours pop and look more saturated against black, and so it looks better in screenshots etc.

> You are really just talking about your preferences as if they are scientific absolutes.

No, I'm talking about what's true of the population as a whole (but not every individual member) as if it was the driver of the trend the poster I was responding to questioned...because it is.

Light themes are better than dark themes from an eye strain perspective if a room is well lit. On the other hand, dark themes are better in low light conditions, so if you like coding in dark rooms dark themes are essential. Dark themes are also good for photo editing where you don’t want chrome saturating content.

> light themes are better than dark themes from an eye strain perspective if a room is well lit.

IIRC, the issue is legibility more than eyestrain (though they are related) and light themes are still better with normal vision, but a majority of the adult population has one or more of the vision issues that reverse this (astigmatism being the main one, and alone accounting for nearly 50%.)

> Because we're mostly using emissive displays, and it turns out that trying to imitate what works on paper on an emissive display sucks for long term use

I claim it’s not true. If one would measure The light flux of my screen I’m sure it wouldn’t be higher than that of the paper when reading in good light conditions. I claim that it’s dependent of how one configures his display.

Emitting light != reflecting light.

I used to battle too against "dark modes". But I was forced to use VSCode for one project (since a couple of months), and I have to say that I became so used to it that now I want to use "dark mode" everywhere I can. Unfortunately IDEs for embedded like KEIL uVision will never get such feature, and now it's a pain to go back to white background.

> Emitting light != reflecting light.

No. It's photons, and the photons count is the same for a given flux. If your screen emits more photons, it's because you've set the background light too high. That's that user configurable setting I've mentioned in the first post. If you have problems with reflection of some other light source and you solved it by turning it off and sitting in the dark room, you of course have to reduce the background light of your monitor to match the ambient light conditions.

Light is light, I know. But reading from e-ink is not as comfortable as reading from an LCD whatever the brightness setting is. There are many reasons, like refresh frequency, angle, etc. I'm sorry I don't have time now, but you can look it up.

"I don’t like this so nobody else should" is always obnoxious to read.

I like dark mode. If it has options to let you have dark-text-on-bright-backgrounds, why does the option for a dark mode bother you?

Tech should cater to different needs. Nobody should have to defend their preferences against anyone, but for those wondering if there are any objective reasons:

I don’t want intense light constantly blasting my eyes, taking up more energy and reducing the display’s effective lifetime, and I want to be able to work comfortably in dark environments, which may be dark for any reason: Not wanting to wake other people up, or bother anyone in theaters/restaurants/cars/planes/etc. or simply reducing energy usage.

Unless you are using an OLED, a dark theme is not more energy efficient than a light one.

I don't think this is true: many transmissive LCD technologies adjust their backlight brightness, including differently across regions, depending on the displayed image?

OLEDs incorporate the backlight with the pixel, so they can turn on or off the light for each pixel, giving you much nicer blacks. A typical LED backlight is just a single uniform light, so it can only be adjusted for the entire screen, and unless your screen is black, you need some light. I guess if everything was a at most a darker grey, they could crank it down, but I don’t think anyone does that?

I'm not sure about typical, but I believe most high-end LED backlit displays use at least one of global or local dimming of the backlight depending on what's on the screen.

This means that the power use of this type of LED backlit display is also sensitive to what is being displayed (but at a coarser resolution to OLED).

That “quote” of what I wrote:

> > I don’t like this so nobody else should. > Is always obnoxious.

Is completely fake.

Readers beware.

It's not "completely fake", it's how your rant reads to a lot of readers - whether you intended it or not. @Razengan was giving you a hand here, helping you understand why that rant is disliked.

I have tried to use a lighter background because apparently "that's the correct thing". After experiencing significant eye fatigue I switched back to dark blue.

Basically that is how I feel when I see HD colour screens being used to organize XTerms, similar to the IBM XWindows terminals I got to use in 1994.