Typically a Linux operating system will create and use a swap partition that’s resident on the hard drive, and this would act as an extension to system memory. The swap partition and system memory are abstracted into a single virtual memory space, but the kernel, by default, will usually read and write data between the two in 4KB ‘pages’.
I’ve only recently had a personal laptop with an SSD (which can’t easily be replaced), and it occurred to me that having data paged continually to a partition might reduce its lifespan.
In the last post, I covered some very basic stuff for editing text in Vim. There are a few more advanced features I picked up while using it as an actual code editor.
Basic keybindings Use ‘Esc’ key to enter visual mode.
Select text, use ‘v’ and ‘Ctrl+Right’ Cut text: ‘d’ Copy text: ‘y’ Paste text: ‘p’ Line numbers Either use the :set number command, or add it to /etc/vim/vimrc.
Lenovo Thinkpads have historically been the ideal hardware for running Linux, so I was initially optimistic about replacing Chrome OS on a sightly older (but relatively decent spec) laptop. Unfortunately it turned out the laptop was a Chromebook, and the vendor (Google, I’m guessing) really didn’t want anyone replacing the operating system. I spent a few hours looking for ways around that.
The operating system I installed was Debian 13.2.0 (Cinnamon edition), and the installation media was prepared by using Rufus to flash the debian-live-13.
While everything in a Tails OS session is wiped from system memory after the laptop is switched off, the option to store data persistently in an encrypted partition (the Persistent Storage) is a critical feature for users, such as journalists, who, for example, need to create notes, save material and draft reports during a session.
The encryption used for this - LUKS - is the standard for disk and volume encryption in Linux.
One of the useful little applications that’s included with Tails OS is OnionShare, which enables the sharing of things on the .onion domain and the creation of hidden services. I think these are important options to have in a Tails-like setup.
Our freedom of expression, in practice, isn’t defined by laws or constitutions. It’s instead defined by what corporations’ terms of service and whatever arbitrary extra-legal pressures they’re subject to. And, unfortunately this applies to almost everything on the conventional Web, since almost everything is dependent on third party.
Though my views aren’t as extreme as Richard Stallman’s, he does have a point: A decade ago we’d be up in arms about relatively trivial privacy-invading crap in operating systems, but it’s since become the norm, with most smartphones and laptops having things pre-installed that send personal data in the background to Google, Microsoft and whichever assortment of corporations. A state of affairs brought about by a confluence of what we collectively surrendered for convenience.
{{ Repost from my WordPress site. The information might be slightly outdated. }}
On the surface, FreeBSD is almost identical to Linux. The difference is that, like Arch Linux, the base installation doesn’t have the features or configuration that something like Ubuntu provides for non-technical users.
This post goes through my process of getting FreeBSD running with a full desktop environment. It should take a couple of hours at most, starting with a basic installation disc or ISO.
{{ Repost of my WordPress article, for reference. Might be slightly outdated. }}
Patching, a properly configured firewall and updated anti-malware protection will prevent 99% of security threats. Fortunately all three can be readily added to a FreeBSD installation, and there are some other native features in this operating system that can provide pretty solid security.
The most important things, in my opinion, are exploit prevention and mitigation – that is, making it hard as possible for something to exploit software vulnerabilities, and restricting what an exploit could do if executed.
!!! info Original post on my WordPress site
The Scenario The following is a summary of what’s presented in the case study. It begins with the discovery of the following in file inetd.conf on a workstation running Red Hat Linux:
netstat stream tcp nowait root /usr/lib/netstat netstat A graphical CPU load monitor showed 100% load, the top command indicated only 90%, and there were apparently no running processes listed that accounted for the discrepancy.
