Windows Subsystem for Linux allows running Linux binaries on Windows 10. To overly simplify it, this means that Windows 10 can run a Linux shell based on a number of Linux distributions.
Although Linux is my primary OS, I also have a Macbook Pro to address the rare occasions where I need to use an app that isn't available to Linux (e.g. Sketchup) and when I need a portable UNIX machine (OSX is based on Darwin, a BSD variant). It used to be that to have an UNIX-like environment on Windows meant having to run something like Cygwin which I always felt to be somewhat clunky. Getting Linux software to work was never as smooth or simple as using Linux itself (obviously) or OSX.
WSL changes that completely and I've been using it for a couple of months writing Go programs with VIM in a Ubuntu shell running through WSL. So far it has worked very well! Things does run slower on WSL such as when I'm compiling and writing to the file system, but as my secondary machine that isn't as big a deal. It's really nice that WSL mounts the Windows file system as a mount point that can easily be accessed.
The ever declining quality of Apple's laptops and OSX and its rising cost gives even more weight to Windows being a better buy for developers needing a portable Linux solution or needing both Windows and Linux.
I generally use the command line tool to upgrade from Fedora 27 to Fedora 28. The first upgrade went without a hitch. On a second machine, I ran into a dependency problem requiring that I install the Fedora 28 version of the nss-pem package before starting the upgrade
Fedora 28 has the latest version of Go (version 1.10) which is very nice. I haven't paid attention to what the previous versions of Go Fedora comes with since I also install the latest version that is released on golang.org.
Update: I've since written an updated article about Go and WASM since a lot of have changed in the time since this article was posted.
WebAssembly (WASM) is the most exciting technology in web development in a long time from my perspective. It represents the first true steps in breaking the monopoly of Javascript as the language for the browser even though the WASM folks emphasize that isn't the intention. In my previous post, I mention that Go will support compiling to WebAssembly in version 1.11. This post shares some of my experimentation with Go's WASM support and to see what might be possible. Let me emphasize that the code is very hacky. I wrote them quickly mainly so I can try out WASM.
There are multiple ways to use WASM for web applications:
Optimization for JavaScript-driven applications - This is the scenario most emphasized for the current level functionality provided by the initial (MVP) release of WASM. Instead of writing everything in pre-compiled Javascript, optimized WASM modules are called by JavaScript. These modules can be written in JavaScript or other languages that can compile to WASM.
Porting existing code bases over to the browser - This is most often demonstrated with porting existing C/C++ code bases over to WASM through Emscripten and running what might previously been an exclusively desktop/native app (e.g. Autocad, games, etc.).
Writing an web app completely in a non-Javascript language - This is what I'm most excited about! Instead of having Javascript be the primary language, the application is completely written in another language such as Go. At the time of this writing, this isn't completely possible since WASM doesn't support WASM modules from directly calling the browser APIs (e.g. DOM APIs, XHR, etc.). This will be coming and is currently covered under the Host Binding proposal for WASM. Until then, the Javascript can be abstracted away in a language-specific binding.
The current state of Go WASM doesn't fit the first scenario very well. There doesn't seem to be a way to expose methods individually for Javascript to call directly. The Javascript code can execute each Go program's main function and when main() is done the module is done running. Given that each WASM module has the complete Go runtime including garbage collection, I'm not sure how practical it is to have a bunch of Go programs that are essentially meant to be single methods to the Javascript code.
Go WASM does provide the ability to define callback methods and attach callbacks to browser events. This requires that the module is running because once it exists it's not longer available to the browser call call. Because of this, Go WASM is currently most appropriate for scenarios 2 & 3.
The browser executes Javascript and WASM in a single threaded manner. When the WASM module is running, the browser's front end will block until it is completed. This will appear to the end user as if the browser is frozen: no way to type input, click button, etc. With Go WASM, control is given back to the browser when using time.Sleep or when the Go code is blocked. This has to be done manually by the developer so it's important to keep it in mind. Unless the apps expect to have completely control of everything in the browser while it is running developers need to remember to periodically sleep itself to give some control back to the browser. I hope this gets improved in the future because it makes the code ugly, error prone and honestly isn't something developers should need to do in a multi-tasking environment.
This is a very basic example of writing a Go WASM module that defines a method that gets attached to a HTML button's click event, change some attributes of the document's elements, waits a few seconds then executes a Go routine that draws to the canvas in the browser. The keepalive() function prevents the module from quitting until it gets a quit signal that happens when the Quit button is clicked and the cbQuit method is invoked because the button click event is triggered. Also note that when the browser's Alert dialog is triggered, it blocks everything until it is dismissed whether it's called by JavaScript or by the Go code.
The keepalive() can also simply be
select {}
if the intention is just not let the module exit.
---
---
The basics of having Go drive the web page (rather then it being Javascript) is all there.
This example was inspired by what was presented at GopherCon by Hana Kim when gomobile was first announced.
Instead of re-writing Rob Pike's Ivy Interpreter for Android/iOS/command-line the example showed that the existing Go library was reused. Just like her example, this example shows that existing Go libraries can be used in WASM.
---
---
The resulting WASM module is about 4MB but when compressed, the whole web app was only about 1 MB.
This example really doesn't show anything that the previous example didn't already show. I wanted to try against a larger code base and didn't want to write it myself. It mainly just demonstrates an existing Go library being used with no changes needed to make it work.
The Ivy code is easy to port but if something is expecting to access a file system or make HTTP calls then the browser environment doesn't match. There isn't any standard file system and outbound calls uses XHRHttpRequest rather then the current HTTP package.
Conclusions
It is possible to use Go to write web applications even though it currently still needs to rely on JavaScript to access the brower's APIs. Things like Go routines work but developers have to handle sleeping themselves in order to not block the UI. However, the possibility of ending JavaScript's monopoly for being the browser's language is definitely there!
Browsers themselves still need to do some optimizations. Each WASM module's byte code still has to be compiled so there's always a delay before the module starts running. It still starts faster then JavaScript but it'd be much better if the browsers caches the compiled WASM the first time. My understanding that it'll likely come in the near future but not there yet.
I'm very excited to see this land in Go 1.11 and look forward to see what other developers use it for!
Linux system can be backed up very simply through the use of a command line tool called rsync and with a little scripting the backup process can be automated just like it is on OSX and Windows.
Encrypting the Backup Drive
Before backing up your files, it is a good idea to encrypt the external drive where you'll be storing your backups. This is to prevent someone from taking the external drive and accessing your files. Use the Disks utilities and select the drive and change it to encrypt the partition. Note that this means that in the future only a Linux system (along with the password) can access the external drive.
Backing Up the Home Directory
I create two separate backups: system and home. The system is to backup my system configuration while the home directory contains the users data. There are a lot of files and directories in the home directory that doesn't need to be backed up that might be consuming a lot of disk space. These include cached files, trash files, etc. It's best to exclude these files and directories.
I found this file as a good starting point for things to exclude from the home directory. With this files (modified to your liking), use rsync to back up the home directory (this example is to back up just your own home directory):
rsync -aP --exclude-from=[exclusion file] /home/$USER [path to backup location]
Make sure that you've mounted the external drive and have the path correct. Use the 'n' option (e.g. rsync -naP ...) to do a dryrun where it it doesn't actually copy any files so you can test first.
If it all works correctly, a crontab to automatically repeat the process can be made although you still need to mount the drive with the encryption passphrase unless you set it up where the cron job has access to the passphrase. I just create a bash script that I run manually.
Backing Up the System
Backing up the system is very similar except there are some additional directories to exclude and the starting point is "/" instead of the home directory.
1. Create a file similar to the one for excluding home directories (see above). This file is more simple since it only contains directories:
This is the first time that I've tried to compile the Go compiler so I figure that I'll document it here for others who might be wanting to try WASM with Go before the official Go release in August.
The next release of Go (1.11) is scheduled for Aug and it will be first time WebAssembly (WASM) will be supported. WASM will be a build target much like how one builds a binary for other machine and operating systems except that in this case the machine is a "virtual" machine that runs inside the browser.
I've been very excited for WASM and I've been eagerly waiting for the time when I can use Go to write WASM. The branch for the 1.11 release has is now locked for only bug fixes so I figured that it might be a good time to try writing a WASM code with Go. Note that this first release for WASM isn't going to be "production" ready. I don't think it'll be very optimized and WASM itself is only at its MVP release it doesn't allow WASM code direct access to the DOM or the browser APIs so all calls is still going through JavaScript.
Unfortunately, as of this writing, the code in the Go repo doesn't work for WASM. The work on WASM for Go is primarily being done by Richard Musiol (neelance), the author of GopherJS, so I decided to get the version Go from this GitHub repo.
First, you will need a version of Go on your system to compile the source. The easiest way is to download and install the binary distribution from the main Go website.
Until 1.11 is released to get WASM is to build from source.
git clone https://go.googlesource.com/go
cd go
Once you have the source, it's time to compile it.
cd src
./all.bash
If everything is built correctly then there will be a new "go" binary in ../bin. Also, there are two files to help you get started with loading future WASM files in ../misc/wasm.
Create a test.go file:
package main
func main() {
println("hello, wasm")
}
Compile to WASM with:
GOOS=js GOARCH=wasm go build -o test.wasm test.go
Make sure you're running the go command that you've just built and not the version that you installed originally.
In the same directory with your test.wasm file, copy over wasm_exec.html and wasm_exec.js from misc/wasm.
The browser will expect the test.wasm file to be served with a MIME of application/wasm so you'll need to add the following to your /etc/mime.types file:
application/wasm wasm
To run it in your browser, you'll need to have a web server. Creating one with Go is easy, or you can also use Python with the following command.
python -m SimpleHTTPServer
Point your browser to your web server and load wasm_exec.html. Click on the button and you should see "hello, wasm" appear in the browser's console.
Following Acer's announcement of the first ChromeOS tablet, HP followed with their version called Chromebook X2. I've always believed that Chromebook makes for excellent laptops for the vast majority of use cases and ChromeOS might actually be a better OS for tablets rather then Android. Of course now that ChromeOS can run Android apps I feel that's more true then ever.
I like that the Chromebook X2 can detach the keyboard versus what the Pixelbook does, although likely for my next tablet, I'm more likely to go with the Acer simply because I don't need the keyboard and the Acer is cheaper because of it.
When it comes to Android vs iOS, I'm firmly in the Android camp. Just like iOS, Android is used to power both phones and tablets, but I believe that ChromeOS might be a better OS for tablets which is why I'm very excited by Acer's announcement of the first ChromeOS tablet. Even though Google touts Chromebook tablets as ideal for education, it's really ideal for general use of tablets.
Chrome has become a powerful platform for developing web applications and ChromeOS' performance, stability and security is perfect for a device that is used much longer then phone. With the emergence of web assembly, I can see developers being more effective writing web applications and directing tablet users to those same applications as desktop users.
For me personally, I spent most of my time on the tablet using the Chrome browser. Many of the Android app that I use are basically just the web application wrapped into an Android app, but for those time that only a native Android app is available ChromeOS can now run Android apps alongside web apps.
I think my next tablet might very well be a ChromeOS tablet and I hope to see ChromeOS replace Android in this space. I also hope to see developers move towards web assembly and build more powerful web apps using languages such as Go (web assembly currently being worked on).
Shadow of the Colossus was originally released on the PS2, then on the PS3, and then remade for the PS4 to take full advantage of modern graphics. I missed it on the PS2 and I pretty much missed all of the PS3 generation so I thought I should try it now on the PS4.
Did I miss out when I didn't play it on the PS2 or PS3? I give my impressions here.
Following Horizon: Zero Dawn, I decided to play Persona 5. While not an open world game it still has a strong story narrative. Although JRPG is often viewed as being a niche among gamers in the United States, Persona 5 seemed to have won over many US fans and is often named among the top contenders for Game of the Year.
To keep things organized, I got some stands for holding the various game controllers that I have for the PS4, XBox and Switch. There are many options out there, but these are the ones I got for myself because I thought they provided better organization and presentation. I've been using all these in my set up and like each of them.
PlayStation 4
I have two black DualShock 4 controllers. These have built-in batteries so they need a dock that can charge them. Most of the ones I saw held the controller upside down to charge which I didn't like the look of so I bought the official charging station that is sold in Japan.
Unlike a lot of third party stations, this uses the port on the bottom of the controller to charge so the controller are sitting upwards. It's a nicer look that matches how my other controllers are held. Note that this is just for the DualShock 4. There is one that can support both DualShock 3 and 4 but it doesn't hold it upright and requires an adapter.
Xbox One S
The Xbox One S controller have removable batteries so I use rechargeable ones that I swap in when power runs low. For these controllers, I don't need it to be a charging dock. I got the Gear controller stand in white that matches the controller colors I have. Each stand holds one controller.
Nintendo Switch
The Switch is interesting because it has two types of controllers: Joy-Cons and Pro. Two of the Joy-Cons normally connects to the Switch itself so they don't necessarily need a separate stand. I have the Switch in a protective case so taking out the Joy-Cons can be a troublesome so I got a second pair of Joy-Cons for my kids as well as a Pro controller that I normally use. Thus, I needed a stand that can hold 1 Pro controller and a pair of Joy-Cons.
This charging stand has a built in connector that plugs into the USB port on the Switch's dock and the top of the unit has lights that indicates that it's charging and when each controller is charged.
