• 0 Posts
  • 237 Comments
Joined 2 years ago
cake
Cake day: June 15th, 2023

help-circle
  • The actual paper presents the findings differently. To quote:

    Our results clearly indicate that the resolution limit of the eye is higher than broadly assumed in the industry

    They go on to use the iPhone 15 (461ppi) as an example, saying that at 35cm (1.15 feet) it has an effective “pixels per degree” of 65, compared to “individual values as high as 120 ppd” in their human perception measurements. You’d need the equivalent of an iPhone 15 at 850ppi to hit that, which would be a tiny bit over 2160p/UHD.

    Honestly, that seems reasonable to me. It matches my intuition and experience that for smartphones, 8K would be overkill, and 4K is a marginal but noticeable upgrade from 1440p.

    If you’re sitting the average 2.5 meters away from a 44-inch set, a simple Quad HD (QHD) display already packs more detail than your eye can possibly distinguish

    Three paragraphs in and they’ve moved the goalposts from HD (1080p) to 1440p. :/ Anyway, I agree that 2.5 meters is generally too far from a 44" 4K TV. At that distance you should think about stepping up a size or two. Especially if you’re a gamer. You don’t want to deal with tiny UI text.

    It’s also worth noting that for film, contrast is typically not that high, so the difference between resolutions will be less noticeable — if you are comparing videos with similar bitrates. If we’re talking about Netflix or YouTube or whatever, they compress the hell out of their streams, so you will definitely notice the difference if only by virtue of the different bitrates. You’d be much harder-pressed to spot the difference between a 1080p Bluray and a 4K Bluray, because 1080p Blurays already use a sufficiently high bitrate.










  • I actually did this a lot on classic Mac OS. Intentionally.

    The reason was that you could put a carriage return as the first character of a file, and it would sort above everything else by name while otherwise being invisible. You just had to copy the carriage return from a text editor and then paste it into the rename field in the Finder.

    Since OS X / macOS can still read classic Mac HFS+ volumes, you can indeed still have carriage returns in file names on modern Macs. I don’t think you can create them on modern macOS, though. At least not in the Finder or with common Terminal commands.






  • I use Koreader on Android (available on F-Droid or Google Play).

    It works. Configuring fonts is a bit confusing — every time I start a new book that uses custom fonts, I need to remind myself how to override it so it uses my prefs. But aside from that, it does what I need. Displaying text is not rocket science, after all.

    I used to like Librera, but I had to ditch it because its memory usage was out of control with very large files. Some of my epubs are hundreds of megabytes (insane, yes, but that’s reality) and Librera would lag for several seconds with every page turn. Android would kill it if I ever switched apps because it used so much memory. I had a great experience with it with “normal” ebooks though. It was just the big 'uns that caused issues.


  • That can’t be good. But I guess it was inevitable. It never seemed like Arc had a sustainable business model.

    It was obvious from the get-go that their ChatGPT integration was a money pit that would eventually need to be monetized, and…I just don’t see end users paying money for it. They’ve been giving it away for free hoping to get people hooked, I guess, but I know what the ChatGPT API costs and it’s never going to be viable. If they built a local-only backend then maybe. I mean, at least then they wouldn’t have costs that scale with usage.

    For Atlassian, though? Maybe. Their enterprise customers are already paying out the nose. Usage-based pricing is a much easier sell. And they’re entrenched deeply enough to enshittify successfully.




  • Yeah, that’s true for a subset of code. But for others, the hardest parts happen in the brain, not in the files. Writing readable code is very very important, especially when you are working with larger teams. Lots of people cut corners here and elsewhere in coding, though. Including, like, every startup I’ve ever seen.

    There’s a lot of gruntwork in coding, and LLMs are very good at the gruntwork. But coding is also an art and a science and they’re not good at that at high levels (same with visual art and “real” science; think of the code equivalent of seven deformed fingers).

    I don’t mean to hand-wave the problems away. I know that people are going to push the limits far beyond reason, and I know it’s going to lead to monumental fuckups. I know that because it’s been true for my entire career.


  • If I’m verifying anyway, why am I using the LLM?

    Validating output should be much easier than generating it yourself. P≠NP.

    This is especially true in contexts where the LLM provides citations. If the AI is good, then all you need to do is check the citations. (Most AI tools are shit, though; avoid any that can’t provide good, accurate citations when applicable.)

    Consider that all scientific papers go through peer review, and any decent-sized org will have regular code reviews as well.

    From the perspective of a senior software engineer, validating code that could very well be ruinously bad is nothing new. Validation and testing is required whether it was written by an LLM or some dude who spent two weeks at a coding “boot camp”.