Ubuntu is taking too long to boot!!! - Fix Problem

If your Ubuntu laptop/desktop computer taking too long to start, this post is for you to fix this problem. The main problem is often the address of the swap is mis-configured or falsely identified.

First we need to measure the boot up time (start time) accurately. So we will use the systemd analyzer as you see in this command.
systemd-analyze time
systemd-analyze time

After knowing the startup time, we should determine if it is normal or slow?! .. in brief, if the total startup time is less than 25 seconds then it's normal. But if the startup time is more than 25 seconds it's slow.

Identify the UUID of used SWAP partition

To identify swap partition run this command, and type your password.
sudo blkid | grep swap
identify the currently used swap partition

After that, remove any other swap file mentioned on /etc/fstab except the above identified swap.

edit fstab file to remove false swap files

Use any editor as you like to edit the /etc/fstab but make sure to edit it as root (using sudo). I am using VIM, but you can use NANO or GEDIT or EMACS.

And edit /etc/initramfs-tools/conf.d/resume file using favorite editor to replace the UUID with the swap partition one if it is not the same. Don't forget to edit it as root.

change the UUID of swap partition to the correct one

Then run this command to update initramfs.
sudo update-initramfs -u

Now.. reboot (restart) Ubuntu so you can see the best performance and speed are come again!

If you want to get new posts, make sure to subscribe to Value In Brief by Email.

Where Does The Google App Save Downloaded Images?

Too many people have this problem when saving images using Google app. But here is the fix for this problem.

First, long press on the Google app widget on home screen - as shown on the image below - then choose App Info.

open app info for Google App home screen widget

Second, tap on app permissions. You will see the permission granted as shown on the following image.

Google App permissions

Third, enable storage access by pressing on Storage item on the permission list shown in the above image and below image.

enable storage permission for Google App

After enabling the storage permission, the images and photos and pictures you download on Google app will be saved to the internal storage of your smartphone. So the downloaded images will show up in gallery app and file browser app.

If you want to get new posts, make sure to subscribe to Value In Brief by Email.

How To Detect And Redirect To Mobile Site Using PHP?

If you don't want to use javascript, you can handle it via php. Take a look at this lib: http://code.google.com/p/php-mobile-detect/. And then you could do something like this code:

<?php
include 'Mobile_Detect.php';
$detect = new Mobile_Detect();

if ($detect->isMobile()) {
    header('Location: yourpage.php');
    exit(0);
}

This library is reliable and usable until today. It's great. I hope you find this short-blog useful. If you want to get new posts, make sure to subscribe to Value In Brief by Email.

Do You Really Need To Eject USB Drives?

Why don't we just yank the USB stick out?! Why we should click on Eject USB then yank it out from the laptop?!!

safely remove USB storage device

Some Operating Systems prefer to cache the copying process from difference storage drives. For example, When you copy some files from your Hard Disk to the USB drive, the files data will be cached in the RAM then moved to the USB stick.

This caching give the illusion of speed copying. But if you yank the USB stick from the computer when the data is still on RAM not actually on your USB stick, your data will be corrupted!!! and you'll lose your data!!

So it is recommended to make sure to click on "safely remove USB storage" or "Eject USB drive".

eject USB mass storage device

Some other operating systems does not use this copy or move cache in RAM but perform it in a realistic way. Actually copying data from Hard Disk Drive to USB Drive. This is better! But..

All operating systems make modification on files on RAM then flush the changes into the storage when you save. For example if you open a word document (docx file) and edit some words, the modifications are not saved yet until you hit the save or save as button.

So it is recommended to close all related files, and to make sure that there is no files in use from the USB drive, click on EJECT to make sure there is no data loss or corrupted data may happen!

Finally, I recommend you to close all related files and click on "Eject" or "safely remove USB mass storage device" to make sure that your data on USB drive is safe and completely saved.

I hope you like this post. If you want to get new posts, make sure to subscribe to Value In Brief by Email.

How To Play Old PC Games On Windows 10 ?

There are too many to run old games on Windows 10 but most of them fails. So follow the following steps. if the game works after a step, it's fine. But if you run through all the steps but the game can't run, through this game from your way! It won't work!!!

1. Run The Game In "Windows Compatibility Mode"
2. Run It On Windows 10 32 bit
3. Search For A Modern Edition Of The Game On Steam

If your tried all the 3 steps and none of them run the game, you should through the game from your head. It will not work.

Finally, I hope you like this post. See you next blog post. If you want to get new posts, make sure to subscribe to Value In Brief by Email.

