I also do a lot of web stuff, and if you're running some server process and you're not running the server process through a debugger directly, then you need to find and attach to the server PID, etc., then maybe deal with threads, and it's just a lot of upfront effort when I could just find the issue by throwing a puts/print somewhere or writing a test.
I'm not anti-debugger, I'm just busy and it's easier to put something in my code (which is how I frequently jump into debuggers too, e.g. binding.irb, binding.pry, debugger, byebug, etc.)
the CLI debuggers (gdb, lldb, etc.) are great when I really need them, but they're a pain in the ass to setup with things that are not C or C++, editor integrations sometimes need setup, and using them without setting breakpoints visually is tedious.
I write a lot of code outside of work. I have some sort of compulsion to do so, and have numerous passion & open source projects I work on. They pretty much all scratch some sort of itch for me personally (either creative or mentally). This keeps me motivated because they're all stuff _I_ want to do and mostly not things I feel like someone else wants me to do or I'm making myself do. I don't worry about going months between touching some of them. Some weeks, I don't feel like touching any of them and will spend most or all of my free time on other stuff.
https://chrome.google.com/webstore/detail/rss-feed-reader/pn...
IMO the big thing that killed RSS ubiquity was Google Chrome not having support for it natively. Before that, Firefox, Opera, Safari all had RSS as well-supported, central thing and I remember finding it super annoying that Chrome didn't have it when it launched. But I kept using Chrome for the same reasons everyone else started switching to Chrome. And the RSS extensions all sucked. And eventually I stopped using them. And here I am, no longer reading RSS.
But as Chrome ate up browser share, I'm sure fewer people went to RSS because it wasn't natively there and so the incentives to implement RSS decreased as fewer people expected it to be there, especially as many more people were coming online only having used Chrome.
Oddly enough, I switched back to Firefox years ago and _could_ get back into RSS at any point (or with any number of RSS reader apps, etc.), but the habit has stuck, and I now stay up-to-date on everything via email newsletters, Twitter and this orange website instead. it's worse and I hate it, but oh well
There's lots of _better_ healthcare software out there. It's still complex, while remaining fairly user-friendly, but it tends to live inside healthcare startups and healthcare tech, and not deployed as broadly as the big EMRs like Epic, Cerner, eClinicalWorks, etc. These established players tend to be the only ones with the feature sets that big hospitals and health systems want/need.
Aside:
A lot of people in this thread are complaining about "regulations" making things difficult, but HIPAA, HITRUST, Meaningful Use/Promoting Interoperability, SCRIPT, etc. are not _why_ EMRs suck. They make it harder to start from scratch, but they do not prevent you from building easy-to-use software. The software sucks because there's generally no incentive to make it not suck and a whole lot of legacy suckage with a lot of momentum, money, and influence.
1. battery life on laptops. Linux tends not to Power Management well on most laptops. Whether this is a hardware/ACPI thing, a device driver thing, or an overall ecosystem thing, I'm not sure. But it's noticeably worse than when running Windows or macOS.
2. as others have no doubt mentioned, trackpad. Apple's trackpad hardware and macOS's trackpad gesture support is so good, it's really hard to not have it. I can emulate some of it on my XPS 13 running Ubuntu w/ some additional agent thing that runs in the background, but it's only 85% there and not as smooth an experience.
3. desktop environment stability & consistency. this is _much_ less a problem than it was say 10 or 15 years ago as GNOME has gotten quite good and Flatpak/Snap/etc. are decent at containing various GUIs and their disparate dependencies, but there's still a lack of good integration with DEs across ecosystem tools generally. But also Electron has also sort of leveled the playing field a bit, so many desktop apps behave the same across platforms (for better or worse)
I would've said slow package/kernel updates, but there are enough solutions to this now, that it's not as much of a problem (Ubuntu HWE, Nix, Linuxbrew, or using ArchLinux)