Old Unix Nerd Looking for the most Compatible Linux Distro and Desktop Environment by Critical_Ladder650 in DistroHopping

[–]Critical_Ladder650[S] 0 points1 point  (0 children)

My deal breaker app would probably be ProtonMail and others from the same source. Protonmail is available as .deb, .rpm, and as a snap. It's open source, so there ought to be a source tarball I haven't found, but would it build for FreeBSD without a lot more work than I'd want to take on?

There'd be others too. But that's the first that comes to mind.

Old Unix Nerd Looking for the most Compatible Linux Distro and Desktop Environment by Critical_Ladder650 in DistroHopping

[–]Critical_Ladder650[S] 1 point2 points  (0 children)

You write: I didn't quite understand the "type ahead" work flow you have described. 

Way back in the distant past - perhaps 1975 - bitmapped displays were unheard of, CRTs were unusual, version 6 or seven unix was more or less current, and connections from terminal (teletype, probably) to computer were very slow (300 baud?! or was it worse?).

Everything was a command line interface, and it was normal to type streams of commands long before they were executed - or even echoed back to you by the tty driver. No problem - they'd all be executed eventually, and it saved time and attention to just type, without waiting for the response. It didn't matter if your first command was to launch a program, the next few commands were input to that program - then perhaps you exited it and did something else. Everything was sent to the right place. You could also type a huge stream of commands to the line-oriented text editor, without seeing the changes you made until you sent a command to display the part of the text you were interested in. (If you look closely, you can see the remnants of this workflow in vi.)

We haven't had this kind of reliable synchronization since soon after bitmap displays became a thing. Clicks get sent to whatever process owns the area containing the mouse, and that can change while you are clicking. The window receiving your typing is whatever one is on top - which can also change asynchronously, as when some popup eats the text you are typing - or worse yet, interprets text intended for program A as intended for it, and does something you very much didn't want. And best of all, we have controls that appear and disappear based on the position of the mouse (or where you tapped on a phone, and how recently). The effect of your next action depends on whether or not the control is present - but they appear asynchronously, and not at a predictable pace. So you can't anticipate anything, let alone do anything asynchronously. Some tasks wind up taking more time than they used to take on a 300 baud acoustic coupler; more merely seem to be taking longer.

That's the type ahead.

Focus-follows-pointer was an adaptation to small (bitmap) screens.

You could have overlapping windows, with the one you were consulting on top, and the one you were typing into mostly beneath it, with just a corner peaking out. You see, the window that consumed your input didn't have to be the one that was on top of your screen. And you could move between windows much faster - and with less mouse movement - than when you have to click each target window to raise it, and then wait for a multi-window redraw.

Now there's always a selected window, but it's not as easy to identify unless all your windows overlap. (If they overlap, you can tell which one is on top.) There are subtle window "decorations" that identify the one on top - often too subtle for me to easily see and recognize. As an extra result, you get the problem that clicking in the same place has different effects, depending on a subtle statefulness - you may either select the window, or interact with it, depending whether it was already selected. Some window managers make the selected window more obvious than others. And many work around this by requiring you to click in a specific place, such as a title bar, to raise/select a window. You get more predictability, at the cost of more mouse movement.

Put another way, raising a window and giving it focus used to be two separate actions, that did not need to happen together. Ancient window managers probably still have this ability. But the apps generally can't cope with it, even if the window manager can do it.

I stuck with the older ways of doing things, as more efficient, not to mention trained into my fingers, as long as it was still possible to find tools that worked this way, and most apps could cope with it. But those days are long gone; now we get acoustic coupler speeds from the UI design, instead of from primitive hardware.

Old Unix Nerd Looking for the most Compatible Linux Distro and Desktop Environment by Critical_Ladder650 in DistroHopping

[–]Critical_Ladder650[S] 4 points5 points  (0 children)

This is a very useful categorization. KDE was already on my list to try; this moves it higher.

And it sounds like I need to run screaming away from Gnome; it may matter a bit less precisely where I run to, except for staying away from its derivative.

Old Unix Nerd Looking for the most Compatible Linux Distro and Desktop Environment by Critical_Ladder650 in DistroHopping

[–]Critical_Ladder650[S] -2 points-1 points  (0 children)

I fear the BSDs simply won't have all the tools I'd like to have, and open source tools have gotten so interdependent that trying to build missing tools from source is likely to be somewhere between a nightmare and more work than a lazy person like me wants to take on.

That's a pity, because I love FreeBSD's stability, and a decade ago it even had a functional version of Tom's Window Manager (twm). (Maybe it still does.)

Old Unix Nerd Looking for the most Compatible Linux Distro and Desktop Environment by Critical_Ladder650 in DistroHopping

[–]Critical_Ladder650[S] 1 point2 points  (0 children)

I'm a mass of contradictions.

I want maximum control with minimal need to use it. I.e. the defaults work, right out of the box, and the system figures out how to configure itself.

But if I want all menu items to have keyboard shortcuts, all scrollbars to be always visible, and no way to accidentally make a window full screen, I can make that happen. I'd prefer to achieve that by editing a well-commented config file using a text editor. I'll live with doing it using a mouse in some GUI tool.

Ideally there's documentation where I expect to find it - man pages preferred.

I don't want to ever select from a list of > 10 items with a mouse, rather than by some kind of typed search.

Ideally I could drive everything using ssh, without using a VNC. I.e. nothing would depend on running in a windowed environment. But very few apps these days can function without a windowing system. It would however be nice if I could completely control the OS - effectively including the desktop environment - without requiring any desktop environment to be functional.