Why Don't Old Games Work On Windows 10 ?

We are guessing that old games will run much smoother on Windows 10! right?.. Wrong! even if you use Windows compatibility mode to run your old games, you will fail most of the time!! BUT WHY?

The real direct reasons are the architecture which those games are written for. And here are all the reasons why old games don't work on Windows 10 computers.

1. Old Games Are 32 bit

Windows 10 OS written for 64 bit CPUs to run faster and allow more than 4 GB of RAM. But every program or game need to be coded to run on either 32 bit system or 64 bit system. This means that Windows OS will emulate 32 bit system to run old 32 bit programs and games.

But this will not work for most games because some games try to use some incompatible code in form of DLL files. A windows update might break a dependency that the game relies on.

Some games won't run at all because some of their code was written for 16 bit systems which Windows 10 can't emulate at all.

2. Multi-threaded Technology

Modern CPUs are designed to split a given program workload to run on multiple cores. This type of design lead to a more performance. But it is horrible for the games which is written for the one core old CPUs.

Windows 10 runs all programs and game in multi-threads by default to gain some more speed and performance.

You can dual-boot Windows 64 bit with Windows 32 bit So you can run some old games on the 32 bit variant of Windows 10. Finally, I hope you like this blog post. If you want to get new posts, make sure to subscribe to Value In Brief by Email.

Why Don't Old Games Work On New Computers ?

We are guessing that old games will run much smoother on the new powerful PC and laptops! right?.. Wrong! even if you use Windows compatibility mode to run your old games, you will fail most of the time!! BUT WHY?

The powerful new hardware is a tiny part of the story. The real direct reasons are the architecture which those games are written for. And here are all the reasons why old games don't work on modern computers.

1. Old Games Are 32 bit

Most modern computers use 64 bit CPUs and 64 bit operating systems (Windows OS in this case). The 64 bit architecture is faster and allow more than 4 GB of RAM. But every program or game need to be coded to run on either 32 bit system or 64 bit system. This means that Windows OS will emulate 32 bit system to run old 32 bit programs and games. But this will not work for most games because some games try to use some incompatible code in form of DLL file. A windows update might break a dependency that the game relies on.

Some of game won't run at all because some of their code was written for 16 bit systems.

2. Multi-threaded Technology

Modern CPUs are designed to split a given program workload to run on multiple cores. This type of design lead to a more performance. But it is horrible for the games which is written for the one core old CPUs.

I hope you found this post helpful. If you want to get new posts, make sure to subscribe to Value In Brief by Email.

What is the best advice for a beginner who wants to learn Go as a first language?

1. Pass the Go Tour.

2. Take a look at Go by Example.

3. Follow common best-practices. (todo: create a post instead)

4. Absolutely always use the race detector.

5. Follow bloggers such as Dave Cheney and join the community.

6. Don’t be afraid to ask, the community is always willing to help, just make sure the code you need help with is on The Go Playground (ideally it should also compile and be formatted and properly documented).

7. Just start writing something and learn by doing! Take an idea, be it a simple todo-app REST API or a file-line-counter, it doesn't matter. What matters is that you set some goals and pursue them.

.. ready.. steady.. Go!

If you want to get new posts, make sure to subscribe to Value In Brief by Email.

Is Go a more powerful solution than Node.js for Back-End Web development?

In short: Go is a much more powerful back-end solution than Node.js and I’m wondering why Node is still even considered a “back-end solution” rather than a “prototyping tool” at all.

I’ve been doing a lot of API development in Node.js before I discovered Go and it wasn’t very pleasurable for many reasons that I’m going to list below, those reasons even got me started looking for an alternative back then.

1. Weak Dynamic Typing (JS) vs Strong Static Typing (Go)

I initially had a C++ background and when I started writing servers in JavaScript it felt like a step back because a lot of runtime errors in Node were type errors. I usually ended up wasting my time on unit- and integration tests too many of which were just testing the scripts for type correctness. Projects usually grow in size over time (even those you wouldn’t expect would) which leads to maintenance hell without proper typing.

Go won’t even let you do such mistakes since it’s strongly statically typed and will fail at compile time rather than runtime. It can only fail at runtime if you’re using empty interfaces and type assertions a lot and you’re not doing it carefully enough (you shouldn’t abuse empty interfaces anyway, structs are there for a reason).

TypeScript does improve the situation, but you have to take into account that most of the JavaScript code out there is still untyped.

2. Performance and Resource Usage

