" itemprop="description"/>

JSE's Blog

Jonah's blog is here


Topics that don't need a category, or don't fit into any other existing category.

So someday I'd like to write more about NTFS and Linux support of the Microsoft designed file system overall, however too much to do now -- like redesign this blog, so perhaps I'll do this some other day.

What I wanted to write about today is simply a quick tweak I do on many linux distros that helps improve NTFS performance, and make mounting filesystems instant like windows. This makes, for example, having multiple disks easy to work with without having to muck around with /etc/fstab if you have a disk you want to work out of instantly upon boot without having to manually mount them -- something I occasionally do.

Anyhow, to do this, I use a daemon called "udevil" (a play on udev). "udevil" will automatically mount filesystems as soon as they're connected, and it has the added bonus of you being able to specify which mount options you want as well.

Because one thing you might realise about NTFS support (using ntfs-3g, the FUSE ntfs driver that pretty much every distro currently uses) is it is crazy slow. Thankfully, there is a mount option called "big_writes" which you can apply to NTFS-3G which speeds up write operations. There's discussions on the internet about what this does but the tl;dr of it is: 1. It makes NTFS write operations faster on linux 2. It's safe to use (so why isn't it default!?!?)

Now of course, you can always just mount ntfs manually with big_writes and not use udevil. In my cause this isn't convenient so the rest of this post is about automating this task.

So first, install udevil on your distro: Debian/Ubuntu: sudo apt install udevil Arch/Manjaro: sudo pacman -Syu udevil

Next, go to /etc/udevil and edit the file udevil.conf

Scroll down to the "default_options" section and find the line default_options_ntfs. You will see a number of options there which udevil will use when it automounts ntfs drives, with each option separated by a comma. At the end of the line, add the option big_writes after a comma.

Next, scroll down a bit more and you'll see allowed_options. Add big_writes to allowed_options as well. You will likely notice there is no allowed_options_ntfs section on most distros. You are free to add this if you like, however there is no harm in my opinion to just add it to allowed_options.

Save and exit the file.

Now, I'm going to presume you use systemd. You must enable a service called "devmon" to make everything work. Devmon requires a username specified, in my cause, my user on my system is jse, so simply running: sudo systemctl enable [email protected] Will enable the service.

To avoid rebooting and use devmon now, you can then run sudo systemctl start [email protected]

And of course, if you change the config, go ahead and restart the service. Don't forget if you misconfigure it (such as forget to add the mount option to allowed_options which is what I initially did lol), log files are your saviour ;)

Hope this helps. Enjoy the automounting and better NTFS performance! :)

So a while back I posted this video on getting osu! working on linux. It was incredibly low effort (like so low effort I cringe just watching it) so I thought it was hilarious it even has gained the views it has, but whatever. There has always been numerous guides on the internet regarding osu! Linux support, but I've found the best, tried and true method for getting it to just work is to use the Lutris installer. It's not perfect, but it doesn't require any of the tedious tinkering many of the other guides suggest.

Now thankfully, osu!lazer is becoming more and more feature complete as the days go by, so soon we will see it eventually support online play, which has full Linux support, but in the mean time wine is where it's at.

Wine is to the point that, with the easy tweak scripts provided by Lutris, the ability to run osu! (and many other Windows only games) on Linux is pretty much flawless. Even the bugs I encountered in the video I made don't seem to happen anymore, at least for me, so it seems things have improved even in the last year or so.

One thing that has changed though is Discord-RPC. You might notice, if you check the Lutris install script, that it fetches a discord-rpc.dll to override the one osu! (used to) provide. Why?

Well the reason goes back to the differences in Windows vs Linux IPC (Inter-process communication). Discord RPC on Linux uses UNIX sockets for games to communicate with the discord client, but not for Windows of course. The modified discord-rpc.dll file was designed to translate the Windows Named pipe (how discord and games communicate on wind0ws) to something Linux can understand, and thus worked with the Linux client. Unfortunately, due to some changes, discord-rpc.dll is no longer in use by osu! it seems, so the file gets instantly deleted from the install, regardless if you copy the modified dll or dll that was originally included discord-rpc.dll file.

