In the last couple of month few things surfaced the news about Intel that made me worry. This is a list of things that made me wanna shout "WTF, Intel?"

Some time ago I bought some XRP (Ripple coins) based on some news that banks are planning to use it. Apparently this is not true. Banks are using some other products provided by Ripple, the company behind XRP, not the coin itself:

While XRP investors might be charmed by the thought of holding a cryptocurrency that one day a large swath of the banking system may use, the vast majority of Ripple's banking clients are using the company's xCurrent product – a glorified messaging platform.

Another disturbing fact about XRP is that nodes in the network are all controlled by Ripple, which makes it less "decentralized".

Ripple relies on a Unique Node List (UNL) – currently encompassing five core validators all run by Ripple – when matters of consensus need to be determined.

Anyone can download the XRP ledger package and become a validator and start broadcasting immediately, but getting everyone else to listen to you is a second point

If you want to read more check "$100 Billion Controversy: XRP's Surge Raises Hard Questions for Ripple" on CoinDesk (the source of all the quotes above). I didn't check this against other sources yet.

My experience about adding git to a project that had no versioning control system before. The project had two running versions that ended up as branches so changes from one can be merged in the other and a production server where git was added without downtime and now it's used for deployments.

My last pair of bluetooth headphones broke and I just bought myself a pair of Apple AirPods. Here are some thoughts regarding them.

AMPPS is a great, but it lacks xdebug support. If you run the latest AMPPS version 3.7 on OS X you probably don't have the xdebug extension in the php-7.0/lib/extension folder. Read this article to find out how to fix this!

ArsTechnica has a in-dept article covering new version of the mobile operating system: Android 8.0 Oreo, thoroughly reviewed. My highlights from that article are:

Project Treble

Project Treble introduces a "Vendor Interface"—a standardized interface that sits between the OS and the hardware. As long as the SoC vendor plugs into the Vendor Interface and the OS plugs into the Vendor Interface, an upgrade to a new version of Android should "just work.

So you should get Android updates faster as long the vendor provided firmware is still supported. Google decides which version it will support based on data collected (how many devices are still on that version).

ROMs shouldn't need to be painstakingly hand-crafted for individual devices anymore—a single build should cover multiple Treble devices from multiple manufacturers. Imagine the next time a major new version of Android is released. On Day One of the AOSP code drop, a single build (or a small handful of builds) could cover every Treble device with an unlocked bootloader, with a "download Android 9.0 here" link on XDA or some other technical website.

Also graphics driver can now be updated through Play Store like any other app.

The Great Background Processing Lockdown

Apps can't just run in background using CPU, RAM and battery as they want. With Oreo they are required to show a notification saying that they are doing background work so you get to decide if an app is doing too much or not. Also, some events will not trigger background processing for all apps like before, making the UI more smoother. And to prevent apps for consuming the battery, all the background processing work will be done through a scheduler in batches, allowing phone to "sleep" more to preserve battery.

New Emoji

Most people know about first-mover advantage, but a few know that it might also be a disadvantage. When the business relies on technology you may end up outdated pretty fast unless you invest heavily in technology or be lucky/smart enough to bet on the winning technological approach (most of the cases you are not).

A few examples come into my mind. First, road tax. Most developed countries from western Europe use stickers applied on the windshield for verification. Some have automatic cameras to check them, others still rely on random human inspection. Eastern European countries introduced road tax years later -- and because the technology was available and (most probably) cheaper they use a completely electronic system. You don't get a sticker - they scan your license plate instead. They are easier to buy online and more flexible. For the countries that already have stickers it might not be economical feasible to update their system, so they might end up waiting years before upgrading.

Another example is the internet infrastructure. Western countries had cooper wires from the 50s already in place and they used that. The cost to upgrade to fiber optics is harder to justify when you already have a working system. Poorer countries didn't have cooper wires everywhere or they were in pretty bad shape. When they decided to get online - fiber optic was already available and they started with that directly. That's why some underdeveloped countries have better Internet connection.

These are the stories that come in to my mind whenever I think about upgrading my 6 years old PC. I try to postpone the move as much as possible just to make the jump in performance as big as possible to better justify the cost and also to avoid being one of the first generation users of Intel i9 or Ryzen Threadripper.

 

 

 

Today my dev server ran out of space. Which was a little bit weird - 20GB should be enough for a bunch of websites. I managed to free up to 6 GB of space just doing the following:

1. Aptitude cache

sudo apt-get autoremove

I had to run this 2 or 3 times until nothing could be removed anymore. Not sure why it didn't clean up everything from the first pass.

2. Logs

In my case journal logs (/var/log/journal) used more than 1GB of space. I found a cool thread on Arch forum: Is it safe to delete /var/log/journal log files? -- with two useful commands:

journalctl --disk-usage # See how much space your journal logs  use
systemctl kill --kill-who=main --signal=SIGUSR2 systemd-journald.service # Force journal to execute cleanup procedure

In my case /etc/systemd/journald.conf didn't have any values, so I had to un-comment the defaults and change the following:

SystemMaxUse=16M
ForwardToSyslog=no

After that I tried the second command, which didn't help. Being a dev server, few minutes of downtime are ok so I restarted and then the journal logs are down to ~ 135M now (not sure why not 100M, but I'm happy anyway).

3. Find biggest folders

Cleaning up unused packages and logs didn't free up as much space as I wanted. I wanted to check what folders had biggest disk usage, but I had no idea how to do it. After some searching ended up on How to Find Out Top Directories and Files (Disk Space) in Linux which is exactly what I needed. I used the following command to find top 20 biggest folders in the current directory. I started from root (/) and ended up in /var/lib.

du -hs * | sort -rh | head -n 20

Using this I was able identify other folders that grew out of proportion:

The project I'm working on has inconsistency issues when it comes to coding style. Even though it's a Drupal project, it doesn't follow Drupal's coding standards and on top of that the .php files are saved using various character encoding and line endings. This forced me to develop a workflow that I use before changing legacy files which helped me to keep changes history readable.

Committing together a file encoding change, white-space conversion and a bug-fix will be a source of regret if you ever have to look at that diff again. Most likely you will pull your hair out trying to figure out what is a code change and what's only a code style fix. That's why I separate the coding standard fixes in a single commit before doing anything else. This commits will be easy to ignore when checking history and can provide a cleaner diff for the changes that follow.

The steps I follow are:

One of the features I like in nginx is the ability to disable logging for certain paths. For example whenever a browser sends a requests for a favicon.ico which doesn't exists the web server will respond with a 404 error but will also write the request to access_log and error_log -- which is totally useless. Most of the time nobody cares about these favicon and apple-touch-icon requests, so logging them is quite useless and is just a waste of CPU cycles and IO throughput.

If you use nginx is quite easy to disable logging for them with something like

location = /favicon.ico { 
  access_log off; 
  log_not_found off; 
} 

But Apache is more tricky to set up, the log configuration is not very straightforward. So here is what I was able to find on this subject after some hours of searching.