Go is fast, really fast, and it surpasses Node.js on both I/O and number crunching by a lot. I once helped a friend of mine to compare the actual number crunching performance of JS and Go using a prime-number calculation algorithm implemented similarly in both and we were a little surprised by the results when calculating 1 million primes on a late 2013 Macbook:

  • Node took 14 seconds to finish and required ~27,5 mb of memory
  • A single goroutine took only 663 milliseconds and only ~2 mb of memory

For 10 million primes things started to look even worse for Node:


  • Node took ~7m 39s and required ~234 mb of memory
  • A single goroutine took only ~7,5s and only ~13,7 mb of memory

Please, notice that this is a pure synthetic test, real-world application performance must be measured carefully in order to make valid assumptions on when it’s the platforms fault. Do not trust these numbers, better go test it yourself or look at different popular benchmarks such as Go vs Node js - Which programs are faster? because benchmarks often tend to be unintentionally falsified.

I personally never saw Node.js outperform Go, ever, on anything including I/O, which doesn’t necessarily have to universally be true, it’s just my subjective personal experience from the past 4–5 year of backend development. There might be cases, where a perfect combination of C++ and Node could easily outperform Go on specific tasks.

3. Predictability and Benchmarking

Probably the biggest problem with dynamic languages like JavaScript is the fact, that it’s incredibly hard to predict what it will actually do at runtime when looking at the code!

Even though Go uses garbage collection for memory management just like JavaScript, it’s still way more predictable in terms of performance and latency than JavaScript, because it doesn’t rely on JIT compilation but static ahead-of-time compilation instead. You can literally get the assembly code from the compiler to have a better understanding of what the CPU is going to be doing in each function!

A struct with an unsigned 32-bit integer field in Go is going to be just that, a 4-byte piece of memory, more or less (not taking padding etc. into account, but still). An object with a number property in JavaScript, however, could be anything in memory and it depends on what the particular version of the V8 engine thinks is better in a particular situation.

JavaScript is incredibly difficult to benchmark! There was a talk from Vyacheslav Egorov, at the GOTO Conference 2015 in Chicago, about how tricky benchmarking JavaScript really is, and even though the talk is from 2015 - not much has changed so far because this is an inherent problem of dynamic JIT-compiled languages in general. It’s very easy to come up with false conclusions when benchmarking JavaScript code.

Finding out where, when and why your Node.js server is slow or uses up too much system resources can also be very painful.

Contrary, Go has built-in benchmarking tools, profilers and even a neat tracer to help you identify latency problems!

The picture above shows a trace captured from a WebSocket server written in Go during performance benchmarking of webwire-go
The picture above shows a trace captured from a WebSocket server written in Go during performance benchmarking of webwire-go.

Go compilers sure don’t optimize your code as well as those of C/C++ or Rust, but the Go toolchain is very good at helping you find bottlenecks and hidden performance and resource usage potential in your programs.

Even micro-benchmarks such as “testing what string concatenation method is the fastest” is totally doable in Go and I even do it from time to time to make sure my code’s not only maintainable but also efficient at the same time.

4. Event Loop (Node) vs Goroutines (Go)

Node’s concurrency model is actually simpler, but Go’s concurrency is exceptionally powerful yet relatively easy.

As you probably already know, Node.js uses an event loop with libuv underneath which allows your Node.js server to deal with I/O asynchronously without blocking the CPU when you’re waiting for a long-running operation like an HTTP request or a Database transaction to finish. But Node.js is still inherently single-threaded, meaning that whenever your script is executed - your application code can only do 1 thing at a time. The JavaScript engine and its internal modules may be doing things concurrently, but those aren’t part of your application code and I’ve not seen many people who actually spend their time writing Node.js V8 modules in C++ to offload some application workloads onto them, because that’s not easy and you definitely don’t want to split your application code base into individual JavaScript and C++ modules.

Most JavaScript environments including Node.js do provide the concept of workers (which are kind of isolated engine instances on top of OS threads, but the actual implementation heavily depends on the engine), but…

  • you can’t spawn too many of them and…
  • they can’t share memory but instead, rely on message passing for communication.
Node.js clusters (when you run multiple processes as a cluster) also can’t share memory and have to rely on different (mostly operating-system specific) IPC techniques, or, even worse, external queue systems or databases (I’ve often seen people use Redis for that) to exchange data between individual Node instances.


Go is inherently concurrent and I’ve written about it in many of my blog posts so please be welcome to check it out.

