Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the clipboard works

whynothugo.nl

Post reply on HN
Print view View original

131–140 of 160 posts

Re: How the clipboard works

#131

Post by SeanLuke »

jeroenhd wrote: post #108
SeanLuke wrote: post #85

Earlier quoted context omitted.

> Elsewhere in these comments there is also a link to an explainer for the macOS equivalent. I know you didn't mean anything by this, but given that the entire concept of a clipboard was invented by the Mac/Lisa team (the Xerox Alto didn't have one), it seems wrong to describe it as an "equivalent" to Windows.

I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well. The Lisa was the first to name it the "clipboard" but that doesn't really count in my opinion. Also, modern macOS isn't based on the old mac operating system after switching to Unix, so even for Apple computers the macOS clipboard is an "equivalent" of the old clipbo…

> I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well.

Larry Tessler coined the terms "copy" and "paste" (basically just mark and yank) on early Xerox text editors. But AFAIK the Lisa group invented the Clipboard as a general storage mechanism for a variety of data types: and they certainly they coined the term. Here's a message from Bruce Horn, who is about as authoritative as it can get:

https://lisalist2.com/lisalist1/1796.html

> Also, modern macOS isn't based on the old mac operating system after switching to Unix, so even for Apple computers the macOS clipboard is an "equivalent" of the old clipboard.

Meh. The current MacOS clipboard is an amalgam of the NeXTSTEP pasteboard and the Carbon clipboard (derived from 9).

Re: How the clipboard works

#132

Post by [deleted] »

SeanLuke wrote: post #131
jeroenhd wrote: post #108

Earlier quoted context omitted.

I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well. The Lisa was the first to name it the "clipboard" but that doesn't really count in my opinion. Also, modern macOS isn't based on the old mac operating system after switching to Unix, so even for Apple computers the macOS clipboard is an "equivalent" of the old clipbo…

> I don't think it was the Apple Lisa that had the first clipboard. Xerox definitely had a clipboard and other experimental environments had them as well. Larry Tessler coined the terms "copy" and "paste" (basically just mark and yank) on early Xerox text editors. But AFAIK the Lisa group invented the Clipboard as a general storage mechanism for a variety of data types: and they certainly they coined the term. Here's…

[deleted]

Re: How the clipboard works

#133

Post by Beltalowda »

lotharcable wrote: post #115
the_mitsuhiko wrote: post #106

Earlier quoted context omitted.

Because go uses threads.

That is kinda insane thing to say. That is like trying to claim that you can't do threads in C++ because you can fork. Of course Go can fork processes.

As I understand it, the problem is that the Go scheduler uses threading to schedule the goroutines, and fork(2) says: "the child process is created with a single thread—the one that called fork()", so your fork then lose access to the scheduler.

Or something along those lines; it's been a while and this kind of stuff isn't really my expertise. I'm sure it's not literally impossible, but I wasn't able to get it to work in a reasonable amount of time so I just shrugged and exec'd xclip instead. The C++ runtime is tiny in comparison, and doesn't do anything like the Go scheduler. I think in general it's just not really considered much of a priority. Modern service managers don't really rely on processes to "daemonize" any more, which was always a bit hacky, and in my 8 years of Go this is the only time I ever wanted to do anything like this.

Go also had trouble with setuid() for the same reason (it would only get set for the current thread on Linux), although IIRC that's long since been fixed (this was around Go 1.5 or so).

Re: How the clipboard works

#134

Post by shmerl »

Is there any good solution for remote clipboard sync with Wayland session?

Use case is like this:

* A - local computer with Wayland session.

* B - remote computer with terminal neovim running.

I can ssh from A to B and use neovim with clipboard and with X forwarding in ssh that clipboard is synced to local session. But for that I need a terminal that runs in XWayland mode locally when doing ssh and working with remote neovim.

Is there a way to get the same result without X?

Re: How the clipboard works

#135

Post by lordgrenville »

Dwedit wrote: post #130
UI_at_80x24 wrote: post #117

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v ctrl + INS (copy) shift + INS (paste) IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick} This might even be a…

It's not a hardware interrupt at all, and needs to be specifically programmed into the text editor. It's just that that was the de-facto standard before Ctrl+C and Ctrl+V replaced it. Back then, Ctrl+C was the break key, so it wasn't usable. Even in Windows today, you can still use Ctrl+Insert/Shift+Insert/Shift+Delete in text edit or rich edit controls. Libreoffice even supports it.

Even today it's the only way to go in Git Bash which is pretty common on Windows dev machines.

Re: How the clipboard works

#136

Post by Vogtinator »

Beltalowda wrote: post #133
lotharcable wrote: post #115

Earlier quoted context omitted.

