111–120 of 123 posts
Earlier quoted context omitted.
A slight difference though. If a newbie picks up grandpa's chisel, it doesn't get glued onto their hand until they google the three magic words they must shout to make the chisel come off.
At least it forces you to find and read the documentation.
Earlier quoted context omitted.
I am not sure it's so black and white with encryption. It depends on your threat model. Keeping it secure from an angry ex-girlfriend is one thing, but keeping it secure from a three letter agency is another. The mistake you are referring to is someone that assumes "encrypted" means three letter agency safe, which is a pretty terrible way to leverage encryption. In that case, it's exactly like hopping in a Tesla and…
> The mistake you are referring to is someone that assumes "encrypted" means three letter agency safe, which is a pretty terrible way to leverage encryption. That's not a mistake, that's table stakes. People reading that X offers "encryption", should assume its cryptographically safe to the standards of the day, and be given that. Not just some "safe from your spouse, ...maybe..." glorified rot13. Else, just don't of…
Thus, the GF V. FBI scenario. Just because you "encrypt" something doesn't make it '100% Safe'. Such as someone keylogging you for your onepass pass.
[0] https://www.washingtonpost.com/graphics/2020/world/national-...
In a world of fleeting software, Vim is a timeless masterpiece. I only wish I had the opportunity to thank Bram for the impact he's had on my life and career, because I don't think I would have come as far without Vim.
Earlier quoted context omitted.
I understand your metaphor but I think it's probably a stretch. Maybe it's better to say the tool has sharp edges that if you aren't familiar with it, can bite you. But with a bit of practise and some knowledge you can master it.
It's not a stretch that practically everybody who accidentally ends up in vim (often because it's git's default editor) ends up googling how to exit the program. It's the tool that you can't even drop by any intuitive action.
The beginning screen of vim tells you how to exit.
If you do C-c, as normally is the case with TUI programs, Vim also tells you how to leave.
The "I don't know how to exit Vim" is a bit overplayed.
Earlier quoted context omitted.
Home row is jkl;
As a reminder, that's why most keyboards have physical indentations in f and j. They're meant to be felt by index fingers.
I didn't care about them on my old QWERTY because I wasn't touch typing correctly, now I understand why the indentations are there.
Earlier quoted context omitted.
> That's regardless of people "having the right to fork". Yes they do. But also yes, if they exercize that right, they do split a community and divert interest from a project to 2 projects. You're not dividing the same-sized pie. The alternative to a fork is a single project with fewer contributors. The alternative to two communities is a single community that's not as large as the two would've been, with a good chun…
> You're not dividing the same-sized pie. We do. Neither vim-or-vim-fork editor users nor vim-or-vim-fork-potential-devs are going to see any significant jump in population from the presense of neovim. People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist. And from people contributing to vim via themes, plugins, etc., some have taken their talents…
It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want. In reality it is likely to lead to more total developers working on the ecosystem.
It contains the misconception that code created for the fork is worthless for the primary project despite the fact that compatibly licensed code can either directly be used or can be used as a conceptual v1 that can be improved with the benefit of the prior work.
> Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades. This is brought to you by the same line of thinking that we all ought to work on one foo where foo is a an application because then and only then would open source compete with the billions of dollars poured into photoshop and the entrenched benefit of OEMs supporting the windows ecosystem with its application ecosystem, broad hardware support, billions of dollars to pay developers, and ability to earn money on shovelware and convince grandma to instead download Linux ISOs.
Just because its commonly expressed doesn't mean there is merit to the argument.
Earlier quoted context omitted.
I've been a happy vimmer for 15 years. I've been dabbling in helix for a month and liking it a lot. The ast-aware selection capabilities--while not habit yet--feel like a fledgling superpower.
Neovim has a plugin for that too.[1] Is Helix different in how you can navigate the syntax tree? [1] https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
There's something to be said for having it baked in though. I've been nix-ifying my configs and not having to think about any plugins was a welcome change.
(Unless you count language servers as plugins, which you maybe should.)
Earlier quoted context omitted.
I understand your metaphor but I think it's probably a stretch. Maybe it's better to say the tool has sharp edges that if you aren't familiar with it, can bite you. But with a bit of practise and some knowledge you can master it.
It's not a stretch that practically everybody who accidentally ends up in vim (often because it's git's default editor) ends up googling how to exit the program. It's the tool that you can't even drop by any intuitive action.
Of course it is possible that one might not think of using ctrl+c, but that's lacking general shell knowledge, not vim knowledge.
Earlier quoted context omitted.
> You're not dividing the same-sized pie. We do. Neither vim-or-vim-fork editor users nor vim-or-vim-fork-potential-devs are going to see any significant jump in population from the presense of neovim. People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist. And from people contributing to vim via themes, plugins, etc., some have taken their talents…
This thought process contains the misconception that non-paying users are the primary currency that sustains a project as opposed to developers even though the former are nearly worthless and the latter vital. It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional…
And yet, projects that fail to get adoption and foster a community rarely go that far, except if they're small hobby projects that can fit on one or two developers scope.
>It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want.
Projects are not just about core developers. They're also about adoption, documentation (webpages, posts, books, articles), plugins, even themes, and configuration bundles. All of those are split in a fork.
And it's not like without NeoVim most of those vi-style-liking people would have gone to a totally different alternative editor. Most of them would have stayed with Vim. Especially when the differences where small to begin with (but enough to fragment compatibility in many areas).
Devs and users (including new devs and users) that would have gravitated towards Vim, now have the addec choice to gravitate towards NeoVim. The amount of people, that, absense of NeoVim, would have gravitated towards something completely different is, I'd say, much smaller.
>If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades
People have mentioned actual projects that have been hurt by forks. XFree86 vs X.org, OpenOffice.org vs LibreOffice, MariaDB vs MySQL, and others. The xBSD fragmentation didn't help either to them losing ground to Linux.