Anyhow, back to wine. Since wine implements Windows functionality, including named pipes, I wondered why can't we just get the Windows version of Discord working. This actually worked, to my surprise, as I know Chromium (which Discord uses in the background) has traditionally not played well with Wine. Seems wine has improved immensely in that regard.

The new ("easy") solution I use now for getting Discord RPC working with osu! on linux is to merely run Discord's windows client itself on the same wine prefix as osu! is running on.

What's a wine prefix? Think of it like a "virtual" install of Windows, only, it's wine. Given how wine is finnicky at best sometimes, the general practice is to install each application, or game, in a unique prefix. This is because depending on the app, sometimes an app requires dependencies that are incompatible with another app. This isn't always because the app itself would behave this way in Windows, but because some libraries may not work for wine unless it's appearing as a different version of windows.

Anyhow, we can't follow the general "each app in it's own prefix" philosophy in this case, since each instance of wine cannot communicate with each other. Instead, you need discord to run in the same prefix as osu!

Thankfully, it appears Discord will generally install nicely on wine of any recent version. You do seem to need .net installed for it to work, but after that the installer, and client will load up correctly. osu! requires .net anyway (lutris installs 4.5.2) so since we're going to be installing discord in the same prefix, we don't need to worry about any winetricks.

There are a couple key changes you will need to make in winecfg first however. First, you need to change Wine's windows version from "Windows 2003" to "Windows 7". In case you're wondering why it's Windows 2003 to begin with: Lutris calls on winetricks to install .net 4.5.2 (as is necessary). Part of this "winetrick" is to set the Windows version to Windows 2003 to work around some bugs that it would otherwise encounter. Now, I'm not certain if those bugs are just related to installing .net itself, or with certain functions that are incompatible otherwise in .net (perhaps there are bug reports on winehq or with winetricks that discuss this), but I've not encounted any bugs doing this regarding discord + osu!

I did, however, try setting it to Windows 10 as well, but setting this causes super amounts of lag to the osu! client when you attempt to search your beatmaps, so if you feel Windows 10 might be a better choice, I advise you don't. Still, your milage may vary. Consider yourself warned if you decide to play with this.

Next, and this is important otherwise the discord client would eat my mouse due to this bug, you need to disable your Window manager from decorating Wine Windows, which is on the graphics tab of winecfg.

Once you've made these two tweaks, installing and using discord seems to work fine, and as long as osu! is running after you've opened the windows version of Discord, RPC will work. If this is all you're after then problem solved! Enjoy your discord RPC integration in osu!. Just remember to launch discord in the same prefix before osu! to get RPC integration.

Okay now for some additional ramblings not really related to Discord RPC + osu! on Linux.

You may now find yourself being tempted to switch to the Windows discord client and dumping the linux client. It appears to work at first glance, right? So why have a notorious electron app running twice in the background anyway?

First off: I was pleasantly surprised at just how much of the client is functional. However, as soon as you make a call or join a voice channel, you'll probably notice the problem. Discord will crash, reload, then reattempt to join again, only to crash again since joining is what caused this issue in the first place. Rinse, repeat. If you happen to have the debug info, you'll probably notice the console output say:

wine: Call from 0x7b031dbf to unimplemented function qwave.dll.QOSAddSocketToFlow, aborting
wine: Unimplemented function qwave.dll.QOSAddSocketToFlow called at address 7B031DBF (thread 00f0), starting debugger...

It seems qwave.dll in Wine is just a stub library, which discord makes a call to for an unimplemented function that doesn't exist in the dll, causing the app to crash. Thankfully, this library isn't too special in that you can easily trade in this DLL for one from Windows and wine will work with this just fine.

Now just to be clear, swapping out dlls in wine for windows ones probably violates some Microsoft license, not to mention it can result in catastrophic behavior from wine, but that's up to you to deal with. Let's just say though, that there are a number of websites on the internet that allow you to download this DLL. Just make sure you get one from something like Windows 7, since I read somewhere there are API calls in newer versions of this said library that Wine doesn't support yet. I went with a version 6.0.6001.18000 of the DLL, which I think is from Windows Vista since NT 6.0 was Vista.

