• 2 Posts
  • 84 Comments
Joined 7 months ago
cake
Cake day: December 16th, 2024

help-circle


  • We could probably stand to have some organisation standards in repo roots, but I tend to agree that dotfiles aren’t the way to go there. The project root is similar to ~/.config and the like: When you’re there you should not be subjected to further hidden levels. Those config files are a significant part of the project.

    State files however, like all the stuff in .git, lockfiles and the like are generally¹ fine to hide away. Those are side effects of running other tools, not ordinary editable configuration. Same goes for cache—and both cache and runtime files should likely go in the ordinary XDG dirs rather than be something every project has to set up a gitignore for.

    If anything I’m more frustrated with the C projects that just plop every source file in the root directory.

    ¹ Just don’t make it too easy to sneak unexpected crap in there. We don’t need to make the next Jia Tan’s job easier.


  • Sun films have been available commercially for a long while. Choose how much sunlight you want reflected (generally more in bedrooms that you generally want dark and cool, less in rooms where you want a view), and either get a professional to apply or do it yourself—it just takes a bit of soap water and effort.

    Generally better to have the sun rejection happen on the outside of the window, so as little as possible energy gets absorbed.


  • I’ve very barely dipped my toes in dbus before, and the option to have something else is on its face attractive (not a fan of XML and the late 90s/early aughties style of oop), but JSON for a system interface?

    I mean, Kubernetes shows that yaml can work, but in this day and age I’d expect several options for serialisation, and for the default to be binary, not strings.

    String serialisations are primarily for humans IMO, either as readers or writers. As writers we want something with comments (and preferably no “find the missing }” game), so for that most of us would prefer something like TOML if the data is simple enough, and actually Yaml for complexity at the level of Kubernetes—JSON manages to be even more of a PITA at that level.

    But machine-to-machine? Protobuf, cap’n’proto, postcard, even CBOR should all be alternatives to examine




  • We’ve also recently introduced Coding Challenges to our site! These new challenges represent a new, fun way for developers to level up by tackling captivating puzzles and earning recognition for your skills and creativity. It’s a rewarding way to practice and expand your knowledge with the Stack Overflow community in a space that celebrates diverse and unique approaches.

    aka

    >pls provide training material for the LLMs for free :pray:

    lol. lmao, even





  • I’m generally an en_*.UTF-8 user (even tried en_DK.UTF-8 for a bit for a reason we’ll come back to), so I don’t have a complete picture of it and would have to go look at the documentation or source for that, but I’d expect

    • documentation
    • date formats: en_DK.UTF-8 should give you ISO8601-formatted dates, if I can’t have that I at least want DD/MM/YYYY; the US-american nonsense is just plain unacceptable
    • sorting: e.g. Norwegian will have …zæøå and expect aa to be sorted as å, the Swedes have …zåöä, the Germans …zäöü, the Turks will want ı and İ sorted and upper/lowercased correctly, and there are some options around how you deal with “foreign” letters and diacritics.
    • Probably more stuff relating to LC_* that I can’t think of off the top of my head

    but in any case, an ls -l output should be different depending on your locale, and in ways you likely don’t even think about as long as it looks normal.