Hacker News Reader

My personal pet peeve is the confusing paste buffer(s). On macs it is always ⌘+C and ⌘+V. On linux it may be CTRL+INS and Shift+INS, CTRL+C and CTRL+V, mouse-select and middle-button click and so on.

Are there different paste buffers depending on how it's activated?

Mouse-select and middle-click might be a different buffer, but other than that it's Ctrl+X/C/V.

Only on terminal it's with SHIFT to avoid conflict the Ctrl+C that ends a command.

This is actually an X11 thing - it predates Linux. Instead of "the clipboard" X has multiple clipboard-like things. In X terminology they are called "selections". There's an arbitrary number of them, but there are only two selections that are used by most apps: the "primary" selection and the "clipboard" selection.

In most apps, the primary selection is populated merely by selecting something, while the clipboard selection is populated by some sort of explicit user action, like ctrl-C or a context menu.

The clipboard selection is pasted with some other explicit action. Usually it's analogous to the way you copy to it, like ctrl-V, or a context menu.

The primary selection is usually "pasted" with middle mouse button. Sometimes there's also a keyboard shortcut, and if there is it's often a modified form of the clipboard-selection's paste shortcut.

Most people get confused by the fact that there is more than one "clipboardy thing". They copy to one, and then paste from the other and winner why their copy didn't work.

The fact that there isn't a consistent action to get to each doesn't help. It is consistent if you stick to apps from the same "family" (eg: Gnome/gtk+ or KDE), except terminals never use ctrl key shortcuts. (Because control characters already mean something in terminals.)

The elementary Terminal allows Ctrl+V to paste and I find it very convenient.

Interesting. I kind of paused when I wrote "never" because it's of course possible for a terminal to bind control-keys to arbitrary actions, but every terminal I've ever used on *nix (including Mac and Linux) just passes control-keys through by default. It's possible that some of them allow such bindings as an option, but I've never checked because I need to be able to send literal control-C and control-V to applications I run in the terminal. (Control-C is of course "break", and control-V is used in vim a lot.)

This is one of the cases where I think the Mac approach happens to work out better than Linux (or Windows): by using ⌘ instead of control as the default shortcut modifier, there's no ambiguity about whether I'm talking to my terminal (copy, paste, spawn new window, etc.) or trying to send a control character. I don't know why the Linux community defacto-standardized on control keys rather than Super (or even Alt), given the high proportion of Linux users who are also terminal users.

Terminator does as well.

> Most people get confused by the fact that there is more than one "clipboardy thing". They copy to one, and then paste from the other and wine when the operation fail.

Let's not blame the (l)users. For example, by merely selecting the text you want to replace you may override the paste buffer content - this is a blatant POLA[1] violation.

[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

> Let's not blame the (l)users.

I don't think stating that "people get confused" is placing blame on one party or the other. That they get confused is a fact. I said nothing about whose fault that is.

> For example, by merely selecting the text you want to replace you may override the paste buffer content

It's a trade-off. Having the mere act of selecting text copy it to the primary selection is extremely convenient. There isn't any way to have that convenience without the downside that overwriting it is also easy. If you want to copy something and not have further selections overwrite it, you use the clipboard. This is like the trade-off of having a confirmation dialog or not.

I wouldn't say "this is a blatant POLA violation". What surprises one person might seem obvious to another. There is only one intuitive user interface, everything else is learned.

The confusion starts with the fact that people typically aren't told that the primary selection and the clipboard are two separate things (and by using the term "paste buffer" to ambiguously refer to one of them you're perpetuating this). Much of this misconception comes from the fact that more popular systems (Windows and Mac) only have the one clipboard, and people assume that whatever they learned first is universally true.

Not knowing about the primary selection actually isn't a problem on its own, though. After all, if one only knows about the clipboard operations, but doesn't ever trigger pasting from the primary selection, then the fact that the primary selection even exists would be invisible to them. The clipboard selection on X works pretty much the same as the clipboard on other systems.