You will need to get the 32bit version of this dll and paste it into your system32 directory of the wine prefix. If you happen to be using a 64bit prefix, then you will need to paste it into your syswow64 directory instead. In my case, syswow64 doesn't exist as Lutris just makes a 32bit prefix for osu!, so mine was located at /home/jsebean/Games/osu/drive_c/windows/system32/.

Once I did this, I went to winecfg, went to the DLL Overrides section and changed qwave to native since this is a native DLL, not a wine dll, then just restart discord. Now, connecting to voice channels works perfectly in wine. Hooray!

Now all that's left is to make an easy to use shortcut to launch discord. I did this in Lutris by just hitting the + button in the top left, click "Add Game", enter in the name Discord and pick wine as the runner. Finally, and this is important, you need to clone all of the settings you have from osu! as this runs in the same prefix except for the executable. Be sure to toggle "Show advanced options" at the bottom to see them all. For me, the options are setting the executable (For me, I just set /home/jsebean/Games/osu/drive_c/users/jsebean/Desktop/Discord.lnk). Fore prefix, it's /home/jsebean/Games/osu, set 32bit for the prefix, set the wine version to be identical, and whatever other options are set. Typically "reduce pulseaudio latency" is also set, but I turned this off.

After all that Discord should get it's own launcher in Lutris and you can easily create a shortcut. Everything seems to work now :)

Now here's to hoping we might see this API become available in wine so all this hackery wont be needed in the future.

UPDATE: It appears this bug has been fixed and everything should work fine in wine 5.4. It has also been backported to 5.0.1.

So it turns out the OBS Studio build available in the Ubuntu/Pop!_OS repositories doesn't support anything other than X264. This sucks for people who don't have crazy good CPUs like me.

However life shouldn't be that hard when it comes to live encoding h264 video, since OBS supports the ASIC encoder built into my nvidia GPU, yet the option is not available?

Turns out, you need an ffmpeg build specifically with NVENC support. There are tutorials online that show you how to do this, but my goal of using desktop linux is to not have to be a l33t h4x0r just to get things to work.

Thankfully, getting OBS with nvenc (and supposedly Intel vaapi) doesn't involve having to follow tutorials on how to compile something. Instead, this is from the power of containerization: Canonical's snapd.

On Pop!_OS, be sure to run sudo apt install snapd. Also, feel free to remove OBS which you may have installed from the repos with sudo apt remove --purge obs-studio.

Finally, run snap install obs-studio. Vioila! You've got a fully nvenc supported build of OBS! Congrats.

Just one note, if you go to the snapcraft page here regarding this package, appearently there are a couple commands you should be aware of for getting cameras or removable storage to be accessable to OBS. sudo snap connect obs-studio:removable-media sudo snap connect obs-studio:camera

The snapcraft page also mentions some workarounds if you run into known bugs at the time of writing this blog post which might be worth paying attention to if you notice weird behaviour.

WARNING: Back up your data before doing things I suggest here. Odds are you will break something so don't blame me as this may not work for you... do it at your own risk ;)

So I got a new 275GB Crucial SATA SSD for Christmas for my budget i3 desktop rig that I wanted to move my windows install over from a 500GB HDD. The last time I used clonezilla was a number of years ago (like 2007!), but I had a relatively clean install of Windows with only a few games and programs installed on the hard drive that I wanted to move over preferably without reinstalling Windows all over again since it is still effort. Why make extra work if you can help it?

