flux

joined 5 years ago
[–] [email protected] 4 points 11 months ago

I guess it's worth checking if those names point to the expected binaries, but I also think it would be highly unlikely they would be anything else than just /usr/bin/ssh and /usr/bin/ssh-agent.

[–] [email protected] 15 points 11 months ago (10 children)

As mentioned, -v (or -vv) helps to analyze the situation.

My theory is that you already have something providing ssh agent service, but that process is somehow stuck, and when ssh tries to connect it, it doesn't respond to the connect, or it accepts the connection but doesn't actually interact with ssh. Quite possibly ssh doesn't have a timeout for interacting with ssh-agent.

Using eval $(ssh-agent -s) starts a new ssh agent and replaces the environment variables in question with the new ones, therefore avoiding the use of the stuck process.

If this is the actual problem here, then before running the eval, echo $SSH_AUTH_SOCK would show the path of the existing ssh agent socket. If this is the case, then you can use lsof $SSH_AUTH_SOCK to see what that process is. Quite possibly it's provided by gnome-keyring-daemon if you're running Gnome. As to why that process would not be working I don't have ideas.

Another way to analyze the problem is strace -o logfile -f ssh .. and then check out what is at the end of the logfile. If the theory applies, then it would likely be a connect call for the ssh-agent.

[–] [email protected] 3 points 11 months ago

I think the main problem is that Chromium still contributes towards the browser engine monoculture, as it is bug-for-bug compatible with Chrome. Therefore if you switch to Chromium, it's still enough for the web sites to test for Chrome compatibility, which they will, because it has the largest market share. Users of competing browsers suffer, further driving the lure of Chrome (or Chromium).

On the other hand, if people switched to some other engine, one that does not share the same core engine or even the same history, this will no longer hold: web sites would need to be developed against the spec, or at least against all the browsers they might realistically expect their customers to use.

[–] [email protected] 4 points 1 year ago (2 children)

I highly doubt businesses would have been this fast in making the switch.

[–] [email protected] 4 points 1 year ago

Well that's exactly the worry. Why shouldn't it be? It is their business and livehood.

[–] [email protected] 3 points 1 year ago

As if taking down the systems is the biggest cybersecurity threat a company might have.

[–] [email protected] 10 points 1 year ago* (last edited 1 year ago)

Apparently Lapce has remote development as its core feature. But I only (re?)learned of it today..

How didn't tramp work out for you?

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

A great git integration can work well in an editor. I use Magit in Emacs, which is probably as full-featured Git-client as there can be. Granted, for operations such as cherry-picking or rebasing on top of a branch or git reset I most often use the command line (but Magit for interactive rebase).

But editor support for version management can give other benefits as well, for example visually showing which lines are different from the latest version, easy access to file history, easy access to line-based history data (blame), jumping to versions based on that data, etc.

As I understand it vscode support for Git is so basic that it's easy to understand why one would not see any benefits in it.

[–] [email protected] 2 points 1 year ago (1 children)

It still maintains their market position, which has value. For example, you might not visit other sites because they don't have the content you want (and the content stays on YT because they have the viewers), or you might even share YT links to other people.

[–] [email protected] 2 points 1 year ago (1 children)

Yes, just mount to /mnt/videos and symlink that as needed.

I guess there are some benefits in mounting directly to $HOME, though, such as find/fd work "as expected", and also permissions will be limited automatically per the $HOME permissions (but those can be adjusted manually).

For finding files I use plocate, though, so I wouldn't get that marginal benefit from mounting below $HOME.

[–] [email protected] 2 points 1 year ago (3 children)

My /home is also on a separate filesystem, so in principle I don't like to mounting data under there, because then I cannot unmount /home (e.g. for fsck purposes) unless I unmount also all the other filesystems there. I keep all my filesystems on LVM.

So I just mount to /mnt and use symlinks.

Exception: sshfs I often mount to home.

[–] [email protected] 5 points 1 year ago (2 children)

But how many use it for browsing, which I imagine this data is from?

view more: ‹ prev next ›