Search
306 results for “YesJustWolf”
-
@FritzAdalis @RuntimeArguments @jammcq @YesJustWolf
Thanks. I did look this up after I wrote the post. I should have looked it up before. But still, without knowing that history, it appeared the speaker was either confused about #OpenSSH and #OpenBSD or equating them or something. It wasn't obvious to me that the OpenBSD team *wrote* OpenSSH. That's the way I heard it, might have misinterpreted what was said.
-
@RuntimeArguments @jammcq @YesJustWolf
You touched on the -R flag briefly. I've used it, but I don't recall it for the purpose you mentioned.
I need to check out using certificates.
I didn't know about password managers being ssh key agents. Another thing to check out, as I use a few 😀
I also didn't know about ssh-import-id-gh, which doesn't appear to be part of any package in the Fedora repos.
A better episode than I expected given my long use of #SSH.
2/2
-
@RuntimeArguments @jammcq @YesJustWolf
I've been a #UNIX user since 1984, and spent my working life developing flavors of Unix and now #Linux. I listened to this episode over the past couple of days. I'm a long time user of #SSH One point of confusion and a few points that I learned.
When talking about the origins of #OpenSSH you talked about #OpenBSD but didn't explain how it related to OpenSSH . Was OpenBSD involved in the creation of OpenSSH ? It could have used explanation.
1/2
-
Today, it’s the Red Queen’s Race: I have to run as fast as I can just to stay in one place. All hands on deck at work. I’m a bottleneck. I’ve dropped everything droppable, so I can focus on just one thing.
-
When someone tells you how to solve their problem, they're almost always wrong. Not because they're foolish. Because the reason they need you at all is that you're better at How, in this particular domain, than they are.
But their "ask" is completely upside-down! Does their How even achieve what they need? That's the What. And does the What serve what they actually care about? That's the Why. You almost never get to Why from outside. When you do, you give them something they couldn't have asked for. How is exactly the wrong place to start.
Three levels every decision lives at (and this is the order that matters):
Why: values, principles. What you act from, not toward. No completion state.
What: the specific outcome you need. Testable. You'll know when you have it.
How: the implementation.
Most thinking happens at How. Most arguments too. Start at Why, get the What clear, then let the What evaluate the How. Once you've stated the What clearly, every How is just yes or no. I align completely with Sinek: start at Why.
Simon Sinek's Golden Circle is in this neighborhood. His order is Why, How, What, and it's about communication: lead with belief, not product. Useful! Mine is about decisions, not messaging. The order is Why, What, How. The What in the middle is load-bearing. Without it you're either arguing about details or just hoping.
#productivity #leadership #tech #programming #management #philosophy #DecisionMaking #ProductManagement #career #SimonSinek #Consulting
-
When someone tells you how to solve their problem, they're almost always wrong. Not because they're foolish. Because the reason they need you at all is that you're better at How, in this particular domain, than they are.
But their "ask" is completely upside-down! Does their How even achieve what they need? That's the What. And does the What serve what they actually care about? That's the Why. You almost never get to Why from outside. When you do, you give them something they couldn't have asked for. How is exactly the wrong place to start.
Three levels every decision lives at (and this is the order that matters):
Why: values, principles. What you act from, not toward. No completion state.
What: the specific outcome you need. Testable. You'll know when you have it.
How: the implementation.
Most thinking happens at How. Most arguments too. Start at Why, get the What clear, then let the What evaluate the How. Once you've stated the What clearly, every How is just yes or no. I align completely with Sinek: start at Why.
Simon Sinek's Golden Circle is in this neighborhood. His order is Why, How, What, and it's about communication: lead with belief, not product. Useful! Mine is about decisions, not messaging. The order is Why, What, How. The What in the middle is load-bearing. Without it you're either arguing about details or just hoping.
#productivity #leadership #tech #programming #management #philosophy #DecisionMaking #ProductManagement #career #SimonSinek #Consulting
-
When someone tells you how to solve their problem, they're almost always wrong. Not because they're foolish. Because the reason they need you at all is that you're better at How, in this particular domain, than they are.
But their "ask" is completely upside-down! Does their How even achieve what they need? That's the What. And does the What serve what they actually care about? That's the Why. You almost never get to Why from outside. When you do, you give them something they couldn't have asked for. How is exactly the wrong place to start.
Three levels every decision lives at (and this is the order that matters):
Why: values, principles. What you act from, not toward. No completion state.
What: the specific outcome you need. Testable. You'll know when you have it.
How: the implementation.
Most thinking happens at How. Most arguments too. Start at Why, get the What clear, then let the What evaluate the How. Once you've stated the What clearly, every How is just yes or no. I align completely with Sinek: start at Why.
Simon Sinek's Golden Circle is in this neighborhood. His order is Why, How, What, and it's about communication: lead with belief, not product. Useful! Mine is about decisions, not messaging. The order is Why, What, How. The What in the middle is load-bearing. Without it you're either arguing about details or just hoping.
#productivity #leadership #tech #programming #management #philosophy #DecisionMaking #ProductManagement #career #SimonSinek #Consulting
-
When someone tells you how to solve their problem, they're almost always wrong. Not because they're foolish. Because the reason they need you at all is that you're better at How, in this particular domain, than they are.
But their "ask" is completely upside-down! Does their How even achieve what they need? That's the What. And does the What serve what they actually care about? That's the Why. You almost never get to Why from outside. When you do, you give them something they couldn't have asked for. How is exactly the wrong place to start.
Three levels every decision lives at (and this is the order that matters):
Why: values, principles. What you act from, not toward. No completion state.
What: the specific outcome you need. Testable. You'll know when you have it.
How: the implementation.
Most thinking happens at How. Most arguments too. Start at Why, get the What clear, then let the What evaluate the How. Once you've stated the What clearly, every How is just yes or no. I align completely with Sinek: start at Why.
Simon Sinek's Golden Circle is in this neighborhood. His order is Why, How, What, and it's about communication: lead with belief, not product. Useful! Mine is about decisions, not messaging. The order is Why, What, How. The What in the middle is load-bearing. Without it you're either arguing about details or just hoping.
#productivity #leadership #tech #programming #management #philosophy #DecisionMaking #ProductManagement #career #SimonSinek #Consulting
-
When someone tells you how to solve their problem, they're almost always wrong. Not because they're foolish. Because the reason they need you at all is that you're better at How, in this particular domain, than they are.
But their "ask" is completely upside-down! Does their How even achieve what they need? That's the What. And does the What serve what they actually care about? That's the Why. You almost never get to Why from outside. When you do, you give them something they couldn't have asked for. How is exactly the wrong place to start.
Three levels every decision lives at (and this is the order that matters):
Why: values, principles. What you act from, not toward. No completion state.
What: the specific outcome you need. Testable. You'll know when you have it.
How: the implementation.
Most thinking happens at How. Most arguments too. Start at Why, get the What clear, then let the What evaluate the How. Once you've stated the What clearly, every How is just yes or no. I align completely with Sinek: start at Why.
Simon Sinek's Golden Circle is in this neighborhood. His order is Why, How, What, and it's about communication: lead with belief, not product. Useful! Mine is about decisions, not messaging. The order is Why, What, How. The What in the middle is load-bearing. Without it you're either arguing about details or just hoping.
#productivity #leadership #tech #programming #management #philosophy #DecisionMaking #ProductManagement #career #SimonSinek #Consulting
-
If I recall correctly, it was Akkana Peck @akkana who first introduced me to Python, probably around 1998 or 1997 (so something in the neighborhood of Python v1.5) while working together at Netscape (I had a different name back then). **That** turned out to be a life-changing event; so thanks, Akkana!
-
Let's say you want to do good type-checking for the #Python project you're working on. You pick a tool, maybe you use it as an #LSP also (so your editor can show you errors, too). As an example, I'm using #Ty at the moment. There's three places this might be installed: globally (e.g., `brew install ty`), as a dev-only dependency inside your project (e.g., `uv add --dev ty`), or -- and this one might surprise you -- it might only be used and installed by `pre-commit`, which builds a separate environment for each needed tool (which is great for instance where I use `codespell` as a `pre-commit` check, which seems to need some higher version of Python than my actual project).
Where should you install it?
If you're the only one on your team running it, globally is fine. If more than just you, then absolutely as a dev-only dependency inside your project ... and **maybe** globally as well.
The only real problem is updates. If you use a reasonable global install scheme, updates will be easy. They're less easy inside your project or in `pre-commit`. And you might care one way or the other! I **don't** want updates! I **do** want updates!
As for Python type-checking, `ty` seems good so far, but not enough experience with it yet. `basedpyright`, `pyrefly`, and `ruff` all good. These four are my favorites.
#BasedPyright #Pyrefly #Ruff #PreCommit #CodeSpell #Homebrew
-
My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:
* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule oneThat was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.
-
My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:
* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule oneThat was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.
-
My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:
* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule oneThat was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.
-
My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:
* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule oneThat was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.
-
My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:
* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule oneThat was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.
-
The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.
If you're not using using `direnv` yet, you are doing yourself a disservice.
-
The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.
If you're not using using `direnv` yet, you are doing yourself a disservice.
-
The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.
If you're not using using `direnv` yet, you are doing yourself a disservice.
-
The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.
If you're not using using `direnv` yet, you are doing yourself a disservice.
-
Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)
-
Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)
-
Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)
-
Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)