That is kinda insane thing to say. That is like trying to claim that you can't do threads in C++ because you can fork. Of course Go can fork processes.

As I understand it, the problem is that the Go scheduler uses threading to schedule the goroutines, and fork(2) says: "the child process is created with a single thread—the one that called fork()", so your fork then lose access to the scheduler. Or something along those lines; it's been a while and this kind of stuff isn't really my expertise. I'm sure it's not literally impossible , but I wasn't able to get it to wo…

Usually programs fork() before they do anything that requires threads. To have the program in the "foreground", just fork and wait for a kind of signal from the forked process and exit only when that arrives.

Re: How the clipboard works

#137

Post by 323 »

imiric wrote: post #125
323 wrote: post #84

Earlier quoted context omitted.

> which is accessible by any application that asks for it If you have malicious software running on your system, all bets are off. There are many ways it could steal your passwords, since desktop OSes don't sandbox apps like mobile OSes do. Just one example: you send the password securely to Chrome, but the malicious app just reads the login session cookie from the Chrome user profile files. Having a secure way of se…

> If you have malicious software running on your system, all bets are off. I think that's a common and lazy response to many security issues. There are _many_ ways in which a nefarious script or program can run in a "secure" environment and wreak havoc. Think NodeJS or Python scripts, which are typically downloaded from untrusted sources and ran blindly by most people as their own (hopefully) unpriviliged user. > The…

> isn't securing this one major IMO attack vector an improvement over not doing anything about it

Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants.

This is why even on mobile as you noticed, only browsers require user confirmation before allowing webpages access to the clipboard.

You could maybe do something in between, like not allowing clipboard access to processes which don't have a foreground window visible to the user.

But in practice, this attack vector is not exploited. If you are targeted, it's much more likely that a specific attack against the password manager is used, since it will extract ALL passwords, and not need to wait for one to show up in the clipboard:

> KeeFarce allows for the extraction of KeePass 2.x password database information from memory. The cleartext information, including usernames, passwords, notes and url's are dumped into a CSV file in %AppData%

https://github.com/denandz/KeeFarce

Re: How the clipboard works

#138

Post by the_mitsuhiko »

lotharcable wrote: post #115
the_mitsuhiko wrote: post #106

Earlier quoted context omitted.

Because go uses threads.

That is kinda insane thing to say. That is like trying to claim that you can't do threads in C++ because you can fork. Of course Go can fork processes.

> That is kinda insane thing to say. That is like trying to claim that you can't do threads in C++ because you can fork.

If you have more than one thread the only thing you are allowed to call after fork() are async safe functions and only the calling thread will make it into the forked process. Go uses a multi threaded runtime so the state of the runtime will be in an absolute mess in the child process. There generally is no sensible way in which an application can fork after a second thread has been created and how bad this gets, depends very much on the situation. But yes, the same problem applies in any programming language after multiple threads were created.

Re: How the clipboard works

#139

Post by the_mitsuhiko »

GaryPalmer wrote: post #127
the_mitsuhiko wrote: post #14

This design has the really annoying situation that applications closing down can't leave stuff in the clipboard. This results in a quite a frustrating behavior for users and also makes command line tools tricky. wl-clipboard lets you pipe text into the command to copy. The way it works is that it daemonizes in the background to fulfill the copy request. It either cancels on the first paste (command) or until some oth…

I don't get it (Windows user). If I copy some text in the browser and then close the browser the clipboard is gone under linux? How is that good design, wouldn't it be preferable if the OS is holding the clipboard data as a middle man?

It's horrible design. It's basically an omission of one of the most critical parts of how the Windows/macOS clipboard APIs actually function where data can optionally be frozen. For whatever reason the wayland folks thought they can get away without that functionality and from what I can tell (as user and developer) you can't.

Re: How the clipboard works

#140

Post by dfox »

lotharcable wrote: post #114
School-Cotton wrote: post #82

Earlier quoted context omitted.

> the applications/toolkits did not get it right until 00's They have still not gotten it right. I still sometimes experience the clipboard losing things on modern Ubuntu.

X11's model for 'cut buffers', 'primary', and 'clipboard' is a historically bad design. Like very easily in the top 10 worst designs in computer science history. The fact that it managed to work at all is a testament to the millions of man-hours people were willing to pour into polishing a turd to make Linux Desktop a reality. If we had the ability to go back in a time machine and do it again it is now painfully obvi…

Cut buffers are different thing than selections and cut buffers are deprecated and probably not used by anything written in last 25-30 years.

On the other hand cut buffers are so simple that there isn't any of the complexity as with selections. But still I think that the ICCCM/Wayland model of selections is the only sane way how to implement clipboard, because it does not involve creating some kind of shared state of potentially unbounded size and consuming potentially unbounded CPU time doing that even if it will not be used.

Post reply on HN