Default avatar
YsYe7Rg5O$JeULRiNnJehvlYjlGrxX5xY_tQgpe5NsP9
npub18eyn...cvu7
Given the upcoming Nixpkgs branch-off in November, I'd like to get some reviews for my Bisq PR: That way, perhaps the next NixOS stable release will contain the latest version of Bisq. I found an easy way to run the code in the PR: nix run github:emmanuelrosa/nixpkgs/5aeffc48db71fac1f3e7f379bea09e3353108c22#bisq-desktop #nix #nixos
I've tried multiple relays, yet for some reason I can't follow npub1jrakh9s8hwjqdph7wz4dwjs8ukhed52jw78n5z0umfvk0h9sm2aqsa2wha on Gossip. If you happen to see a note from npub1jrakh9s8hwjqdph7wz4dwjs8ukhed52jw78n5z0umfvk0h9sm2aqsa2wha, please forward it to me. Maybe that will work.
Bisq v1.9.14 was released today: However, I don't have a working updated Nix package. Upstream changed the way Bisq is packaged, which requires updates to the Nix package to get it to work. Basically, instead of putting everything in a "fat jar", each jar is provided seperately. That's fine, I can deal with that. But I spent numerous hours trying to get it to work, but ultimately I failed. This exhausted my patience, so it's going to be a while before I can update the Nix package. #nix #nixos
Since the github repo for OBW (Open Bitcoin Wallet) is now read-only, I'm assuming it's no longer going to be developed. How long will the back-end services which support the wallet remain available? #zebedee
Here's my OS history: Windows 95/98 -> Mandrake Linux -> FreeBSD -> Gentoo Linux -> NixOS. What's yours? I had Gentoo the longest; About 12 years, and I only had to reinstall it once because somehow... this is embarassing... I did `rm -fR /` Yeah, I did that as root.
I just migrated my NixOS system from BTRFS to XFS. I've got all my services up and running and I'm already seeing improvements: - Reduced memory consuption. - Reduced file fragmentation; The Gossip client LMDB database went from +6,000 extents down to 2. - Reduced CPU usage. My CPU fan actually turned off for a while :) It turned back on when I launched Gossip, LOL! I think my laptop is much happier now. #nix #nixos #xfs
nix run github:emmanuelrosa/erosanix#winerun-wine64 /path/to/app-x64.exe That's all it should take to execute a Wine-compatible (64-bit) Windows application. winerun is built on mkWindowsApp (in the same Git repo) which takes care of "installing" Wine and creating an ephemeral WINEPREFIX. Not to mention that a prestine WINEPREFIX is shared by multiple apps of the same Wine architecture, thanks to unionfs; This saves on disk space and startup time. In addition, the WINEPREFIX never goes stale since it's always recreated when Wine is updated. See and #nix #nixos
The more I play with XFS on Linux (yes, I ment XFS, not ZFS), the more I like it! I've been using BTRFS for about 5 years. It's been stable for me that whole time, except for that one time that my BTRFS backup drive got corrupted ;) But the thing I can't ignore any longer is the horrible file fragmentation due to how BTRFS handles "COW." I'll give you an example, if I were to run a sqlite script to create and populate a database, and said database is on BTRFS, even with a database < 1MB the .sqlite file would get so fragmented that the sqlite process will never finish creating the database. sqlite works OK on BTRFS in other use cases, such as for web browser bookmarks and browser history. It even works OK with Gossip. But a VM image (ex. qcow2)... forget it! A brand new Gossip LMBD database... 6,000 extents. Yeah, it's a problem. Let's compare that with XFS. I created an Alpine Linux VM with the qcow2 file on XFS. After installation the qcow2 file had... I think it was less than 100 extents. I then copied the image with "reflink" to trigger XFS's "COW." I booted the copied image, which shared extents with the original, and installed xfce4 and a web browser. The number of extents on the new qcow2 file went up to about 150 extends. I kept making changes to the disk image and got it up to about 500 extents. If this were BTRFS, I bet that file would have 10,000+ extends. I booted the original qcow2 image and it was in the expected state; Without any of the changes I made. I then removed the original qcow2 file, which meant there were no longer any shared extends between the two. Then out of curiosity I defragged the file and got it down to 15 extents (from about 500). I also tested a reflink copy of a directory structure to see how well XFS can create sometime like BTRFS subvolumes; I use this feature to create a snapshot of my files and then back them up. The XFS reflink copy worked just like I expected; The extents are shared and if a change is made then new extends are created, leaving the original file intact. It cannot create a read-only snapshot like BTRFS can, but I'm willing to accept that trade off for the better file allocation performance. I'm going to test XFS some more on a real-life, non-critical filesystem to see if I find any issues. If not, I plan to migrate from BTRFS to XFS.
I'm considering a NVME M.2 USB enclosure for a "retired" NVME SSD. Once issue that I became aware of is that the enclosure needs to consider the heat generated by NVME SSDs; It's not merely a larger flash drive. Are there any other considerations?
Goodness, the shitcoins! They're swarming Nostr like cockaroaches. And I don't even look at "Global." I bet they'll reply to this note with their amazin' airdrop deals. At least the block/mute button works well, though :)
Years ago I played around with the Squeak, Pharo, and Amber Smalltalk implementations. I loved them. The ability to develop applications while they were running was a game-changer. I was blown away by being able to inspect the call-stack during an exception, modify the values in the stack, and then rewind the stack to see if my idea for a fix would work. But... I concluded that no client would allow me to write their application in Smalltalk. So I walked away from Smalltalk. Nowadays, I only write code for myself, as I used to do prior to working as a programmer. Therefore, I'm revisiting Smalltalk :)