While I agree with what we don't need, something is still off with the UI. I can't really put my finger on any specific problem, though. It's just a gut feeling.
The names are bold faced, so my attention is drawn to them, but since i don't recognize any of them, i don't even know where to start reading.
i'm not from the US, but i did work on forms related to government workflows.
it bugged me for a long time why a person can't store facts about themselves and let some software figure out which of those facts are needed for filling out any form, which needs the usual personal facts.
then one can review the required facts and decide which ones are they willing to share.
in fact governments could even standardize the kind of info they are dealing with usually and when a citizen wants the government to do something, instead of filling out forms, they could provide their own, self-hosted fact db, run the govt's query and provide the results (after review)
I think the post office could have been this, but the political will wasn't there. Separation of banking from taxation and the postal system from both of those for separation of concerns for compartmentalization was probably at the forefront of the minds of the founders, since Washington himself had run a spy network and been personally hunted by soldiers and mercenaries on their own turf during the revolution, so I can't say these aren't legitimate concerns, but they haven't exactly aged well. At the time of the revolution and directly after the union, there was no federal income tax anyway.
Hypothetically, you could have sent 0.01 to a friend and use the memo field as a poor man's postcard with free postage, provided in-system transactions were free, which they arguably ought to be, but likely never were or would be in actuality.
Taxes work on "self assessment" basis meaning you, the taxpayer have the burden to declare all facts relevant to assessment of your tax and you pay the tax.
Then, sometimes your case is picked for audit and then they check if what you declared is correct as per applicable laws or not.
See, here is a small mom and pop shop... who owns that? Is the premises on rent? How much ? Is the rent deed valid and proper? Maybe you are paying less rent than declaring? Are you actually employing people you say you are? Are you paying them exactly you say you are paying?
How would you ensure that fact db is not having funny data ?
Say i am saying i am paying 100 bucks a week for fuel but fact is, my shop is next door to my home and i am just pocketing this cash daily. If i keep putting this 100 bucks weekly expense in this factdb, how will govt know.that i am not lying?
It’s my understanding that they have expected ranges certain things should be within that’s considered normal and anything outside of that puts a higher risk of an audit or simple manual review/adjustment.
You're moving the goalposts; the purpose would be reducing toil (and possibly other costs) for the people who are currently tasked with filling out these types of forms.
There's nothing in the comment you're responding to that suggests that it's instead meant to be a solution to the problem of the government (or any other org) being unable to trust the inputs to its systems or ameliorate the costs of bad actors at all.
A person entering lies in their personal fact database tomorrow can submit the same lies on their personal income tax return today.
it also doesn't quite work with macOS remotes usually.
again, not purely TRAMP's fault, but a default config and habits issue with ~/.zshrc vs ~/.zprofile and maybe /etc/sshd/config settings, i think. i hasn't fully figured it out yet.
using this kind of "full-screen terminal screen sharing" approach has a more predictable experience, because of the amount of data transferred is usually 1 screen worth of characters (and colors) max, on most keystrokes.
that's both a pro and a con.
it imposes a fixed, network connection dependent input lag and the output is also often redrawn by retransmitting the same data over and over again...
my biggest problem with azure was also the fact that they couldn't stick to industry-standard terminology, but they has to invent their own. it made azure docs tremendously confusing.
or they should just make sure emacs can work with the machine thru ssh, then there is nothing to install ;)
if no ssh, then nano is not a bad option, though i would go with joe (https://joe-editor.sourceforge.io/) which can also show the shortcuts, but much much more powerful, yet it's just a single ~700kbyte exe (or 1.5MB with some optional syntax highlighting grammars and docs)
>or they should just make sure emacs can work with the machine thru ssh, then there is nothing to install ;)
While (neo)vim doesn't have TRAMP and dired, it has netrw, which does the same stuff (on a basic level). You can do the following to edit a remote file:
vim scp://user@hostname/path-to-file-here
You can also replace user@hostname with an ssh alias you've configured, which makes it easier to work with multihop ssh and different keys and users. One useful usage of the remote editing is to combine it with opening multiple files to compare two files on different machines:
vim -O ~/.config/mpv/mpv.conf scp://htpc/.config/mpv/mpv.conf
To browse a directory instead of a specific file, just put the dir instead of a non-dir file and it will open a filebrowser view where you can then pick a file to open. In the above examples, leave off mpv.conf and you'll then be able to pick either your mpv.conf or input.conf or files related to your mpv scripts.
chawan has a custom terminal module, so my knowledge about the standard X/Open curses is not that great.
That said, for the actual escape sequences, XTerm's ctlseqs.ms[1] is an invaluable resource. I also took many ideas from nick black's notcurses[2], and I especially recommend his notes on "sprixels".[3]
Is there some "industry standard" or "best practice" for such a metric?
I guess Bitwarden might have something publicly available...