• 0 Posts
  • 25 Comments
Joined 9 months ago
cake
Cake day: October 4th, 2023

help-circle







  • Considering that reading source code can take a long time

    You’ll get faster over time, until reading code is faster than reading documentation, as code will always represent what’s truly happening, while docs are frequently outdated.

    In a language the user isn’t familiar with

    If you’re not that familiar with the language, it’s likely you won’t be contributing to the project. Open source projects usually to have quite limited resources, so they tend to optimize docs and dev UX for people who are likely to contribute.



  • I’m a software dev as well.

    But I often layer multiple windows in the same tile of the screen. e.g. I may have the IDE with the software I’m working on in one tile, the IDE with the library source code I’m working with in the second tile, and a live build of the app in the third tile. But I’ve also got documentation, as a website, in the same tile as the IDE with the lib’s source.

    Now when I switch between the IDE with the lib’s source, and the browser with the lib’s documentation, I only want that tile to change. No problem, with KDEs taskbar and window switcher I can quickly do that.

    But when using the applications menu on Gnome I get a disrupting UI across all screens that immediately rips me out of whatever I was doing.




  • Unless you’re writing ruby on rails on a 13" macbook, you’ll run into Gnome’s limitations when working.

    Gnome is in many ways so focused that it makes a lot of productivity use impossible. You always have to open the menu to launch software, you’ve got no system tray, and worst of all, Gnome apps are so simplified that you constantly run into the limitations when using it productively.

    When working with dozens of windows open at the same time across multiple monitors, I’m a fan of KDE. And KDE apps tend to also have all the extra features I need to handle weird situations, files, and edge cases.




  • If you’ve got 14 billion years, a theft takes a minute, then you need 53 recursion levels of binary search to find the moment of the theft. (14 billion years can be split into about 7.3e15 1-minute segments, 53 levels of binary search allow you to search through 9e15 segments)

    That means OP assumed that it’d take 1 minute to decide whether at a certain still frame the theft had already occured or not, to compute the new offset to seek to, and the time it’d take to actually seek the tape to that point.

    Not an unreasonable assumption, but a very conservative estimate. Assuming the footage is on an HDD and you’ve got an automated system for binary search, I’d actually assume it’d take 5 seconds for each step, meaning finding a 1min theft on 14 billion years of footage would take 5 minutes.