I recently did the same thing, as 95% of my incoming call volume in a week was spam calls. It's been great. The friction I feel is when interacting with ephemeral contacts like contractors, etc. I've had to try to be diligent about adding them as contacts if I expect a call back, or hoping they leave a voicemail.
It's sad there really isn't much you can do about it. I tried do-not-call lists, answering and telling them to stop calling me, reporting them - all was apparently a waste of time.
In our modern world, every last vestige of trust is being abused. Government bureaucracy is an increasingly-visible problem, and a lot of it is insulation to protect lobbied interests, but some of it is a good-faith reaction to the way various actors abuse trust in a market. Eventually, there will be no trust left in society, whether due to law or personal technology. Apple would do well to take the lead on better ways to handle this on the personal side.
1000%. The number of times I’ve tried to go straight to the correct well factored abstraction and it worked out are countable on one hand. This is one of those pieces of advise that I know to be true yet it takes continuous effort to enact.
I have tried to switch quite a few times over the years to Firefox and I still to this day consistently run into websites that are unusably broken on Firefox, do you have the same experience? I realize this probably speaks volumes to the need for more people to use browsers other than Chrome but its unfortunately frequent enough that I always end up switching back to Chrome after a few months.
The web interfaces for both Jitsi and Zoom fail to recognise my web camera. I've gone through the permissions settings a dozen times and Firefox says that it sees camera, but it only displays a black feed. Vivaldi correctly accesses the camera on both sites.
imascientist.org.uk makes it "impossible" to sign up for outreach sessions under Firefox. The div with the sessions has a `max-width` parameter, but the contents are significantly larger than this width, resulting in the buttons being outside the rendering area and inaccessible. I have to go into the dev tools and edit the CSS every time I open the page.
These are just the issues that I've dealt with today. Don't get me wrong - I'm literally typing this in Firefox at this moment. However, it doesn't help anyone to pretend that these issues never pop up. I simply feel that the benefits outweight these annoyances.
If I record correctly, Mozilla has said that like 97% of all problems people has is with problems is due to extensions, not Firefox. '
When you have a site not working as expected, start Firefox in "Troubleshoot Mode" (alt-key then in the menu at the top Help > Troubleshot mode) that starts Firefox with addons turn off. If the site works, restart and turn of addons one by one to you see which one creates the problem.
Very strange. I run Zoom constantly in FF - my company does several events a week that I edit, so i’m thick in the weeds on zoom’s site doing admin/recording management stuff. Almost 3 years on zoom’s site almost every single day, never had to swap browsers. Mac Studio if that matters.
I unfortunately do not have a running list. The one that made me drop Firefox last time was the mermaid.js docs site. None of the sidebar navigation was clickable but only on Firefox, the same issue did not appear on Safari or Chrome. It appears they have since fixed that issue as I retested and it appears fine.
The "give me examples" is sort of a moving target, anecdotally I have run into many more completely or partially broken sites when using Firefox as compared to Chrome and Safari. It is likely that some or all of those examples are now fixed but the pain in the moment is enough to keep me from using the browser long term.
Often people forgot they have installed an obscure exstension in Firefox and that is breaking the site, trying another browser it works, concluding that Firefox must be the problem, while it was the extension. That is also why people usually cannot reproduce the problem later or give concrete examples.
I've been using Firefox as a daily driver for four years and have not run into a single site that was truly "unusably" broken except perhaps some Google-published tech demo for a new webgpu feature.
I've occasionally run into relatively minor visual issues (I think from before the :has pseudo-class was made generally available in FF) but I cannot think of a single instance where a site was unusable and then worked when I tried it in Chrome.
I, similar to the parent, have very few issues on either my computers or phones. I run Firefox on several different OS's and I just don't have the issues you mention.
Do you have some examples of websites that really behave that differently depending on the browser you're using?
Having lived through the "best viewed with..." days I'd hoped we were past all that by now!
The most recent ones that I ran into seem to have been fixed based on a quick check. mermaid.js docs site was one of them where nothing on the page was clickable (I think Firefox was rendering an invisible div over the entire page) but this issue wasn't present in Chrome or Safari. That appears to have been fixed. Examples are hard to provide since they almost always get fixed but in the moment its enough pain to always get me to drop Firefox.
If it always getting fixed shortly after, it probably means something is going on in your settings or in the background that is interfering at the time you are trying to access them. Just my two cents. I know when I run proton vpn, little snitch, my various extensions, etc. one of them is always the culprit no matter what browser I use.
If it gets fixed quickly, it was probably an issue with the particular website or a plugin of yours rather than Firefox's issue. People are fast to "conclude" it must be Firefox. You should also test in a private tab with no plugins enabled. That might very well also fix the issue.
Google Images has problems with Firefox. If previewing several related pictures, the back button of the browser doesn't bring you back to the last image, but to somewhere else.
* Recording in web client of Duolingo does not work on Firefox, only in chrome.
* Webserial for flashing esp for example is not supported
* Webauth took forever to be supported (still not sure it's fully supported)
But I still use of because of the cookie Mgmt mainly, and secondly because we need at least one alternative browser engine on desktop... Safari WebKit is a fork (or the original if you prefer), it's not really that different.
I use Firefox as my daily driver. There are in fact some websites that don't work on it, but it is rarely anything mainstream. My example is the website 3M provides for doing medical code grouping. Probably less than 0.01% of the internet uses it, but it only works on Chrome and then just barely.
Honestly? No. If I do it's on the order of "once in a year", and usually only sites that are doing something specifically quirky, like particular types of webgpu demos or somesuch.
Oh interesting. I actually find custom docs sites (mermaid.js was the most recent one for me) seem to be the ones that break most commonly for me in Firefox but work in Chrome and Safari.
The only reason websites break on Firefox for me is that I break them myself with uBlock Origin and NoScript. >:D I'd rather have them broken than put up with their repugnant bullshit. The rare time I need a site to work pristinely for some reason, I begrudgingly pull out my (mostly) vanilla Chrome though.
I was recently introduced to the “lottery factor” as a less morbid alternative. As in, if one of us won the lottery tomorrow and quit on the spot what would happen.
I can kinda see the point there, but in the lottery example there's at least a possibility of making contact at a later date.
The bus is irreversible and sudden.
I'd say the lottery example works for example with skills/knowledge. ("Do we have someone else who can do what that person was doing?")
While the Bus factor is very relevant for issues like infrastructure and access ("The only person who knew the important passphrase or credentials is now lying dead on the pavement.)
The difference between the lottery factor and your bus factor makes a decent proxy for how much people like working there.
If someone has a lottery factor equal total their bus factor, then you expect them to say “screw you” when asked for help, and you should probably work on that.
Really? Maybe I'm in an A/B test but on mobile for me every page load pops up a dialog that says "this looks better in the app" and they only load a limited number of comments and gate the rest behind the app.
Apollo was by far the best reddit browsing experience on mobile and it seems like the API price was a direct action to shut these third party experiences down knowing their experience was sub par.
Are you using old.reddit.com by chance? If so I have a sneaking suspicious that's going to go away in due time.
At least to me, it seemed most intuitive to not have a global server environment and always copy the environment when starting a new session not just on server start and have the existing behavior when attaching to a session.
OP here. Apologies for not providing the real world example that triggered the behavior but here's some more background: We have some make tasks that set up a local dev environment and rely on environment variables to control a few things. We ran into an issue where if someone started another tmux session and then ran the make task to start the dev environment the env vars wouldn't be set correctly causing some confusing behavior.
Ultimately we decided to use a named tmux socket to ensure the environment variables were picked up correctly when set via the make task but you can also use `set-environment` as well if the ergonomics hit of having to use the named socket each time is too much. It's nice that tmux provides a few work arounds but I thought the original behavior was not intuitive.
If you thought you were reloading the dev environment database, and found out you just reloaded your production database, you would be surprised too. And you would probably wonder why after setting the dev variables, the tmux shell didn't have them.
It's one of those rare gotchas that will bite someone in the ass. And it will hurt. And when it does, you'll swear like a mother f'er.
OP here. We have some make tasks that set up a local dev environment and rely on environment variables to control a few things. We ran into an issue where if someone started another tmux session and then ran the make task to start the dev environment the env vars wouldn't be set correctly causing some confusing behavior.
I wouldn't rely on env variables. I'd make a script that goes somewhat like
script envname command
then just loads .env.envname before executing.
For k8s work I just put some relevant variables in PS1 so it is always visible "where I am", with prompt looking like this for say "dev" env:
[08:15:57] ^ [~]
k8s:dev -> ᛯ
As for tmux behaviour, it's honestly entirely understandable. tmux have no way of knowing the intent of the user; some people might want "clean" session with defaults of what server is running, other might want some env variables copied.
I don't have that problem because I just have session being created in my WM autostart, and I just use that one session 99.99% of the time. And creating new ones usually is from tmux, not from some random shell window elsewhere
Yeah that makes sense. To me it felt unintuitive that environment was global and only copied on server start, with a few exceptions, and not session start but that was likely just a failure in my mental model of how tmux worked.
I think it's about the stuff that needs to be shared. Like variables for X11 or ssh agent.
If you start server off your graphic session then any new tmux session will get those variables and your ssh agent or graphical app will "just work".
Reading from current one by default might fuck something up if you say have some automation that starts stuff in tmux
There isn't really good way to handle it by default that would make everyone happy, screen had similar "problems".
I just have
tmux new-session -d -s main
in my .Xsessionrc so the main session gets both SSH_AGENT stuff (I use gnupg as agent, for smartcard support) and proper DISPLAY, then just use alias to use that main session
Could you encapsulate the config to a file within your build step and set the env vars from that? Like a “remember to source <envfile> before make dev” or better, if the env isn’t set in make properly (flag), have make source it.
Environment vars are great with defaults for configuring codebases. They are designed for runtime. Build time flags can read the current environment but if your build pipeline requires custom variables you need a “dictionary” of sensible defaults that will spin up a local environment so that onboarding is as easy as git clone && make dev.
I wonder if it's because of export. If one puts an env var into a command alone then it should be OK. For example, `MY_VAR=1 my-commmand.sh` should leave env vars unchanged for everything else.
Yes that should work. In our case we have a few different windows/panes that all want the same environment so it made sense to reach for export as a way to ensure the environment was set but then ran into this quirk of tmux
You can use the include syntax for Makefiles in order to include your environment variables.
Alternately, set those vars in your shell RC and it'll work too when the shell is spawned.
IME it's stabler to kick off automation or build processes from a clean slate anyways, clearing the environment and setting specific values as required from a file.
I think the intent of OP was to help people get setup with Hugo so your comment is pretty off topic. Yes you could set up php, elm, a full lamp stack, rails, heck you dont even need nginx to serve a static .html file but none of that will help someone get setup with Hugo if that's what they want to use for static site generation.
It's sad there really isn't much you can do about it. I tried do-not-call lists, answering and telling them to stop calling me, reporting them - all was apparently a waste of time.