In short, Go’s goroutines can share memory and you can spawn and use millions of them to do a lot of things concurrently! But the “sharing memory” part is where you have to be careful!

In Go, reading shared memory from multiple goroutines is fine as long there’s no goroutine trying to write to it as well. If at least one goroutine is going to be writing to a shared piece of memory - you need to protect it using a synchronization primitive (such as a mutex), otherwise, you’ll end up creating a data race!

Fortunately, Go comes with 2 built-in things to help you write safe concurrent code:

  • Go channels are safe in terms of concurrency and beginners should use those for making goroutines talk to each other safely! They’re a core part of the language and come from the concept of Communicating Sequential Processes.
  • The built-in data race detector helps you find any occurring data races at runtime so you won’t miss them.

I’ve even seen people applying strategies like running their production code with the race detector enabled (which does have a significant memory and performance impact) and then, over time, getting rid of it when they’re sure everything’s working fine boosting the performance to the top again.

5. Promises / Async&Await (JS) vs nothing (Go)

Since JavaScript is inherently single-threaded, you need to write your code in an asynchronous style with either callbacks, Promises or async/await.

DISCLAIMER: The APIs in the following code are fake and were made up for demonstrational purposes. I won’t cover callbacks because they’re are no longer recommended for writing asynchronous JavaScript code in 2019 and I also won’t cover error handling here because we’re talking about concurrency models.