The real problems start when people who believe there is only one "paste buffer" are then told, or discover, that they can "paste" using operations that actually paste from the primary selection rather than the clipboard. The worst part is that this doesn't fail outright, but instead seems to work, but inconsistently. Now they're confused, because there is no way to reconcile this behavior with their mental model that "this is another way to paste from the one and only clipboard".

https://github.com/diodon-dev/diodon he doesn't explain it very well, but you can see one of the options available is to keep the clipboards in sync http://i.imgur.com/7dOzNLq.png

I had a similar headphone crackle issue when setting up an XPS13 with Arch Linux.

There's a good guide here :

https://wiki.archlinux.org/index.php/Dell_XPS_13_(9350)#High...

Using alsamixer, I set 'Headphone Mic Boost Volume' to be 22. Then persisted the change with 'sudo alsactl store'.

I haven't experienced the other issues with Arch, though.

My greatest praise for Linux is that it's nearly impossible to completely brick the install - it's almost universally possible to recover it, no matter how broken it seems. You can potentially live-boot your XPS from a USB stick, chroot into your existing install and let the upgrade run to completion (Google around for some guides). 18.04 is a very slick OS - I'm running it at work on my company Precision laptop and it's fantastic. The '-d' flag is required until the 18.04.1 release, which is when the new LTS is considered stable enough for existing LTS users to upgrade.

This sounds very useful! I googled but didn't find much - perhaps I did not use the right terms. Can you please post some links that point me in the right direction?

Here:

https://help.ubuntu.com/community/LiveCdRecovery#Update_Fail...

Rather than Ctrl+Alt+F1 (which switches to a TTY), you can open a Terminal instead and run 'sudo -i' to get a root shell.

Replace 'sda1' with your root disk (you may have LVM enabled, and definitely if you have full disk encryption). If you don't have disk encryption, run 'pvscan' and see if it reports anything.

To get the update to finish, you can run 'dpkg --configure --all'.

@gargravarr Thanks so much!

> Headphones constantly crackle when they're plugged in. I've tried updating audio drivers, enabling/disabling various things, editing config files, etc. nothing fixes it. I've gotten used to listening to music with a crackle superimposed on top.

I thought Dell’s XPS series was supposed to have first class support on Linux? Did you try to contact Dell? I never had problem with sound on Linux even with some very cheap hardware.

Anyway, if you’re willing to do some tinkering yourself it might be as simple as adjusting some deep alsa settings.

E.g. this guy makes it look easy[1] :)

> I've also tried updating/changing/etc libinput and it doesn't do anything.

Does it use “precision” drivers on Windows? Sometimes trackpads implement their own gesture recognition and all kinds of other weird things. Check what you get with `xinput list` and try disabling anything that is not a pointer device.

> (it was on the latest 16.04)

Was it a new Dell? If you have new hardware and old kernel then forgot all of the above as that is obviously not a great combination. You absolutely need the latest kernel for the latest hardware.

> I did `do-release-upgrade -d` without realizing it was a dev version, then after a few minutes of reading I realized it was, so I cancelled it, and rebooted my computer.

Yeah sorry, Ubuntu doesn’t offer safe upgrades. I suggest if you don’t have much Linux experience (and even if you do) OpenSuse Leap/Tumbleweed which has full snapshot & rollback support[1], and since recently fully transactional upgrades as well.

[1] https://www.youtube.com/watch?v=a1YkPtfC4LI

[2] https://www.youtube.com/watch?v=GJgWvTLo07k

For the record, 18.04 isn't a dev version now, but 16.04 won't offer the update until 18.04.1 is released in a couple of months. That's a chance for early bugs to be ironed out before lots of LTS users upgrade.

> In an attempt to fix the above issues, I tried to update to Ubuntu 18.04

Upgrade are offered from LTS to LTS only once the x.x.1 has been released.

Your headphone crackle and screen flicker issues both sound like hardware problems. I've never experienced anything like that on any Linux machine I've ever used. I did have an old HP laptop (running Windows) where the screen hinge had damaged the video cable, and I'd get flicker unless it was opened just right.

See if it boots with a Ubuntu live USB. If it does you can install over the old version.