• 0 Posts
  • 14 Comments
Joined 2 years ago
cake
Cake day: December 19th, 2024

help-circle
  • Nice, Blizzard has always had unofficial support for wine. I used to play WoW back in vanilla on Linux using Crossover (or whatever it was called back then.) Occasionally the battle.net launcher will get an update that borks it, but Blizzard has always been very quick to fix it. I play WoW, Diablo4, HOTS, and Hearthstone from Linux. With the recent influx of Linux adoption, maybe Blizzard will release a native Linux launcher. Have to see where things are in the next 5 years.



  • Naa, tar handles archives, it should know how to archive and unarchive really well. It shouldn’t know how to compress or un compress or sort it’s output by human readable file sizes. If you add the -z or -j, for example, to your tar command, tar will filter your archive through gunzip or bunzip prior to doing it’s job of un archiving all your files. If you use the -f flag, tar will spit out a list of files that were operated on. Adding a sort -h feature to tar would violate the unix philosophy.


  • Naa, it’s about the network affect. Sweeney said there would be no LInux EGL until there is enough demand. Even if the Linux EGL sucks, it’s still Engineering dollars being spent by Epic. Engineering dollars that would never have been spent on Linux unless the there was a requisite level of demand. Sweeney sees the writing on the wall. I’m sure there will be a lot of new to Linux gamers that come for the Linux EGL and eventually switch to Heroic.



  • I looked at the article, same as the reddit thread, probably written by the same person. ZSWAP is just not necessary. ZRAM works and doesn’t require disk space w/ 3:1 compression. If I was running out of swap, then yes, I would take a look at ZSWAP to improve my swap situation. It’s just not a thing with ZRAM, not for many years.

    I.E. for my use cases, ZSWAP is irrelevant.


  • You get more ram for very little slow down, that also, would rarely be the bottleneck. For the servers, ram is a constraint, and it’s all just selfhosting. I have a Raspberry Pi that I selfhost with, as well as a couple 10 dollar compute instances in the cloud. More ram is much better than the tiny slow down that might occur during compression or decompression. All my services are all still very snappy, even the mailserver. For my work, I bring up large docker sandboxes of services that I need running to test entire systems. In the past, I would just allocate 32GB to a swapfile. ZRam is way faster.



  • There is a lengthy thread on Reddit about the technical differences. Apparently Zswap will take advantage of the kernel eviction strategy for swap space. Apparently Zram doesn’t have that. To me that never made sense because, you create a Zram block device and then set that as your storage for swap space. Why would the kernel care, or know, that the swap space is backed by a Zram block device.

    I do use Zram for my cloud self hosting machines and my dev machine. On the cloud devices they have 1 or 2 GB of ram and on my dev machine I have 32GB of ram. And in both cases it definitely seems like there is swap eviction. I also set the vm.swappiness to 180. Prior to Zram I would set my machines’ swappiness to 10. Swapping is highly encouraged on my machine.





  • Because they took time to make something from scratch with ingredients. i.e. Cooking. linux ricing started with only Window Managers and occasionally you get someone that modifies a DE. These people start from scratch to build their perfect environment. They aren’t doing after market modifications. They literally pick the components they want and put it all together, write all the configs. Hence, Cooking.