dashwav

I'm not even old (mid-20s), but I scale the site to 150%. HN is honestly one of the worst sites I have used with regards to default scaling across resolutions.

OTOH the simplicity of the site allows for very easy browser-based scaling, which means I only really think about how bad the text size is once per machine.

This seems to only really work in languages that allow null variables/timestamps. I wouldn't really want to have to do comparators to the default value of a timestamp.

I think that the biggest differentiator between Discord and the others (mumble, TS, Vent, etc) was that Discord has very mature text chatting as a first class citizen, rather than an afterthought. This is what I have anecdotally seen as the primary thing that has made even people who casually voice chat join public discord servers. The model is much more friendly to casual users than either TS or Mumble are.

To be fair, from a security standpoint if you want *the highest security* allowing third party installers is one of the first things I would disable as well.

I have a very hard time getting behind these complex configuration languages. To me what makes a configuration format good is the simplicity of reading the configuration of a program, and almost all of these languages are optimizing for feature complexity over readability. I think that all of the popular config formats (yaml, json, toml, etc) have issues, but none of the major issues with them have to do with being unable to represent a fibonacci sequence in their language.

To draw a direct comparison, when I look at the examples in the github repository, all I can think is "I would never want to have this be a source of truth in my codebase". While I get frustrated w/ whitespace in yaml and the difficulty of reading complex json configuration, if I need a way to programmatically load complex data I would almost always rather use those two as a base and write a 'config-loader' in the language that I am already using for my project (instead of introducing another syntax into the mix)

In my experience, I have seen much less of the OOP-only group, especially in recent years. The general feel I have seen when communicating with other developers about this is that OOP is a tool and it's probably not the best one, but they are comfortable with it and it's problems.

In general it feels like the overall feeling to FP is either

"I don't have time to learn a new paradigm when my current one is working good enough to make the company money"

or

"I love using FP ideas in my code when it makes sense"

I really feel like this is the ideal state for Software Development, as either side "winning" will only hurt the robustness of the environment.

I have to say I really appreciate this! I was going down very similar lines just last week (I had installed Hammerspoon and was experimenting with some applescript hacks, but to no avail).

Just intercepting the actual scroll and inverting it is a really elegant solution (that doesn't require a relog) which is great.

This solves one of the two biggest gripes I had about MacOs - with the other being my inablility to "pin" my dock to one of my monitors, overriding the swap functionality. Thanks!

I have been looking for a solution to this problem for a very long time and my reasoning is that on a trackpad, natural makes a lot of sense intuitively, since you are "pushing" the document (page/app/whatever) the direction you want it to move.

Whereas when I am using a mouse I feel like I the document is below the mouse more or less and when I move the scrollwheel it is physically moving the document as if it was tied to the scrollwheel.

Not sure if that makes any sense, as this is just some internal feelings on it, but I have beeen manually toggling the natural scroll when i plug and unplug my mouse ever since I started using MacOs

I think that is a very optimistic view of how things are currently - I think 80-90% of all business still operates in a similar organizational fashion as it did 20 years ago, and it is changing linearly at best, not exponential.

TBF with a completely greenfield project and managed K8s (GKE or EKS) you can absolutely get a pretty well set up infra very quickly if you are willing to learn how to do so.

I often get the feeling a lot of the negativity comes (rightfully so) from trying to replicate a current existing project into kubernetes. This is true of almost any paradigm - try replicating a Java EE monolith into Erlang and you are going to have a lot of problems. The big thing to note is that starting a project on Erlang very well might solve the problems that a Java EE project ran into, but that is because they were able to solve them at the ground floor, and just popping a Java EE project with all of it's architecture into an Erlang project will probably end up in a worse spot.

I think that this is what often happens with k8s as well - if you or your company have a currently working implementation that isn't on k8s, of course you won't be able to just easily plop it into a k8s cluster and everything be all well and good, but I think the problem is that people are equating that issue with k8s itself, which is a completely different paradigm.

As a counterpoint, buses/railways are imo 100% an essential service for cities and yet they were running empty during the COVID-19 lockdown where I live. I would hate to see them recategorized as non-essential because of a situation that is clearly completely abnormal.