Promises:
function HTTP_DB_FS(resource, fileName) {
return http.Get(resource)
.then(data => db.Query(data))
.then(result => fs.write(fileName, result.data))
}
ES6 async/await:
async function HTTP_DB_FS(resource, fileName) {
const data = await http.Get(resource)
const result = await db.query(data)
return await fs.write(fileName, result.data)
If you block the event loop somewhere you’re going to be in silent trouble because the event loop will easily become your bottleneck! Never block the event loop in JavaScript!

In Go, however, writing blocking code is totally fine since a blocked goroutine is automagically swapped out for another one by the scheduler:
func HTTP_DB_FS(resource, fileName string) fs.File {
data := http.Get(resource)
result := db.Query(data)
return fs.Write(fileName, result.data)
}
The above Go code is almost the same as the JavaScript code before, it’s just non-blocking by nature. As you probably can see, Go’s built-in scheduler makes asynchronous non-blocking code a lot easier to both read and write!

6. Dynamic Execution Environment (JS) vs Compilation (Go)

Since JavaScript is interpreted - your code might be executed in a different environment (such as Node.js and the Browsers), some of which won’t support some features or modules you’ll be using and you have to keep that in mind.

The WebSocket APIs do differ on Node and in Browsers for example. Another great example would be that Node.js uses the Buffer module whereas browsers use the ArrayBuffer primitive. You have to be very careful about what environment capabilities you use and when.

Since Go is statically compiled - everything will be exactly the same on every platform (except some operating system features of course, which you won’t normally use though).

7. Deployment

With Node, you have to make sure the right version of Node is installed on your server. Docker does help, but Go is still one step ahead. A compiled Go binary won’t need anything external to run itself, you just run it.

Final Conclusion

Neither the JavaScript language nor the Node.js runtime was ever designed to be a serious back-end solution.

  • JavaScript was designed as a sandboxable scripting language that could be loaded into the browser, interpreted and then compiled on-the-fly gluing together certain parts of the DOM.
  • Node.js just made it easier for Front-End JavaScript developers to quickly get a micro-service up and running without having to dig into learning back-end languages such as C++, Java etc. (or PHP… though PHP is probably even worse than Node.js in almost all aspects so I won’t consider it a good back-end solution either).
  • JavaScript code can’t fall into synchronization issues and data races because it’s single-threaded by nature. But since Go has channels and a built-in race detector - this advantage becomes rather moderate.

    (but remember that you’re never safe from race conditions, not even in JavaScript because those are semantic issues)

Go was designed to replace C++ for writing networking software at Google (Not to replace C++ in general, many got this claim wrong). It was designed with heavy loads, predictability, maintainability and concurrency in mind.

  • Go was also designed to be a very simple, relatively safe and coherent programming language, which we can’t really say about JavaScript. Most scripting languages including JavaScript tend to be more expressive but harder to read. Go is rather balanced in that regard, it will feel a little more verbose than JS, but it’s also going to be much easier to read and maintain.
  • Go is much faster than Node on average and uses up much less memory (sometimes 10-fold and even more).
  • Go is also non-blocking by nature without requiring you to write asynchronous code.
  • The amazing tooling around Go will help you remove bottlenecks and latency issues relatively easily and make it scale like crazy.
  • Unlike in JavaScript, testing is built-into Go’s standard library and toolchain.
  • With Go, you can write closed-source software, with Node you’d have to obfuscate/uglify your code, which is still much easier to reverse-engineer than compiled Go binaries.

Finally, to me personally, writing server software in JavaScript feels like trying to hammer a nail with a screwdriver, for the reasons described above.

As a professional software engineer, you’ll get productive in Go in less than a month, so don’t waste your time on screwdrivers when you really just need a proper hammer.

If you want to get new posts, make sure to subscribe to Value In Brief by Email.

Is Golang good for real-time services? Should I choose Node.js instead?

It depends on what you mean by "real-time"

  • Chats, collaboration boards, streaming? Definitely yes, Go will fit perfectly!
  • Stock exchange trading and similar? maybe, needs testing, Go could be sufficient but it really depends on what latency tolerances we’re talking about.
  • Fighter-jet sensors, 3D VR rendering and similar? Definitely no, that’s where Go’s garbage collection and poor compiler optimizations (compared to C) are usually not an option.

Should I choose Node.js instead?
I don’t think so, and I’ve described why in another blog post. There are several problems with Node:


  • Node is very unpredictable in terms of performance due to dynamicity and JIT compilation. Go is statically typed and compiles to machine code ahead of time making it very predictable. You can even just take a look at the output assembly to find out what’s wrong if needed.
  • Node will usually be slower than Go in general. For example, there’s no integer types in JavaScript, just “numbers”. Numbers are 64-bit floating point numbers (IEEE 754). Computations on integers are usually way faster and I’m not sure V8 is able to optimize this at all. Go, however, supports both 32- and 64-bit integers and is able to produce fast executables (not as fast as C/C++/Rust, but usually faster than V8). In computing, anything dynamic will always add runtime cost (like dynamic vs pre-baked lighting in 3D graphics).
  • Node won’t make it easy to find your performance problems. First of all - JavaScript is extremely difficult to benchmark correctly, Go, however, supports benchmarking natively through pkg/testing and go test. Go also has a tracer and pprof built-in because it’s designed with development of high-performance software in mind. JavaScript was never designed to be used as a server-side programming language.
  • Multi-threading… again, JavaScript was never designed to be a language with multi-threading capabilities. Go was deliberately designed to make multi-threaded concurrency easier than the traditional threading model. There are several ways to make a Node-powered service use multi-core CPUs (like workers and clustering) but the only advantage compared to Go is that JavaScript is somewhat safer in terms of memory management because in Go you can easily shoot yourself in the foot with data races. Luckily we do have a data race detector built-in to Go so it’s not that much of a problem, you’ll just have to acquire a few multi-threaded programming skills. Go will do much better at utilizing modern multi-core systems because there’s no event loop but a built-in user space scheduler and goroutines utilizing all CPU cores whenever possible.

I’m not trying to say “Node is bad, you shouldn’t use it for real-time systems at all”, it might actually do surprisingly well when there’s only little JavaScript and things like uwebsockets backing it, but I really feel much more confident with Go because I know - if there’s ever a performance related problem - I’ll find it quickly using the tracer and profiler, I’ll fix it easily and prove it’s faster with actual benchmarks. I can even check what string concatenation method is the fastest in the nano-seconds range which is considered “micro-benchmarking” and almost undoable in JavaScript.

There’s always an option to write V8 modules in C++ and use them from JavaScript but it’s much more difficult than it seems and you’ll be dividing your code-base into 2 languages (2 ecosystems, essentially) which is far from good.

If you want to get new posts, make sure to subscribe to Value In Brief by Email.

What is the easiest way to deploy a simple Go web application?

What is the easiest way to deploy a simple Go (Golang) web application on a server, for someone coming from a PHP environment?

The easiest way is to compile your Go executable for the server’s architecture and OS on your development machine, just copy and run it there.

A Go executable is self-sufficient. It won’t need an external web-server, a runtime, runtime configurations, etc.

However, usually, you’ll also have a database backing your service, some kind of configuration files and similar. Containerization is a good way to deal with these situations. I use Docker Compose to deploy my services and I’ve also automated it in such a way that when I push to the "release" git branch the CI/CD system will automatically compile my Go code, verify it’s correct using various static code analysis tools such as https://golangci.com/ and go vet and deploy it as a containerized service on production servers.

If you want to get new posts, make sure to subscribe to Value In Brief by Email.