> it's not really viable to audit the entire dep chain by hand
When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc.
Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.
For me, it'd be primarily having more than one undo. Not being able to undo the second-to-last change is pretty bad. In fact, vim's undo being set up as a tree that can be walked with g- and g+ is excellent. It's impossible to lose a state of the buffer, even if you undo and make changes. It's a lot more practical to navigate than Emacs' undo, too.
EDIT: I just realized that nvi can undo more than one change by having u toggle the direction and . continue in that direction. I don't think ex-vi could. busybox vi seems like it can undo multiple with u but it seems to have no redo.
> For me, it'd be primarily having more than one undo
Do you mean infinite undo? nvi has that. I'm not sure what you mean "set up as a tree" wrt undo, but i'll look into it. I think of nvi's undo as linear - I can 'u' to "undo" and implicitly set my "undo direction" "backward in time" (as one would expect). If I want to "undo, even more", '.' (dot, period) to "do that last command again" is what I'll do. If I want to "undo an undo", 'u'. That has the effect of moving the "undo direction" back towards the state of the buffer we had at the beginning of our discussion here.
> can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate.
Because vim generally offers everything vi has.
vi does have one advantage though. It's a lot lighter. vim is like 5.4MiB in size with 82 shared library dependencies, while vi[1] is like 260KiB with 2 library dependencies (libc and ncurses).
Right. Sometimes all you need is to edit a couple lines in a config file and get out, in which case hjkl, i/a, and Esc (and then :wq) are all the editor really has to implement. (And a few more movement tools like w/b and so on). Plugins? Colorschemes? You don't need 'em to edit a couple lines in a config file. (I'll grant that syntax highlighting that makes the comments a different color from the actual lines can be helpful, but if it comes at the cost of a much larger binary it's not always worth the cost on those resource-constrained systems).
Do the links actually support the statements? When I've followed such links, it's generally been a roll of the dice on whether they do support the AI's statements.
Yes. The links are to isolated threads on a rail (model) forums (apparently, this publisher markets books/magazines related to railway models).
It's hard to see if the individual complaints really support a general problem, or if this simply the only result that talks about "scam + business-name". Probably, the latter.
The same problem happens on google search, if you look "<obscure false fact>", you'll get pages mentioning that false fact. If you fall into the trap of confirmation bias, it leads you to think the false fact is in true.
That earns you a special position as one of a pair of guards in a labyrinth with two doors, one of which leads to freedom and the other to... ba-ba-ba-bum - certain death.
It's not about a special status of flight captains. Same can be said of e.g. a store manager acting in-place of the owner. It's a matter of one being on someone's private property, instead of on public property.
Hi, when I was in flight school it wasn’t explicitly stated but certainly heavily implied that as pilots were not allowed to trespass passengers and kick them off the plane mid-flight.
If you have information to the contrary, I would like to be made aware because occasionally I have ended up stuck for hours in the air with unpleasant passengers.
When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc.
Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.
reply