u/Ok_Yogurtcloset8372

When the remote loses its responsiveness or the battery power is low, tapping on the remote with your hand will almost certainly bring it back to responsiveness.

What physical phenomenon takes place in the remote when this is done?

We're considering inheriting a system that was built and maintained by a large team, many many engineers over the course of a number of years. We have 10 members in our team.

Not that the codebase is going to be abandoned, but the original org is restructuring and we'd be taking responsibility for it going forward. I'm not certain management realizes that they have to take care to "just maintain" it, rather than understanding what it does.

100 developers equals 100 assumptions are baked into code. No one recorded the design decisions. Unspoken understanding of the rationale behind the way something was being done which was lost when those people were gone. With good docs (which to be honest, I don't think we have, at least not when we're writing them), there's still a huge divide between reading the code and understanding what it is doing.

I have seen teams take over smaller code bases and work for months, with no idea of what they are doing. This is a problem on a different order of magnitude. Millions of lines can't be grep'd and considered understood.

Every time you download an app and it requests access to your camera, contacts, location, etc., all you are asked is yes or no. Nothing explains why it really requires access to this particular permission to function. For example, does the app require location all the time or just at once when using a particular function? Does the app require access to contacts in order to use its features or it needs access to contacts only to "find your friends"?

It seems to be such an easy thing for apps to put one line to explain their request prior to asking for permission, but they do not do it. You either allow the app or deny its request and hope everything will work okay.

PID exhaustion is among those kinds of failures that surprise everyone since there doesn’t seem to be any issue with resources in such cases. Memory is okay, disk is okay, CPU is free, but for some reason the system is unable to fork processes and behaves unpredictably.

By default the maximum value of processes on Linux systems is 32768. Some processes that fork quickly enough will be able to reach that limit without getting anywhere near to the RAM limit, for example a runaway script, incorrectly configured job queue or fork bomb.

It is possible to view the current limit in /proc/sys/kernel/pid_max and increase the limit to 4194304 on 64 bit systems. Usually reaching the maximum number of processes is a sign of other misbehaviors rather than limit being too low.

The problem is that most operating systems place everything into the same library pool, resulting in the user-installed package conflicting with the core system requirement silently and without any problems until the time when the problem occurs.

Justification for such a choice is quite clear. There are NixOS and Guix that do this quite well. Instead, Flatpak takes care of that on the application level. However, there are some trade-offs associated with the strict separation, namely lack of common library advantages, more disk space required and duplicated dependencies at slightly different versions.

There is /usr and /usr/local convention for Linux, which is not enforced by anything. Windows has had to deal with DLL hell for many years already. macOS is the closest one with SIP.

Who hasn't heard about 404, 500, 401, 403? You hear these a lot. But this specification goes way beyond that and sometimes they only appear in some kind of cursed scenarios.

418 (I am a teapot) is often used as an inside joke but 508 (Loop Detected), 507 (Insufficient Storage) and 421 (Misdirected Request) are HTTP response codes that you won't ever run into until the servers you have set up behave in some unexpected way. One more example of such a code is 451 (Unavailable For Legal Reasons) which sounds like something made up until you receive a takedown request from the legal department and you have to implement it.

And finally, 431 (Request Header Fields Too Large) which is the code that you will come across only when the payload size of JWT tokens or cookies becomes too large.

There is nothing quite like working on a project where the repo has grown gigantic over time (much history, many binary files which probably could have been stored using LFS from day one). Cloning is taking forever and failing at times.

I am aware of the usual suspects: shallow cloning with –depth, git LFS for the large files, maybe even partial cloning with –filter=blob:none. Has anyone actually done any sort of post mortem cleanup on an existing huge repo, for example by rewriting the history to remove large files that existed long ago? Or is there no way around this other than accepting the reality and working with sparse checkout or shallow cloning from now on? The implications for CI, as a shallow cloning might be fine on my development machine.

Thinks that everyone is trying to bring their rankings up on google but not really providing better products. You find it everywhere; sites with keyword filling, content created to address imagined or feel such as search intent, and whole pages planned for the algorithm's requirements rather than the user's requirements. While the service itself and the product behind it are nothing special.

Not saying that SEO isn't important, it is important if nobody finds you, but none of the other things are. Companies are optimizing for visibility, first and foremost and in some cases, quality is not in at all if the game of SEO is up and running.

I know, that a lot of them have premium versions with more features but that wouldn't be the only way to make a buck, right? I wonder how they are actually making this sustainable, especially the larger guys that run on thousands of servers. The costs for these servers have to compound quickly based on the number of bots that they are running and also if they are handling a lot of traffic or otherwise.

Are the majority of these on donated servers and a small number of premium tiers or do there more profound aspects that I'm not seeing? Things should be happening if it's a scene behind the scenes though.

There have been instances of large corporations and MNCs simply forgetting to renew their domain, until it expires and some genius snaps it up and has a page up that says, "Pay me X amount and you can retrieve your domain. Sounds like it is more common than usual for companies of that size.

Does domain parking really violate the law anywhere besides being tolerated because no one cares to go after an individual domain owner? And, does this whole "buy the expired domain and sit on it for ransom" thing actually constitute legal practice as well or does it tip into cybersquatting?

Seen in the GitHub Octoverse report for 2025 - they present this every year and it's usually a great resource to keep in mind when looking at actual usage trends rather than survey data stuff.

This is also what I see in the field on an ad hoc basis. Seems like pretty much every JS code base I stumble across these days are already on TS or are in the middle of a transition to TS. Contains even smaller personal projects that previously were only plain JS and are beginning to be done in TS instead of being clung to types at the end of the day. Like it was "nice to have", instead of, kind of wild, the only 5 years ago TS was ranked at like 7th place on GitHub...

After I got on the wifi calling for a couple years now, with average bandwidth where I live, I'm leaning towards whether it really sounds better than a cell call or not because all the bars look full now and I'm imagining that.

It's sometimes easy to see, particularly in the home where the regular service is weak at 1 bar. At times its similar experience or there's a funny delay/lag while communicating as it was in a VoIP call. Does that have something to do with the router, ISP thing or is there any explanation for WIFI calling as a whole?

Noticed that Spotify increased their price twice this year, and there were really no exodus happenings. It makes sense when considering the "why". It's not that people want to pay more, it's that the switching costs are more than the subscription. Your years of built playlists, saved albums, listening history; it all goes into the recommendation.

It will take a long time to rebuild all that somewhere else, and being forced to pay this price increase sounds so arduous that people will just eat it.

Whenever I hear the words "just a quick fix" or "we'll fix this up in the future" something jumps my nerves. Out of all the code bases that I've ever worked on, more often than not everything has a bit of code you had to work with that was supposed to be temporary, but, "Of course, it still works, why change it?Out of all the code bases I've worked in, more than half the time, you have to work with some bit of hacky code you put years back, "Of course, that works, don't break the code?

The gruesome thing about the hacking isn't even why you want to hack, it's because nothing comes with an actual "temporary" deadline. No showdown, no reminder, no part crippling anybody to look at it again. So it lies there, until it is load bearing, and anyone shy to its presence.