Based on the (lack of) people I see refusing the optional facial recognition check at the TSA checkpoint for flying, I can't imagine this will be anything other than an overwhelming success for Discord and the surveillance state.
Because you're leaving 2-3% on the table for every transaction. Using a credit card doesn't mean you can't pay it off in full every month, costing you zero in interest, while taking advantage of reward programs.
On top of all the benefits, if for some reason you get hit with fraud or scammed on a debit card, it's a lot harder to get that money back. Credit is an extra layer of protection.
I've heard this, too, and it's a good reason to use a credit card at least for significant purchases. But I'd rather see those same protections extended to debit cards. I wish I understood why they aren't.
The fees that fund those protections don’t exist on the debit card.
It’s also fundamentally different. There are protections, but they depend on you being aware of the activity to avoid impact. Basically, in the event of fraud with a credit card, Chase or AMEX have a problem. With a debit card you have a problem until the resolve it. In the meantime, your payments and checks may not clear or hit overdraft.
As long as you can control your spending, credit cards are a real superpower for consumers.
I have heard this, and it is probably a flaw in my approach to purchases. But is that really justification to ask "who in the world uses debit cards"? I still feel more comfortable not being on the hook to somebody, and the organizations that extend lines of credit don't do so as a prosocial program, certainly. (Just because some people can safely make use of credit doesn't mean everyone can. I know someone who has unfortunately made poor use of their credit card, and I don't necessarily trust myself to avoid a similar fate.)
No, credit card companies aren't giving out rewards at a loss. Better cards have a higher interchange rate, ie the merchant pays more fees to accept a good card.
Hence why cash discounts are a thing (and yes they're legal again).
You do realize that 2-4% is not left on the 'table' its taken from the merchant you are shopping at. If you are at a big box store sure but when going to local merchants its best for them if you use debit or cash.
One could argue the merchant 'choose' to accept CC but in this day and age its more like extortion because the CC lobbyist were able to make it illegal to pass that charge onto the customer.
At the big box stores absolutely they have it worked in to the prices. I have no idea if the local mom and pop shops are working that 2-4% into their prices or not.
Mom and Pop stores are basically the only places left that reliably give you a cash discount for not using a card. Sometimes advertised at checkout, sometimes you need to ask.
Especially service companies. They tend to quote out "cash" (aka check/bank transfer) price and then add another 5% or so if you want to pay via card. There of course is very often an even cheaper "actual cash" price too you need to ask for if you are so inclined.
I had this thought as well. I didn't want to raise it myself, because I don't have any personal evidence that this is the case, but of course the "cash back" has to come from somewhere.
> the CC lobbyist were able to make it illegal to pass that charge onto the customer.
This is no longer a thing, there was a settlement with Visa/MC that removed this provision from their merchant contracts. You are now allowed to pass on transaction fees if you feel like it as a merchant.
It was also never illegal. It simply was part of the contract to do accept Visa/MC/Amex and they'd close your merchant account if you got caught doing it.
Handling cash costs money too though. I know some small business are credit/debit card only since they do not want to deal with the hassle of cash. Out of everywhere I have been, only one place (some grocery chain in SLC) has accepted debit cards but not credit cards.
Maybe ask if he has ever exceeded the speed limit, or run a red light, or failed to signal a turn. All things that could be monitored by a smartphone and reported to the police automatically.
Have him publish his full name, date of birth, social security number, mother's maiden name, bank checking and routing numbers, credit card numbers + expiration dates + cvv numbers, nude photos of his wife, nude photos of himself, all of the search history from all of his browsers online, all visible to the public.
Surely he doesn't see any point in keeping any of that information private, he's a good guy and not doing anything wrong, therefore he has nothing to hide and no use for privacy.
Yes, of course. What I'm trying to communicate is that if you're just doing things locally you can get all the benefits (sin sessions) from modern terminal emulators. Most people are using panes and tabs but switching to another terminal emulator will get you these and much more. If you're using the default terminal emulator, you should probably switch (you're installing a program anyways, right?).
That said, I still use tmux. Almost every day in fact. Because all my work is being done on a machine I'm not sitting in front of. This even includes at home. My main desktop is connected to a TV for videogames and movies. When I want to do work on it there's no difference if I'm sitting in front of my laptop or it other than it sitting in my livingroom keeps it cooler and gives it better air flow.
Edit:
Locally: my terminal emulator (ghostty) can do everything tmux can. I can do sessions (windows), panes, tabs, and all that. But with ghostty I also get images, a lower memory footprint (than stock emulator), lower CPU usage (than stock emulator), ligatures, and everything else. It is strictly better.
But I can't do {widows,panes,tabs} with remote connections. Hence, tmux. Which in that case, I will frequently give up capabilities (like images) for that.
You don't mention the persistence of tmux sessions, which I find very useful for local development. Does ghostty have a client-server architecture too?
I mean having long processes(batch jobs, backups, compiling, etc...) or even your opened terminal apps like your code editor or claude code don't get interrupted/killed if you accidentally close your terminal, or you terminal/desktop environment crashes/freezes. While essential for doing dev on remote servers IMO cause of "networks", is useful for local stuff too.
Tmux is going to solve some problems that your standard emulator won't solve. I agree.
BUT
1) I'm unconvinced the things it solves that emulators don't do are common situations
2) tmux isn't "free". There are trade-offs that you have to make for tmux.
There's definitely edge cases where I do run tmux locally, but I find them rare and there's usually another solution (and I definitely do a lot more "weird things" than the average user will, so I run into more "edge cases").
But most users are turning to tmux for the {tabs,panes} feature (and then using sessions like anyone would use a window).
> interrupted/killed if you accidentally close your terminal
Sure, I get you, but I'm also not sure what tmux is doing for you in most cases. I'll give you that it's easier to kill your terminal pane than it is to kill the tmux server, but it is still easy to kill a pane or tab in tmux. I think there's better defenses here to prevent those mistakes. I mean you can just put a window in a different workspace and get very similar defenses as to what tmux is giving you. You're right, that isn't a reliable defense, but that's true about tmux here too.
If you have a process running that needs to stay alive for long periods of time then does it need to be running interactively? It is pretty rare that long running processes need be running interactively. Not rare in the sense that an average user is going to do this infrequently, but rare in the sense of few users are going to do this infrequently.
- You can always throw running jobs into the background by doing: <C-z> (suspend), `bg` (resumes program in background), and `detach` (so the process is not attached to the current terminal instance).
- If you're launching a job consider using `&`
- Remember, you can always reattach to a running process too. If you still have the terminal open it is trivial with `fg`. If you don't, then you can still attach with strace or gdb, but you'll probably need `sudo` and this isn't exactly trivial.
- If you know your job needs to be interacted with then there's better ways to handle that communication like by setting up a pipe. But that requires forethought.
- or the best option is to actually run it as a service since you'll get a lot more benefits and flexibility through that. It's pretty quick to turn anything into a systemd job.
- You can interact with systemd jobs if you set them up that way. Lots of fancy options here from ttys, pipe, sockets, or containerizations.
- systemd-nspawn or systemd-vmspawn. Containers are honestly the best option for long running but interactive jobs.
--- Aside ---
Batch jobs:
script and should run in the background. Are your batched jobs not scripted? Just copy paste your loop into a file and add the header. I typically add a few more lines for logging and stuff but yeah. I mean if I want that output I usually want that output longer than my session will be alive, so logs. That way they also are organized.
Backups:
unless you're doing a quick rsync then this really should be automated. A service is the solution. If you find yourself needing/wanting to manually run, you can also just call the systemd job. But yeah, if I have a one-time big sync, I'll pull up tmux (or caffeine). But that's different than always running in tmux.
Compiling:
I'll be honest, locally I rarely have long compiles (or anything over a few minutes). Anything that is long and repeated should be incrementally compiled. I mean this is a much more robust strategy anyways and in a long compile there's a lot of potential disruptions that are far more likely than me closing my terminal window. But in those rare instances I usually throw the process into the background (or start with `&`) or will turn on caffeine or whatever to keep my machine awake.
--- /Aside ---
> or you terminal/desktop environment crashes/freezes
This seems like a more complicated issue. Depends on the crash, right? But how often are you crashing? If frequently enough that you're going to default to running in tmux then I think you have bigger problems. Honestly, I don't think I can remember a time where only my DM or terminal crashed and the whole system didn't go down. Well... DM on a boot, but that's not the situation we're discussing. Maybe if I did something stupid like try to mess with the DM while the DM is running, but... I mean... tmux isn't going to fix the root problem... IDK if it will fix any problem there...
I'm not sure how often ghostty calls the window-save-state command but it looks like you should be able to call this frequently, though I haven't tried it and I'll give you this one because this definitely requires more work. Though ghostty will survive a reboot and you need a plugin for that with tmux. But either way, this is related to the lesson of backup often. Or commit frequently.
> While essential for doing dev on remote servers IMO cause of "networks"
If we're talking about remote, well that's why I use tmux every day. I didn't say there's no point to tmux, just that the vast majority of things it does *locally* can be accomplished without it.
I'm 100% supportive of tmux with remote connections.
If you're having that spotty connection then I think the better solution is using something like mosh or the best option is configuring better timeouts in ssh{,d}_config. Look at `TCPKeepAlive`, `ServerAliveInterval`, ServerAliveCountMax` (s/Server/Client/g for sshd_config)
I cannot phantom why anyone would write lengthy walls of text trying to convince people "no askhually, your workflow is invalid and theres a better way!11" after they've told you very directly and clearly several times that this works well for them. People have different preferences. People are telling you that this works well for them. They don't really don't need to be condescendingly "educated". Learn to listen.
Neural networks absolutely are designed. Network architecture is one of the primary innovations in NNs over the years, and transformer architectures are the biggest development that enabled modern LLMs.
In addition, behavior is designed indirectly through human reinforcement.
The individual weights aren’t designed themselves, but there is a ton of design that goes into neural networks.
I'm admittedly out of my depth, but think the point is the current state of architecture is one of rapid and volatile iteration. There isn't really a comprehensive "design" because each generation is building (and in some cases rebuilding) upon the previous generation.
> I've had decent results recently with non-trivial Cuda/MPS code.
reply