Clonezilla isn't really made for moving data from a larger drive over to a smaller one like this using d2d cloning, which I guess makes sense, but that doesn't mean we can't make it work. Of course, you can't have more data on the source drive than what the SSD can hold, and who knows what other unknown issues might come up, but I only had the HDD 75GB full and it worked for me. Here's the step by step on how I made it work. Note I'm running Windows 10 Home on UEFI.

  1. In windows I first opened Disk Management (right click This PC in start and click manage) and shrink the partition down on the source drive to something less than the SSD so nothing funky happens.
  2. Create a bootable USB for clonezilla. I simply downloaded the clonezilla ZIP archive, and copied the files over to a blank USB drive formatted as FAT32. Then the F11 menu on my MSI motherboard detected it perfectly on reboot.
  3. Boot to clonezilla (I boot to RAM and remove the USB drive as soon as the blue screen comes up just because I think I recall clonezilla listing the USB drive back in 2007 when I last used it and I wanted to avoid any potential confusion as I'm simple minded. If it's not plugged in, it wont be listed as a disk, right? ;) ).
  4. Choose local disk to local disk cloning (or however it's worded) and then when asked to use Beginner or Expert mode, choose expert mode. You'll have to pick your source and destintion disk but this was pretty easy to understand minus the standard sda/sdb linux disk naming, it shows the disk drive size too so pretty easy to identify!
  5. In expert mode options, I left the flags that are already selected default but I turned on -icds which skips checking disk sizes.
  6. After that I chose k1 option on the next screen and watch it go.

THE LAST TWO OPTIONS ARE NECESSARY for this to work. If you forget the icds flag or the k1 option afterwards it will fail if not destroy your data if you screw something else up.

It moved all the data over and then resized the partition perfectly so that on reboot, the PC booted to the SSD perfectly (even though windows wanted to initially run chkdsk which I let it do and it was fine!). You can (and should) confirm this through disk management just in case, just make sure you boot to the SSD in case your motherboard defaults to the hard drive.

From there, I want to use the HDD as a regular storage drive. So I opened cmd as administrator, ran command diskpart, listed disks (using list disk) and selected the Hard drive disk with select disk 1 in my case (yours may be different!), then ran the command clean.

Then I went back to Disk Management, made sure the C drive partition was using all available space on the ssd (it was, clonezilla did it's job) and reformatted the HDD. Perfect. The whole process only took a few minutes.

Now I should say while this worked for me it may not necessarily work for everyone, of course, BACKUP YOUR DATA JUST IN CASE. Worst case scenario for me was I'd just have to reinstall Windows anyway since it was a fairly clean install and I had nothing important on it so I was willing to just dive in head first and try it. Your case may be different, so keep your data backed up before messing around in case you need to start from scratch!

So Kong from the DD-WRT forums used to provide builds for DD-WRT that I used for my MVEBU Linksys 1900acv2 router. He apparently doesn't anymore, which is fine, brainslayer builds are fine for me, but I wanted to keep the bins he had uploaded for reverting to stock.

I figured I'd post them here in case someone else is looking.

While you shouldn't need these for your 1900ac router if you followed the "FAQ" thread response I wrote, there may come a time you do need it. I tested it before on my acv2 from Kong but I actually got these from a different mirror (since kong deleted them) so they are not tested. I may test them someday. Until then, use at your own risk.

This is a single zip archive with all of the factory firmwares for 1200ac, 1900acv2 and 1900acs, which in theory the acs one should also work with the 1900acv2. Sorry, I don't have them for any other router, but you can check out this thread for details if yours isn't listed here which I can confirm works for the later 3200acm unlike testing these which I haven't done yet. Been busy working but perhaps someday I will. If you can comment below your results though that would be appreciated!

Of course.... if you completely brick your router, you can always go the route of a usb-to-ttl cable.

Anyhow, here is the download link.

Hello world!

- Posted in Uncategorized by with comments

This is my first post! More to come someday. This blog is where I'll post... probably mostly linux stuff? Anything I feel like writing about, you'll find it here.

Cool part about this? I want to see how far I can push a Low End box (as if you call a blog nobody reads "pushing"). So...

This website is running on a lightweight blog platform called htmly. It's flat file based when it comes to storing data, so it's memory footprint is way smaller. I save a lot of resources that I would have used with something like wordpress.

I installed lighttpd web server, and php5. Setup a custom config in lighttpd that htmly suggests so you can't access the config directories and so that rewrite works. Server OS running Debian 8 on a BuyVM 128MB $15/yr Low End Box. I don't expect to get much traffic here so I figure this LEB will last me out a while. And hey.... for running a fully functional blog/CMS platform, this looks sexy:

enter image description here

Yeah that's right! 8MB of ram used total for the entire system and web server. Of course, it's idle, and it is openvz (so not all the processes a dedi would have and in turn very little ram usage) but still, take that apache! No way it would use such little memory even idle haha