Unfortunately, these are very clinician-focused and are very hard to understand without a medical background. They also don't usually cover experimental treatments that are still in trials, but in some cases can be extremely helpful. I work on an app at Outcomes4Me (https://outcomes4me.com/) that is trying to convert the NCI guidelines into an algorithm so that we can tell patients in simpler terms what their treatment options are based on their specific diagnosis. We also try to find clinical trials recruiting for their specific diagnosis. We've done this for breast and lung cancer so far.
That is if you consume too much. Anything is poisonous in great enough quantities, including water. I'm assuming OP is asking about whether it's dangerous in normal dosages.
No one has mentioned ShareMouse yet? (https://www.sharemouse.com/) In my experience it has worked way better than Synergy. I switched after getting fed up with the synergy developers not responding to various multi-year old bugs that made the software unworkable for me (e.g. https://github.com/symless/synergy-core/issues/5992).
The only downside is that you have to "renew maintenance" to continue receiving updates to ShareMouse after a year. But I haven't done that yet and it still works fine for me.
How are we sure that pulsars are 100% consistent? How do we know the timing discrepancies are due to gravitational waves and not just tiny wobbles in the pulsar itself?
It really sucks when you are the only one on your team that knows Rust. I whole-heartedly think that I'd be more productive and write better backend code in Rust than JavaScript/TypeScript/Python/Ruby from my experiences of using Rust in side-projects. But I have to suffer because I cannot make the case of rewriting our backend and teaching all the devs Rust.
So my only choice if I want to use Rust is to leave the company, but it's really hard to find other companies that primarily use Rust. The majority of the ones that do are crypto/blockchain related or doing something extremely low-level or out of my wheelhouse since they assume you're also comfortable with writing C++. I'm primarily a web developer and I hardly see any web startups choosing Rust.
We need to do that movie thing where two people switch places and pretend to be each other, that way we swap jobs. Cause where I work, we write web backends in C++ purely because people there want to use a "real language." Not only do I hate it, but they have a hard time hiring people cause all those kinds of candidates want to do lower-level stuff.
The speed of rust out of the box is insane. I sped up one python endpoint by a factor of 100x with Rust (not 100%, 10,000%). If you can get 1 endpoint that is causing performance issues to be written in Rust, it may be the skinny end of the wedge. You obviously shouldn't sneak that in, but if you get buy-in, then it may start the process.
You can run vim and emacs in a gui app. I run neovim in neovide which imo is the best experience for vim these days. Vim's builtin terminal is good enough now that you can ditch running it inside tmux/terminal.
They're all terminal apps so I'm not sure why platform conventions would matter. Sure some people use GUI wrappers but most people primarily use them in terminals which have the same conventions everywhere, generally speaking.
Platform conventions matter because uniformity matters. It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. That is terrible usability, consumes brain cycles for no good reason, and is above all else completely unnecessary because modern alternatives exist that actually blend in with the system they're a part of.
> Platform conventions matter because uniformity matters.
There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working.
> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.
I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system.
I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time.
Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do.
I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.
This isn't even true on virtually any macOS terminal, which use Command-C (just like a web browser). The problem isn't the terminal, it is the operating system.
> Platform conventions matter because uniformity matters
Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.
If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).
If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.
That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.
You mean like yy versus ctrl+c? You can definitely use a Vim browser/OS extension but Vim does it that way because the creator, I suppose, perceived that his user interface is better than what's already there. And I tend to agree. I don't need uniformity if it'll be inefficient.
I have C-f mapped to Find and C-v mapped to Paste on vim. It’s trivial to do (one line per mapping) but yes I would be considered an heretic by some vim purists. They tend to go the other way around, using plugins to make their browser behave like Vim. Which makes more sense than it might seem; if you spend a lot of time on the command line vim bindings are better supported than ctrl c ctrlv
> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.
M-x cua-mode resolves this in Emacs. I don't use it, because I've been using Emacs for slightly longer than the CUA has existed.
If you have a Garmin, you actually have a lot of the features Strava offers through Garmin's free service. I don't think you even need a Garmin device to use it if you upload your data manually.
Maybe serious athletes and socialites rely on some specific Strava only functionality, but I find the Garmin service has pretty much completely replaced Strava in my own usage.
Except the middle man can actually serve a purpose here. I would actually like someone to distill highly academic articles full of technical jargon into layman's terms that I can skim in a few minutes. The fact they don't link the original paper is just bad journalism.
It's also bad journalism when newspapers frequently misunderstand the original source completely or sensationalize one piece of the source completely out of context for extra clicks. But, there's not much we can do about that.
Why use something slower when an equivalent faster tool is available?
There's definitely a noticeable delay on my machine with starting up the python interpreter. Enough that it dominates most actual request times to fast servers. (`http get www.google.com` is ~460ms while `ht get www.google.com` is ~130ms)
For a tool I'm constantly using to check APIs I'm developing, I really appreciate snappy commands that give me results that feel instantaneous.
Unfortunately, these are very clinician-focused and are very hard to understand without a medical background. They also don't usually cover experimental treatments that are still in trials, but in some cases can be extremely helpful. I work on an app at Outcomes4Me (https://outcomes4me.com/) that is trying to convert the NCI guidelines into an algorithm so that we can tell patients in simpler terms what their treatment options are based on their specific diagnosis. We also try to find clinical trials recruiting for their specific diagnosis. We've done this for breast and lung cancer so far.