The familiarity is great but the thing that really draws me to Plasma over Gnome is that the KDE developers seem to have an attitude of just implementing the features people want even if it's not perfect yet. Gnome is polished, but it's missing so many basic configuration options out of the box.
It's kind of funny because when I first got into linux it was practically the opposite story. Back in the day of KDE 2 or 3 and Gnome 2, KDE was the slow one to bring in features while Gnome felt like the wild wild west.
Now it seems like Gnome has gone down a practically walled garden path which I don't love. Last I tried it, I wanted to launch an app focused and in full screen on startup. The gnome response for that was basically "You're not allowed to do that".
I can't speak to actually setting it up, but where I work we have an IT-provided yubikey ssh-agent that handles getting all that stuff set up, and we just paste the public key from our individual yubikeys into our authorized ssh keys with our on-prem-hosted bitbucket server. However almost everyone I know quickly gets sick of touching the yubikey for every git remote operation and just generates their own local SSH key to use for git since doing so is not forbidden. It's definitely not High Security, but since our git is on-prem and can only be accessed from within the corporate VPN the risks are probably lower than if we were using something shared on the public internet.
The obvious solution is an ssh-agent integration that caches the touch-derived key for up to N hours or until the workstation is locked (as a proxy for user-is-away event), AND integrates with secure desktop (à la UAC) to securely show a software-only confirmation prompt/dialog for subsequent pushes within the timeout window.
(Tbh, a secure-desktop-integrated confirmation dialog would solve most issues that needed a hardware key to begin with.)
> almost everyone I know quickly gets sick of touching the yubikey for every git remote operation and just generates their own local SSH key to use for git since doing so is not forbidden
Yes, that's the exact problem at hand. If you generate your own local SSH key, the private key sits on the disk, and it can be stolen by malware (see article).
I'm asking how people set up the controls such that only hardware-based keys are signed by the CA.
The article is presenting something different entirely. This is the precursor to what it would take to create a compiler written in java that produces native code.
Regardless of whether you use JSON or Protobuf, the only way to be safe from version tears in your serialization format is to enforce backwards compatibility in your CI pipeline by testing the new version of your service creates responses that are usable by older versions of your clients, and vice versa.
Yeah, no discussion of this topic is complete without bringing up schema evolution. There’s a school of thought that holds this is basically impossible and the right thing to do is never ever make a breaking change. Instead, allow new fields to be absent and accept unrecognized fields always. I think this is unsustainable and hard to reason about.
I have not found it difficult to support backwards compatibility with explicit versioning, and the only justification I’ve seen for not doing it is that it’s impossible to coordinate between development teams. Which I think is an indictment of how the company is run more than anything else.
That's why this was the year I finally dropped Windows and VSCode forever. Not that hard for me because all the games I play work flawlessly in Proton, and I already used Linux at work.
You can drop Windows and keep VSCode. I'm running it on this laptop (Kubuntu 25.04).
To install it, browse to here: https://code.visualstudio.com/ (search: "vscode"). Click on "Download for Linux (.deb)" and then use Discover to install and open it - that's all GUI based and rather obvious. You are actually installing the repository and using that which means that updates will be done along with the rest of the system. There is also a .rpm option for RedHat and the like. Arch and Gentoo have it all packaged up already.
On Windows you get the usual hit and miss packaging affair.
Laughably, the Linux version of VSCode still bleats about updates being available, despite the fact that they are using the central package manager, that Windows sort of has but still "lacks" - MSI. Mind you who knows what is going on - PShell apps have another package manager or two and its all a bit confusing.
Its odd that Windows apps, eg any not Edge browser, Libre Office, .pdf wranglers, ... anything not MS and even then, there are things like their power toy sort of apps, still need their own update agents and services or manual installs.
Yes but winget is not the Windows central package manager. Actually, Windows does not have one but for some reason you have enforced updates from a central source.
Why does Windows not have a formal source for safe software? One that the owner (MS) endorses?
One might conclude that MS won't endorse a source of safe software and hence take responsibility is because they are not confident in the quality of their own software, let alone someoneelses.
I believe that MS wants that to be their own MS Store, though I don't know of a single person who actually uses it as their preferred way to manage software. For what it's worth, VS Code is available there: https://apps.microsoft.com/detail/xp9khm4bk9fz7q
Not who you responded to, but for a GUI editor I tend to like Zed, and for terminal I like Helix. Yes, Neovim is probably better to learn because Vim motions are everywhere, but I like Helix's more "batteries included" approach.
I decided to finally learn a modal editor and installed Helix. Ideal for me since it's very hackable if you're already familiar with Rust. Very easy to build from source. Plus all I need is LSP support and I'm good at work, clangd is all I need for an IDE.
Yeah everyone I've tried to introduce helix to who was already a vim master hated it. It's great for people who don't already have that muscle memory, I found the reversed selection->action model a lot more intuitive personally.
Right, the 4g/day number is the amount that should be safe for any relatively healthy adult (minus whatever is making them take the medicine). I should hope it isn't too close to the number where you can cause permanent damage.
It's become fashionable to fearmonger about it lately, but I agree, it's safe to assume the makers wouldn't tolerate the liability that would come with a single extra dose above the given instructions causing that kind of harm.
The side channel from memory access timings are exactly why cmov is its own instruction on x86_64. It retrieves the memory regardless of the condition value. Anything else would change the timings based on condition. If you're going to segfault that's going to be visible to an attacker regardless because you're going to hang up.
AFAIU, cmov wasn't originally intended to be a guaranteed constant-time operation, Intel and AMD won't commit to keeping it constant-time in the future, but it just so happened that at one point it was implemented in constant-time across CPUs, cryptographers picked up on this and began using it, and now Intel and AMD tacitly recognize this dependency. See, e.g., https://www.intel.com/content/www/us/en/developer/articles/t...
> The CMOVcc instruction runs in time independent of its arguments in all current x86 architecture processors. This includes variants that load from memory. The load is performed before the condition is tested. Future versions of the architecture may introduce new addressing modes that do not exhibit this property.
At your link there is a link to the list of instructions that guarantee constant execution time, independent of the operands.
The list includes CMOV.
However, the instructions from the list are guaranteed to have constant execution time, even on any future CPUs, only if the operating system sets a certain CPU control bit.
So on recent and future Intel/AMD CPUs, one may need to verify that the correct choice has been made between secure execution mode and fastest execution mode.
I mean the possibility that the rest of the program guarantees that the address is valid if the condition is true but otherwise it might be valid or invalid. This is probably not important for most applications, but I don't know if there are some unusual ones where it would matter.
reply