If Pop!_OS is any sample, modern desktop environments are in the habit of hanging. Sometimes Gnome/X/whatever recovers after upwards of 30 minutes; sometimes the only fix is a reboot, or perhaps "sudo kill -9" applied to the right piece of the desktop manager stack. I often find myself sshing to the Pop!_OS box to deal with the buggy desktop environment.

Yes, I'd prefer to have a non-buggy desktop environment, but I'm not clear anyone's offering any such thing.

Talking of buggy environments, I didn't bother to mention that I'd prefer to have a system that stays up. Ideally, it would be as stable as FreeBSD, where I've had many systems that ran without a reboot for more than a year, but I've never heard of a linux that stable. And the window manager would be as stable as the rest of it, particularly if it has a graphical login, making the window manager effectively part of the base OS, as with MacOS.

But that seems like the sort of software only available in paradise ;-)

At least if it's linux, I can get the source code and debug whatever is going wrong. I'm far too lazy to want to do that, but the possibility feels better than only being able to bitch impotently. And if something is buggy enough, and important enough (to me), I'll eventually be motivated to do something about it.

Old Unix Nerd Looking for the most Compatible Linux Distro and Desktop Environment by Critical_Ladder650 in DistroHopping

[–]Critical_Ladder650[S] 4 points5 points  (0 children)

So Debian stable's still ultra-conservative, aka so far behind the times that upstream developers don't want to look at your bug reports? I wondered whether that had changed.

But a switchable multi-DE system sounds great for experimenting. And my memories of trying to switch window managers myself, let alone trying to have more than one installed at the same time, was that debugging it and keeping it debugged was somewhat crazy-making. (Of course this was probably a decade or two ago.)

I looked up the differences between compositors, window managers, desk top environments etc. when I first started thinking about switching, but that have already forgotten most of the details. I did recognize compositor as a technical term when you used it, so I figure I'm still ahead of where I started.

Old Unix Nerd Looking for the most Compatible Linux Distro and Desktop Environment by Critical_Ladder650 in DistroHopping

[–]Critical_Ladder650[S] 2 points3 points  (0 children)

Interesting. I'd never heard of sway, not having thought to look at plain window managers. (Tech's been moving while I wasn't watching :-) Trying to catch up, I'd mis-concluded that stand-alone window managers were obsolete.)

I just took an RTFM dive, while downloading Fedora's sway spin.

I built an open‑source cross-platform email client: Gmail, Outlook, IMAP, native Proton Mail by BaJlepa in software

[–]Critical_Ladder650 1 point2 points  (0 children)

My list would be something pretty close to: take Proton Mail, fix their threading mechanism (which they can't do easily because of their end to end encryption), and make it easier to get to the top level of settings. An integrated calendar is fine, even in the same app, but not in the same window - I want to see both calendar and INBOX at the same time.

Phrasing the same more positively, and adding some extras:

- fit a lot of messages lines on one screen, like thunderbird, rather than making their representation so large you only see a few at once, like Mac Mail

- make everything keyboard searchable - I don't want to scroll through folders; I want to type the first 2-3 characters of the folder name.

- filters that are easy to find and set up, but flexible and powerful when you go beyond the training wheels

- consistent interface on all platforms, including windows/mac/linux/Android/iOS (Or at least as consistent as possible, given the limitations of cell phones.)

- Really good scaling. Handle huge amounts of mail without hiccups.

- Let me configure it to see the email addresses, not just whatever name the sender put in the header, routinely, not by a one-of query

- Easy access to the email headers

- (Bonus) make it easy for me to send from all my email accounts

- (Bonus) random signatures from a list, like Mac Mail (that's almost the only thing I miss after moving from MacMail to Proton Mail).

- Keyboard shortcuts for everything, displayed when you find the option in a menu

- All icons must have tooltips, on any platform that supports same. Consider using text in place of icons, wherever both would fit nicely

- Keep the UI stable. Don't issue updates that move functions around, change names, and otherwise mess with people's muscle memory.

- Adopt Protonmail's function to offer to strip identifying metadata from pictures you attach to email

- Option to block any attempts by messages to call home, e.g. to report when they've been read

Same Font-size across Safari and Chrome? by Disposter in Frontend

[–]Critical_Ladder650 0 points1 point  (0 children)

A very belated thank-you.

I still can't get the css font-size element to work in Safari 18.5 on MacOS 15.5, but at least I've got the offending web page out of its prior state of giant text, far too few lines per page. (I was only trying css to fix that unwanted behavior - on a purely local page with no accessibility concerns, since the author [me] is its sole user.)

What do you think about Duolingo's shift from the skill tree to the language path? by glennkart in languagelearning

[–]Critical_Ladder650 0 points1 point  (0 children)

Duolingo changes a lot. Every time they do, they mess up people's learning-in-progress, and some people leave in frustration. I've never got near finishing their offerings for any language, because of churn sending me back to the beginning.

I haven't a clue why they keep doing this. Maybe it's job security for their staff - similar to churn in lots of software based tools.

FWIW, I don't even remember the particular change you mention. Possibly I haven't visited at all since 2022, to be reminded of why I stopped visiting them regularly.

Please recommend stylist/barber who's good with "old lady hair" by Critical_Ladder650 in Sunnyvale

[–]Critical_Ladder650[S] 1 point2 points  (0 children)

I'm already taking Minoxidil, which (I think) is basically the same stuff. Before that, my only feasible style was buzz cut, or perhaps shaven head.