The ThinkPad T480 Successor: New ThinkPad T14 Gen 5
notebookcheck.net
notebookcheck.net
Now checking to see if it can ship w/ Linux by default.
edit: The answer appears to be "no." Also, searching Lenovo.com for "T14 gen 5" yields: "2676 Result For ‘t14 gen 5.'" Lenovo should really work on their search functionality.
It was bound to have an effect in the industry, as tech-savvy people select and recommend them simply because they're the least broken option.
Others are too disposable; made to break rather than last.
In any case, I would bet they are outnumbered by fruity laptops.
Probably a case of "the thin edge of the wedge".
So in a few years time if/when Framework is more established, they might be an option for IT departments.
"Hacker conferences" dosent matter in the real world, sorry
For laptops, try T430: it can last for decades.
Then they can still decide later if they themselves want to cell it with Linux late on.
I think currently they are down to just the Carbon X1 being orderable with Linux which likely speaks to the actual demand for Linux vs their cost to support it.
I don't want to risk "Linux support" that comes from the vendor tasking some interns to hack drivers into one specific distribution and/or kernel version.
I want a machine where I know I can wipe or replace the SSD and boot my preferred standard Linux install media to get a fully functional system. I want zero vendor-supplied drivers or other add-ons.
Luckily, Thinkpads have been popular enough that I can always read about someone else's experimental validation of new models before I bother to order one myself.
Is it? Isn't it like 1/1000th their sales, one being a global brand and everything, the other a niche product?
The annoying thing about soldered RAM on Thinkpads is that it can't be disabled.
So if the onboard RAM dies so does your laptop. Even if the laptop has a SODIMM slot.
> The new ThinkPad T14 Gen 5 has a redesigned keyboard with swapped FN/Ctrl keys
Having the Fn on the left appears to be quite an emotional subject for some people.
* I am joking.
The copilot key seems to replace the menu or prtscr key between the alt and ctrl on the right.
TBH it's weird to hear this so often. Macs also have the same "Fn on the far left" layout as ThinkPads and Macs/ThinkPads have basically won in the tech space. I got a Dell work laptop and I thought this wouldn't be a big deal, but having used a ThinkPad or a Mac for 20 years I couldn't adjust (which is wild, because I got over Neovim's D/dd abominable betrayal in a few days).
But on a PC far left key is easier to press with a palm than the much less useful fn, so it's a welcome improvement in the default layout
It's subjective.
> palm
Did you mean to say you're pressing a button with your palm?
> Unless you rebind it to make your experience 100% consistent
If we're saying rebinding is an acceptable solution then what does it matter what order the keys are in?
You also can't really rebind the Fn/Ctrl/Option/Cmd to do what you're suggesting in macOS. I learned this using a ThinkPad USB keyboard on a Mac trying to get it to use Ctrl for the things you're used to on a non-Mac keyboard: there are a lot of clashes. For instance if you map Cmd-C -> Ctrl-C how do you copy things (or cancel things) in a terminal? I ended up binding the ThinkPad's keys to be what they would be on the Mac's keyboard.
The amount of rebinding still differs due to Alt, defaults unfortunately matter even if you change them.
> if you map Cmd-C -> Ctrl-C how do you copy things
How do you do it on Windows where it's the same combo from the start?
But also: by making it conditional on selection or simply using another letter
1. Me: Macs also have the same "Fn on the far left" layout as ThinkPads and Macs/ThinkPads have basically won in the tech space.
2. You: Macs have a better design here - they use the more convenient thumb for Ctrl functions, so fn on the far left is not relevant
3. Me: Nah in the terminal where I spend 90% of my time Ctrl is Ctrl.
4. You: Unless you rebind it to make your experience 100% consistent
5. Me: If we're saying rebinding is an acceptable solution then what does it matter what order the keys are in?
6. You: The amount of rebinding still differs due to Alt, defaults unfortunately matter even if you change them.
Like, sure I guess rebinding 4 keys is more work than rebinding 3. I was just confused (5) because you said that the Mac's design is better (2) but then you seemed to abandon that argument by saying you can just rebind keys (4). Your response at (6) seems irrelevant; why is Alt (a key not on the Mac keyboard; do you mean Option?) germane?
> How do you do it on Windows where it's the same combo from the start?
Pretty much the same way the Mac does it [0]: let Ctrl-C mean "cancel" and use some other key combo for copy (you guessed it).
But, again overall rebinding is an imperfect solution. A lot of things don't know you rebound your keys, there can be weird clashes, etc.
[0]: https://learn.microsoft.com/en-us/windows/console/ctrl-c-and...
It is a literal (as in both printed on the key and referenced in the OS/docs) key on a Mac keyboard with, you're just confused by the fact it also has another name.
> A lot of things don't know you rebound your keys, there can be weird clashes, etc
Like what? If you just move 4 keys all the things will know, that's a system-wide rebinding. And what clashes do you mean? You've only provided a single example Ctrl-C example, which turns out to be easy to resolve in either the same way it's resolved in Windows. Or in a better way
But also, if you recognize there are many clashes that need to be resolved via rebinding, then this "rebinding 4 keys is more work than rebinding 3." doesn't make sense, guess that's why you're confused again. Alt is germane precisely because rebinding 4 keys isn't enough since default keybinds work differently with these modifiers.
1. On a Mac Cmd key is already used by the OS for most of control functions, so it's easy to rebind the few terminal Ctrl keys to Cmd without moving those 4 keys around, and resolve only those direct clashes
2. But on a PC Alt is used for some common operations, so if you move Ctrl to the more convenient thumb location, you'll have to deal with moving some of those keybinds, so resolve clashes that potentially touch more apps/keybinds than just terminal keybinds
I feel like we're in a weird place in this discussion. AFAICT no keyboard Apple currently ships labels Option as Alt, though it is true they have shipped keyboards with this in the past. There's no need to condescend, or maybe you were just referring to PC keyboards and trying to bail yourself out here?
> Like what? If you just move 4 keys all the things will know, that's a system-wide rebinding.
Web apps don't know. Swap Control/Option and load up Google Docs. The binds they list don't take into account the swap, though the new binds work correctly. Also in iTerm2 Pointer settings the Cmd/Control/Option icons don't update. Etc. etc. etc.
> You've only provided a single example Ctrl-C example
My point is that it's always gonna be a little imperfect and maybe a lot of work. Let's say you did want to basically make iTerm2 function like xterm in Linux; what that means is Ctrl-C is cancel and copy/paste is done w/ the mouse. Well, you can't get rid of Command-C for copy, and you can't get the "copy on select" behavior either, so that's a bust. Let's abandon a Linux-alike and just add an App Shortcut for ^C -> Copy. Some terminals are smart enough to use Copy when something's selected and use Cancel otherwise, but Vim's isn't :(. Also if you have anything bound to Ctrl-C in those apps you lose the app's bind, and you don't always have a way to get it back. Pasting is another problem: if you bind ^V -> Paste, any terminal app that uses ^V as a keybinding (Vim again) will instead get whatever's in your clipboard.
> But also, if you recognize there are many clashes that need to be resolved via rebinding, then this "rebinding 4 keys is more work than rebinding 3." doesn't make sense, guess that's why you're confused again. Alt is germane precisely because rebinding 4 keys isn't enough since default keybinds work differently with these modifiers.
> it's easy to rebind the few terminal Ctrl keys to Cmd without moving those 4 keys around, and resolve only those direct clashes
You can't have it both ways. Either rebinding is easy or there are many clashes.
> But on a PC Alt is used for some common operations, so if you move Ctrl to the more convenient thumb location, you'll have to deal with moving some of those keybinds, so resolve clashes that potentially touch more apps/keybinds than just terminal keybinds
Great, the Alt you were talking about is for PC keyboards. That's what I thought; dunno why we had to go deep into like, API docs for macOS. Sometimes people goof! That's OK! Now I see what you meant here. Yeah but like, welcome to more rebinds across more apps.
---
AFAIK people use Karabiner to pretty good success here. I've never tried it. Maybe it makes everything easier, or maybe you've got one more fiddly thing to maintain.
[0]: https://www.apple.com/shop/product/MK2A3LL/A/magic-keyboard-...
> Swap Control/Option ... the new binds work correctly
That means the web app knows. Or do you want it to show the wrong keycap labels instead of the correct key function names?
> Well, you can't get rid of Command-C for copy
You can. Depending on the terminal you can do it either in the app or in Karabiner
> can't get the "copy on select" behavior
Think that's also possible, maybe not in iTerm, though how is this relevant when we're talking about keybinds? Obviously you can't have two functions per key 100% (below 100% you can have context-dependency like selection), so I don't understand what your perfect baseline is? No matter where control physically is you'll still have this issue that you can't use it to copy and cancel in the same context, so the fact that you'd need to resolve a conflict in Cmd is not an argument for any position.
> but Vim's isn't
But you can detect vim and use Cmd+C to pass Ctrl+C to it, so you'd retain vim's dumb behaviour just like you'd have with the original Ctrl+C, so there is no functional improvement, just ergonomic one (though this is more complicated)
>lose the app's bind, and you don't always have a way to get it back
you can always send the original Ctrl+C key event instead of "Copy" with a different keybind, so you'd retain that function
> You can't have it both ways. Either rebinding is easy or there are many clashes.
I can:
1. It's relatively easy in one case of the terminal app where you move Ctrl+X keybinds to Cmd+X and resolve a few conflicts
2. There are many clashes if you do it another way and move keys around at the OS level. And the amount of clashes is OS-dependent, and the reason it is due to Alt (including Mac's Alt)
> Great, the Alt you were talking about is for PC keyboards. That's what I thought; dunno why we had to go deep into like, API docs for macOS. Sometimes people goof! That's OK! Now I see what you meant here.
Unfortunately, you're still confused, but trying to persist in your mistake too hard to notice. I meant both keys (Mac's Alt and Win's Alt), and the fact that they serve different functions on different OS explains how "defaults matter even if you change them", that's how Alt (includings Mac's) is relevant
(also, it's not API docs, it's general user keyboard shortcuts help, why do you need to make even these things up?)
> Yeah, the fact that you've never tried Karabiner explains a lot of why you keep wrongly insisting things are impossible
Huh I don't think I said anything's impossible. I've said things will clash or will be a lot of work, but in software all things are possible. I've been trying to define parameters around what you're saying. This is why I've been saying stuff like "if rebinding is an option then why do key layouts matter", which you've yet to explain. If installing 3rd party software and spending tons of time configuring it is an option, I think key layouts matter even less. I'm confused because you've yet to take a clear position on anything, instead you take small, generally inaccurate swipes at trivial stuff I write.
>> Swap Control/Option ... the new binds work correctly
> That means the web app knows.
No, it means the OS is passing different key codes to the browser.
> Or do you want it to show the wrong keycap labels instead of the correct key function names?
When I swap Ctrl and Option, I want Google Docs to show Option when it would have shown Ctrl. That's how I'd know the webapp "knows". But it doesn't, hence why I listed it as a drawback of rebinding.
>> Well, you can't get rid of Command-C for copy
> You can. Depending on the terminal you can do it either in the app or in Karabiner
How do I do this in iTerm2, a super popular terminal emulator for macOS? It only has a keybinding option for Paste and that only lets you create a bind. I don't see how I would use this to disable Command-C for copy. Again I'm not saying it's impossible--I thing I feel like I now have to say. You could hex edit the binary! You could redirect gamma rays to minute parts of your hard drive! I'm saying in the finite amount of time I'd want to spend on something like this, it doesn't seem straightforward.
>> can't get the "copy on select" behavior
> Think that's also possible, maybe not in iTerm, though how is this relevant when we're talking about keybinds?
Isn't the whole point to "rebind it to make your experience 100% consistent"? You must have meant "consistent with other OSes". The reason Linux does copy on select is that's its solve for "Ctrl-C is cancel".
> No matter where control physically is you'll still have this issue that you can't use it to copy and cancel in the same context...
Phew! It took a while but, this is what I've been saying. Glad we agree.
> ...so the fact that you'd need to resolve a conflict in Cmd is not an argument for any position
It's the whole problem! macOS solves the "Ctrl-C is cancel" problem in terminals by having a whole different key for it. If you scooch it over to Cmd you'll find a host of problems that are irritating to resolve, which we're currently discussing, albeit in a super awkward way.
> But you can detect vim and use Cmd+C to pass Ctrl+C to it, so you'd retain vim's dumb behaviour
Woof this is a hot take. Vim's behavior isn't "dumb", it just isn't anticipating your super weird rebinding strategy. Also I don't know what you mean by "detect vim".
>>lose the app's bind, and you don't always have a way to get it back
> you can always send the original Ctrl+C key event instead of "Copy" with a different keybind, so you'd retain that function
Of course; there's always something you can do. That's why I said "My point is that it's always gonna be a little imperfect and maybe a lot of work." But, in this case I don't think it's super straightforward. If you bind Cmd+S to Copy and then open up VLC you'll see there's no shortcut to save a playlist. Dunno what you would do about that.
> 1. It's relatively easy in one case of the terminal app where you move Ctrl+X keybinds to Cmd+X and resolve a few conflicts
I can't see a way to do any of this in iTerm2 or Terminal.app.
> 2. There are many clashes if you do it another way and move keys around at the OS level. And the amount of clashes is OS-dependent, and the reason it is due to Alt (including Mac's Alt)
Agree, but since this doesn't seem possible in the most popular terminal apps for macOS, I think this is what most people are forced into.
> (also, it's not API docs, it's general user keyboard shortcuts help, why do you need to make even these things up?)
Sorry then, what did you mean by "docs" here: "It is a literal (as in both printed on the key and referenced in the OS/docs) key on a Mac keyboard". I'm not making anything up; I'm genuinely trying to understand what you're saying, which after you being wrong, self-contradictory, and moving the goalposts for days seems to be: "Cmd's position is more convenient for the operations other OSes use Ctrl for, and you can spend a lot of time in Karabiner if you want it to function consistently with other OSes".
I've explained it several times, yet you keep ignoring the complexity in your trivialized binary option: the amount of effort differs even if rebinding is an option, so key layouts still matter
> If installing 3rd party software and spending tons of time configuring it is an option, I think key layouts matter even less.
For the same reason it actually matters: to reduce the amount of time spent
If you keep ignoring these simple facts you'll never get past your confused state of "weird to hear this so often. Macs also have the same" etc. or...
> I'm confused because you've yet to take a clear position on anything, instead you take small, generally inaccurate swipes at trivial stuff I write.
Which parts of the "better design ... more convenient thumb" confuse you? The swipes are also generaly accurate, thus you keep trying to do all the meta instead of addressing them directly.
> Sorry then, what did you mean by "docs" here
Company's keybinding help web page? You're making it up by trying to move the goalpost to narrower scope of "newer hardware" or "API docs"
> seems to be: "Cmd's position is more convenient for the operations other OSes use Ctrl for, and you can spend a lot of time in Karabiner if you want it to function consistently with other OSes".
That's also something you've made up again, on both points.
1. You can spend very little time with a few tweaks (like using a different keybind to cancel in the terminal). You need to spend a lot of time only if you insist on better matching the original conflicting design. But even then, the amount of time depends on the layout/OS
2. And no, it's not about consistency with other OS since the better design of Cmd on a Mac is NOT consistent with Windows. The goal is to achieve consistency WITHIN the OS so you can, for example, use the same key combo to copy in all apps
Oh, I didn't consider this because it's super obvious, and also the presumption of the whole thread (switching Fn/Ctrl) until you entered it. What's the value in pointing this out yet again?
>> you take small, generally inaccurate swipes at trivial stuff I write
> The swipes are also generaly accurate, thus you keep trying to do all the meta instead of addressing them directly.
Of course you write this in a post where you again only pull out very small things in my previous post, and engage with none of my larger points:
- It doesn't seem like any of your suggestions are possible
- even if they are with something like Karabiner, "My point is that it's always gonna be a little imperfect and maybe a lot of work"
>> Sorry then, what did you mean by "docs" here
> Company's keybinding help web page? You're making it up by trying to move the goalpost to narrower scope of "newer hardware" or "API docs"
No, all I'm saying is that going from "docs" to "API docs" on a site like HN isn't a big leap, and I was just making an off-hand remark that you've dug into multiple times now.
> 1. You can spend very little time with a few tweaks (like using a different keybind to cancel in the terminal).
You've not responded to my questions about specifics on this for either Terminal.app or iTerm2. I'm forced to conclude you don't actually know how to do this, if it's even possible. Also FWIW "using a different keybind to cancel" isn't something you've suggested before, which I know can be done in config files. You've only gestured vaguely at some context-dependent logic and rebinding Copy.
> 2. And no, it's not about consistency with other OS since the better design of Cmd on a Mac is NOT consistent with Windows. The goal is to achieve consistency WITHIN the OS so you can, for example, use the same key combo to copy in all apps
You can't really mean this. Are there macOS apps where Cmd-C isn't copy and adjusting the binds in System Preferences or Karabiner will fix it? I find that hard to believe.
To correct the mistake you keep repeating
> - It doesn't seem like any of your suggestions are possible
Could you resolve this self-contradiction first?
>Huh I don't think I said anything's impossible
Or name one?
> - even if they are with something like Karabiner, "My point is that it's always gonna be a little imperfect and maybe a lot of work"
I've also addressed this mistake, but you're just repeating it without any reponse to that, so can't add anything new
> No, all I'm saying is that going from "docs" to "API docs" on a site like HN isn't a big leap,
But it is a leap, in the same mistaken direction of all your other leaps. Also you forgot to excuse limiting the hardware to only the recent models to
> and I was just making an off-hand remark that you've dug into multiple times now.
And the correction was (in an off-hand remark in parentheses), why do you keep pretenting like it's not your trying to defend this silly mistake is what's "digging into"?
> I'm forced to conclude you don't actually know how to do this
No one is forcing you to spread your ignorance like that onto other people, that's just another one of your bad faith leaps
> You've not responded to my questions about specifics on this for either Terminal.app or iTerm2.
This is pretty trivial, and you rail against me for addressing your comments in a detailed manner, so I skipped that one: in Karabiner you make a simple rebind "if terminal is active, let Cmd-C send something else"
> Also FWIW "using a different keybind to cancel" isn't something you've suggested before, which I know can be done in config files.
So if you knew it's possible, why did you waste time arguing it was all time consuming and complicated?
> You can't really mean this.
Of course I don't mean what yet another one of your confused leaps resulted in. If you use Cmd-C to cancel in the terminal, this conflicts with Cmd-C as copy everywhere else. And you'd use Cmd to cancel (although not necessarily Cmd-C, far simpler to use Cmd-X or something) instead of Control because Cmd is your "control" key on a Mac
Try to remember that this whole conversation started with me trying to clear your confusion about "[winning] Macs also have the same "Fn on the far left" layout" - the far left side and relative positions of fn and Control isn't as relevant since you'd use Cmd for all control-like functions to be consistent with the rest of the OS
> in Karabiner you make a simple rebind "if terminal is active, let Cmd-C send something else"
That's great; we agree: "even if they are with something like Karabiner, 'My point is that it's always gonna be a little imperfect and maybe a lot of work'"
Everything else is you nakedly trying to score internet points instead of having an earnest discussion with me, which I would guess won't win you a lot of friends.
For sure yeah; I failed to adjust the other way. I'm so bad I bought one of those ThinkPad USB keyboards for home and used a Magic Keyboard at work.