Monday, July 16, 2018

Visual Studio Code over SFTP/SSH SOLUTION: sshfs

So, here I am trying to use Visual Studio Code to do some real work, when it's ability to connect to my remote sftp server through gnome's gvfs connection randomly fails.  How dissapointing... Not having hours to figure out why its failing all of a sudden (although a reboot fixes the issue), I decided to look for another option.

Let me give you a quick background of what I'm doing:

OS: Fedora 28

I write Drupal (PHP) code with MS Visual Studio Code IDE which is lightweight and fast.

I use Gnome's nautilus remote folder location integration to mount the folders, which can then 'normally' be accessed by other applications, like vscode.  

Option #1: vscode extensions... I looked at these briefly but I was never really interested in using such an extension when I may need to connect to remote servers securely.  I am simply a bit paranoid that the extension code could be either malicious or buggy and render my connections insecure... So I discarded this option.  If I had more time, I might be inclined to double check the extension's code and functionality.

I'm hoping for a solution that's more or less standard, well supported, well documented, and included in the official Fedora packages.... granted vscode itself isn't part of the official packages, but my paranoia has limits.

Option #2: Looking for a tool to create a local mount of a remote SFTP server.  This would be the closest thing to a real filesystem, and it would take Gnome, Nautilus and vscode right out of the equation... leaving the OS to take care of providing me the remote files.

... And I found sshfs...

It's part of the official Fedora repo.

It's easy to use.

It's available for other OS'es  (Mac and Windows - seriously!).

Some will ask why not use vagrant's own sync folder... because, once again I don't want to be tied down to a particular technology.  If the remote server is not vagrant, then what?

Ok, here's how it works:

Step 1: Create a mount folder for the instance I would like to work on:

$ sudo mkdir /mnt/d8-vagrant

Mount the remote sftp folder:

$ sudo sshfs -p 2222 -o allow_other vagrant@127.0.0.1:/var/www/html/drupal /mnt/d8-vagrant/

That's it.  Now I can open /mnt/d8-vagrant whichever way I like... Brilliant!

Thanks for DigitalOcean's excellent docs for pointing me in that direction: https://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-ssh

By the way, the DO docs/tutorials are nothing short of GREAT!  They are not always perfect, and they tend to have a lot of Ubuntu based articles, but for the most part it ports nicely to Fedora or RPM based systems.  They have very neat and creative ideas too.


Thursday, July 5, 2018

Fedora 28 on the Dell XPS 9570

Here are a few short comments about my experiences using Fedora 28 on the new Dell XPS 9570.

See my previous post for instructions on the NVIDIA card setup.

This system is spec'ed with a 1TB SSD, 16Gbs of RAM and the 1920x1080p 15" 400 nits screen.

PRE-INSTALL:
  1. Before installing, I had to modify the BIOS SATA configuration from RAID to AHCI, otherwise the SSD was not recognized.
  2. I disabled Secure Boot.
GRAPHICS:

The first thing to note, is that the nouveau drivers do not play well with the NVIDIA GeForce GTX 1050 TI which comes with this system.  This means that GDM crashes when it attempts to startup and you are left with a black screen and zero control.  One way to solve this temporarily is to add the following line to your kernel boot parameters:

nouveau.modeset=0

To do this, when you are prompted to choose a kernel during any boot, press the 'e' key to edit its parameters:



Next, move your cursor down to the kernel line and add nouveau.modeset=0 at the end of the line:


Boot the kernel using ctrl+x.

This will allow GDM and Gnome to run without crashing everytime.

You can then install the NVIDIA drivers as per the instructions in my previous post.

SUSPEND:

Until I updated the kernel from version 4.16.3-301 to 4.17.2-200, suspend was working perfectly well with the NVIDIA drivers.  However, as soon as I upgraded, resuming from suspend no longer works correctly and instead shows a black screen with a cursor in the top left corner of the screen.  If my wifi is still connected, I can ssh into the machine and see that XORG is using 100% of one CPU; very few helpful errors are in dmesg.

As a temporary solution I've switched the power button's function from 'suspend' to 'hibernate' - which appears to work well enough.  So far hibernate has failed to resume only once, out of about 30 times or so.

THOUGHTS ON OTHER ASPECTS OF THE LAPTOP:

WIFI: Great reception, Fedora 28 support out-of-the-box.

Camera: Excellent, clear, wide image - Fedora 28 support out-of-the-box.  However, I have the same complaint as everyone else - Put the camera at the top of the screen.  As it is now, its not too bad, but people mostly see my face from slightly below and a lot of my fingers on the keyboard. 

Screen: Excellent.  Great colours, great brightness and brightness control; 'the hobbit' has never looked this good.

Keyboard: Excellent.  There were a lot of negative reviews regarding the XPS 15 series' keyboards.  For my part I find that the keys feel good: You don't have to press them too much, but you do feel them and they respond well and appropriately. 

Heat dissipation: So far I've not experienced the issues that other users have complained about.  However, I don't use this machine to do any kind of serious gaming.  Probably the most graphic intensive game I've run was FlightGear, which hardly gets close to other engines.  I was worried about this point as I run several VMs at once, and they can get fairly heavy loads at times.

GAMING:

I use Linux exclusively on this machine and I don't use steam, so all games I play are stock Fedora or from flathub.  Here's what I've tried:

Minetest - Excellent: I'm a big fan of minetest and run my own server called "Aurelium's mine" at m.impactcore.com.  You can get the list of servers at https://www.minetest.net/servers/
Very smooth on full graphics.  I haven't tried running a server on it, but I would be curious to see how my "LUA script generated lag" would do with this new Intel Hexacore.  Unfortunately the Mod engine in Minetest isn't multi-threaded so I'd still be running mostly on a single core.  Note that Minetest is multi-threaded but the LUA mods are not.

0AD - Great: but chugs a bit when 6 players start to have up to 300~500 workers/soldiers.  But this has nothing to do with the GPU and everything to do with the fact the most of the game runs on a single thread.

FlightGear - Insane! I don't know about multi-threading or how flightgear does it, it might have to do with the fact that the GPU is doing most of the heavy lifting in this game.  The graphics are on max and its smooth as can be.  I never knew flightgear could look so good.  The terrain could be a bit better, but some of the airplanes just look great.  The dynamically generated trees are pretty good, and they fill the gaps nicely to add a touch of reality.

Here are the ones I would like to try soon:

Doom 3 - The doom 3 engine (id tech 4) was released as open source.  A proper doom 3 port was then made by dhewm and seems to work really well.  I've tried it on my other PC with the wad files that I had from the original game.  I will try it on the laptop and update this post.

Battle for Wesnoth - I've never played this much, nor have much time to do so, but I'd like to give it a go and what better chance than to try it on this shiny new machine.

Torcs - I've played this a bit in the past but found it nearly impossible to use with a mouse and keyboard.  Yeah, I don't have a lot of time for gaming these days so I don't have a stick or steering control.

Red Alert - This game brings back memories and for Fedora its available as one of the flathub packages.  I can't wait to try it again.

OVERALL:

Apart from the problem with suspend, everything else works relatively well and I have no complaints.  Other than the few items noted above, there wasn't much else that needed to be done.

The machine itself is solid, much more so than it appeared in pictures and videos I had seen before purchasing it: I was afraid that it might end up being rather flimsy, but was pleasantly surprised by its robustness.