This is definitely not best practice, but on some servers I have some server configuration in Git and I deploy and update them manually. Git is used more as versioning system and less for deployment.
There are two main issue with this approach once you switch to root account (
- you loose you ssh key chain and you can not pull/push changes
- if you commit changes, your Git name and email are empty and using
git configit's not OK since multiple users might do the same thing
It's possible to fix this using sudo by using something like this:
sudo -Es GIT_AUTHOR_NAME=Your\ Name GIT_COMMITTER_NAME=Your\ Name GIT_COMMITTER_EMAILfirstname.lastname@example.org GIT_AUTHOR_EMAILemail@example.com suI added an alias for this and whenever you use the alias, you will forward your ssh key chain and set Git username and password by send temporary environment variables.
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.
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 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.
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 is 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 have already 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 using 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.
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:
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: