cobar

For some reason, Okular doesn't render tables with any kind of borders. Not sure what else it's missing, but that alone has made me it a poor solution as a viewer. So I end up loading the files on the command line or in zed, which is sort of the author's point.

Break down the changes into smaller units. I try to create discrete units that can exist independently from each other and then limit PRs to only one module or subsystem. The sequence of PRs ends up being something like requirements, API docs for the module, tests, implementation per module, integration between modules. This limits the size of any fix and reduces the churn.

Ahh, ^H brings back memories. We had Solaris x86 machines in the computer lab at UC Santa Barbara when I was there from 97 to 02. They were deathly slow never mind that CDE was miserable too. I made it slightly less painful by loading the BSD versions of the utilities and using those. Pretty much gave up and ran FreeBSD on the desktop with Window Maker.

Sun got by because they had faster and more reliable hardware than what was available in the x86 space at the time. eBay's services ran on a handful of 64 CPU Starfire servers. And proprietary UNIX workstations had a bunch of specialized apps that weren't available on Linux at that point.

Front page of Hacker News seems like a good bucket list item. And not a bad thing to have on your resume either.

If you have an extra NVME slot you could look at picking up an Optane 800P drive. Extremely low latency reads and writes, which makes it ideal for swap. They're available for ~$100 on eBay.

Same problem I've had. On a 24GB MacBook Air, I can have a VMWare VM, Lima and an IDE and a bunch of Chrome tabs loaded and the system is fluid.

Meanwhile if I try something similar on a 32GB Linux system, it will sputter or outright freeze. Suspend the system at 16GB used and on wakeup it takes 15 seconds to get back to full responsiveness.

Yes, some of this can be addressed with swappiness settings, however that behavior isn't partically clear and doesn't take into account that depending on your workflow on a given day (e.g. coding then video editing) different swap behaviors may be more optimal. Nor does it help for people who are trying to get good productivity out of a 16GB or lower system.

The one thing that has helped is moving to Brave Origin. Whether that's loading less JS ad SDKs or general optimization, it does seem to use a lot less ram than Edge/Chrome.

Overall experience is very good with AMD graphics. Most games run on Steam out of the box. There are also emulators for all the systems I've wanted to use. I use Faugus Launcher for other stores like BattleNet and Epic Games (Magic Arena).

For the most part the games just work, it's more system issues that I've run into where Linux suspend mode and the audio stack can be a little flaky and required Claude to diagnose and sort out.

I've had better luck since the switch to Wayland. I don't play many FPS games but mouse input & overall smoothness for strategy games has been great. Check your mouse settings, you might need to set a higher USB sample rate. Piper is a frontend for adjusting them.

While product often does operate in a waterfall model, I think this is the wrong mindset. Good product management should adopt a lot of the same principles as software development. Form a testable hypothesis, work to get it into production and begin gathering data, then based on your findings determine what the next steps are and whether to adjust the implementation, consider the problem solved or try a different approach.

It's possible to map the Caps Lock key to Escape as long as you don't need Caps Lock functionality.

My bad, I had misread the comment the poster made and didn't see that the quote was there. I stand corrected.

There is a certain cost in time and energy required to separate yourself from harsh statements like that identify it as such. While it's pretty easy to say, yes he's not suggesting physical abuse, the statement implies this guy is not going to cut me any slack, I can expect to get verbally attacked for missing something in my code, etc.

Bad code has a cost associated with it as well, it takes time to reject it, explain why it's wrong, and deal with the frustration of someone less experienced. Unfortunately with some developers they want to push that off on the person writing the code and bear none of the burden.

I've seen the costs of the latter in open source projects I've worked on. People who feel encouraged stick around, support the community, and when given good feedback will often learn from it and submit better patches. Taking the time to communicate and make sure everyone feels included is part of the cost to get that.

I can relate to this as I'm quite sensitive and when I was younger had an incredibly hot fuse, largely related to being socially awkward, getting teased in school, and not knowing how to deal with it. That carried on into the work environment and left me adversarial and feeling isolated.

For me the problematic dynamic came from having things upset me and build up until I would get so angry it would explode outward. I grew up learning to hold it in, so I had no idea I could talk about problems with people. It wasn't so much letting go of the anger as talking about feelings and difficulties with people allowed me to avoid hitting that breaking point and over time, the anger and resentment has faded. Additionally, those conversations led to a level of trust where I feel like I can reach out to the person when something comes up or even strongly supported by them.

Coming from alcoholic parents, you might want to check out Al Anon. I found that and Codependents Anonymous invaluable as places where I was surrounded by people struggling with many of the same social issues I did. Also, it was unique in that it's an environment where talking about these sort of things is encouraged and invited, in public I tend to find that people find these topics uncomfortable and unwelcome.

They should be pretty minor. I've found that it's rare you need to rely on any of the Electron APIs. For the most part, Electron just provides a shell to load HTML/JS/CSS and that's where the overwhelming majority of the code lives.

The only time you need to access Electron APIs is to create and manage windows, system menus, etc.

For all the hate against it, we've been very happy with Electron. There's no way we'd have been able to afford to offer Windows and OS X given our limited budget without it.

They actually ported JavascriptCore over to Android. The only time it uses V8 is if you run the code through the Chrome Debugger. Not sure what the benefit was perhaps performance or lower disk usage.

Development time is a lot quicker with RN. Not only are you targeting a single code base instead of maintaining two apps, but the React environment helps you to be productive.

The React way of managing views makes a lot of sense - change a variable and the whole UI updates accordingly. Also, rather than going through the typical debug, modify code, recompile cycle, there is a Hot Reload mode in RN where your code updates are immediately applied when you save. Laying the UI out with RN's CSS-style syntax is a lot easier than doing it by hand or mucking with Interface Builder / Android XML files. There is a lot that RN wraps around that gives easier management of than the native approach to, e.g. a BackButton component vs. dealing with a stack of Android fragments.

I haven't done any PhoneGap programming, the lack of native UI always scared me off. Without that, I never felt like I could hit a level of polish that was acceptable. The nice thing with RN is you can build you own native components and access native functionality as needed. It's not super well documented, but powerful when you need it.