hmm, that’s interesting, the islam practiced in pakistan is much more arabicized compared to the one practiced in indonesia which retains plenty of hindu-buddhist influence :cirno_think:

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> &gt;open<br />&gt;HDMI</p>

@koakuma@uwu.social ڤاݢي کاق، مريمري کيتا بربوکا دڠان لزات :neofox_nom_burger:

>puasa is a sanskrit loanword उपवास for “fasting” >commonly used to describe fasting in Ramadhan in Indonesia :cat_alien:

أستغفر الله ، کان ربا ايتو حرام کوق ماسيه اد ڤينجول :acat_gawk: here i can get why got ah long tho

<p>nixfmt, the winner of the <a href="https://types.pl/tags/Nix" class="mention hashtag" rel="tag">#<span>Nix</span></a> formatting RFC has a lot of holes &amp; annoyances even if it’s more resilient than nixpkgs-fmt.</p><p>/* comments */ are reformatted to # comments even when this style is supported by the language--&amp; especially since it’s used my tree-sitter to add syntax highlighting text blocks that otherwise wouldn’t have it (these comments are seen all over Nixpkgs). </p><p>You can no longer make a { foo, bar } one line as with 2 elements it gets broken out to many lines which can massively harm readability in many cases when you stretch *too* vertically. With attrsets as a common way to pass arguments &amp; those sets often being finite (not to be extended) it’s really strange to turn 1 line into 5 (newline happens after the function now too). This is inconsistent too, as it only happens if you are in a lambda, named functions you *can* have it be one line.</p><p>Inconsistently breaks lines after `name = func` where attrset open can let you put the function on the same line, but non-attrset open curly breaks to a new line.</p><p>It’s a bit harder to do, but I agree also with the expand-don’t-contract philosophy of formatting where you shouldn’t be pulling up elements after a newline the author made since it was likely done intentionally for their own readability or an understanding that a list or attrset will be expanded with elements in the future. This is the opposite problem of breaking all multi-element list/attrsets earlier.</p><p>And lastly, altho claimed out of scope on an RFC about styling, they should have moved to 3 or 4 space indentation. It’s too hard to read heavily-nested code with 2-space indentation &amp; Nix code with its attrsets will always look this way.</p><p>I submitted a patch to their Microsoft GitHub Git repository to removing the needless flake-utils dependency. I hope it goes thru since I think it’s irresponsible to add a dependency for a for loop which will be propagated down into user’s flake.locks--for a for loop. My patch to move .envrc to .envrc.example was denied even tho I think that is fundamentally the wrong way to use that file (should be personalized per machine)--&amp; sure enough, my concern was ignited trying to patch out flake-utils getting the big warning about direnv code I had to DECIDE NOW on while first cd-ing into a new project. It’s a pretty useless file that only has the words `use nix` in it which doesn’t warrant it being tracked but also now you can’t `use flake` without having changes in a tracked file BUT WHAT DO I KNOW 🤷</p><p>Some of these issues I can deal with even if not happy, but swapping comments out breaks workflows &amp; 2-space indentation (in a language that doesn’t support tabs) is a readability nightmare for me personally. When more kinks are ironed out, I will submit patched version to Nixpkgs with 4 space indentation as the default &amp; I wouldn’t be surprised if it didn’t become very popular. As for now, after 24 hours with nixfmt, I’m very unhappy with how much it breaks my flow (particularly /**/) &amp; I will be going back to nixpkgs-fmt for the time being.</p>

<p><span class="h-card" translate="no"><a href="https://infosec.exchange/@dymaxion" class="u-url mention">@<span>dymaxion</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@rst" class="u-url mention">@<span>rst</span></a></span> <span class="h-card" translate="no"><a href="https://infosec.exchange/@tinker" class="u-url mention">@<span>tinker</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@AndresFreundTec" class="u-url mention">@<span>AndresFreundTec</span></a></span> understandably, they are pushing against creating a liability relation with OSS maintainers and users in spirit of all those no guarantee clause</p><p>Those who are the supply chain of OSS are integrators and commercial entities reselling the software, c.f. CRA in EU</p>

@lain@lain.com you're actually an unsecured daylight creditor and will not get your daylight back during a default

Ordered a new mouse :blobcatangery: