A pretty awesome feature of any modern hypervisor is the ability to pass through physical devices like USB and PCIe, without using host drivers. Almost any PCIe device can be passed through, including GPUs. There are many guides online discussing GPU passthrough, including this one by @bryansteiner.
GPUs, however, aren't as easy because they are initialised before the operating system starts. Upon boot, the firmware (sometimes called BIOS) initialises the GPU into VGA mode and starts drawing immediately. Any graphical interface (including the Linux console) will be constantly writing frames to the video card. To free up a GPU for use, you can either go purchase and install an additional GPU or instruct the operating system to stop writing to the current one.
I'm not willing to spend on another GPU on my system, therefore I went the latter route. Most guides online mention using two GPUs, but doing so with one GPU will work too by configuring the system over SSH. I used Fedora Server as
A long long long long long time ago, in Talk.CSS #52, Gao Wei presented a talk on Bézier curves "The Obscurities of Bézier Curves Explained to My Computer Engineer Friends". She showed uses of Bézier curves in user interface animations, some rather interesting history about it and explained the mathematics behind it. Watch the meetup on Engineers.SG!
It's actually reasonable to store passwords in a database in plaintext, if your threat model excludes the possibility that an attacker could gain access to your database.
However, the reason for hashing/salting passwords is to account for the scenario that an attacker could gain a copy of the database or read-only access to the database. Have I Been Pwned lists many site breaches that have resulted in plaintext passwords being shared or sold. Many of which were due to unprotected databases, backups and poor access controls.
With a site user's password, an attacker can easily:
Gain access to the user's account on the site
Gain access to the user's accounts on other sites
Note that the first objective is also achievable if the attacker has write access to the accounts database.
A simple defence against exposure of the user's password is to apply an unrecoverable operation on the password before storage. A hash function is such an operation. Hash functions produce a digest fr
I have a Dell U2713HM 27" monitor that has DisplayPort, DVI-D, VGA and HDMI input. I have a dock that only outputs HDMI, so to use my MacBook Pro with the Display I must connect with HDMI. However, the Dell U2713HM can't support its full resolution and frame rate over HDMI. I also previously used SwitchResX but the trial period ended and I am not willing to fork up $23 SGD for something that I can do myself and learn something new in the process.
How a monitor advertises its supported resolutions is by sending EDID metadata to the source. (Read more on Wikipedia) macOS has a feature called EDID overrides that can force a specific display to use a specific resolution. The EDID overrides shipped with macOS is found in /System/Library/Displays/Contents/Resources/Overrides. When a new display is connected, macOS will look in this folder by display vendor and product ID, and if that file exists, it will use the EDID data contained within the file instead of the one sent by th
A lot of our Internet depends on domain names. It's the one source we rely on for verifying authenticity of a website. HTTPS/TLS relies upon users checking the domain of the link they click. I really doubt most users will do so.
This is why Chromium has written guidelines for presenting URLs correctly, to reduce the ability of attacker to present to users a trustworthy-looking URL. There is also an extended document in Chromium source code. However, Chrome hasn't implemented it yet. Disappointing...
Using long URLs that confuse and mislead users is one thing, but someone paying slight attention to the URL may notice. An attacker can go even further by obtaining domains that remove a dot or replace a dot with a dash. Most organisations will not spend the effort to buy up all these variations of their domain, therefore it's possible to register one of them and
This is frequently overlooked because it is uncommon for link
Building your own Linux OS from scratch is no dark magic, believe me! As long as you feel comfortable using a command line, it isn't such a daunting task, only requiring a fair amount of patience.
We'll be setting up an environment, compiling the kernel, userspace tools, a root filesystem and then test booting it. I'll assume you already run Linux on a machine, or in a Virtual Machine. Let's dive right in!
We'll first install the programs necessary for building. All these tools should be available in the major Linux distributions, but I'll only give the commands to install them on Debian/Ubuntu and Alpine Linux.
It is not hard to get your hands dirty on computer networking basics and operating networking equipment. I've been running my own home network for the past 4 years and messing around with IPv6, VLANs and multiple networks, all without expensive racked routers or switches.
The most important device you'll need is a router. Any computer with at least one Ethernet port is already a router. You can even use an old laptop as a router. (It comes with a free keyboard and mouse too!)
Alternatively, if you have an old consumer router and access point combination (wireless router) that comes from your ISP, it too can be used as an advanced router.
Usually, your computer or wireless router won't support advanced features like VLANs and have restrictive configuration options, so software is the next step in getting these devices bend to your will. There are a ton of router operating systems that you can install onto devices, or if you want to spend the extra effort, you can also use a Linux dis
With the new infrastructure, I wanted the entire setup to be reproducible from a set of configuration files and scripts. This would mean that I can restore a fresh state anytime in the future, and provide a way to track changes in configuration. This also means that I can quickly spawn another Kubernetes setup to test new features safely.
Before I created installation automation scripts, I spent a while learning about how Kubernetes works by manually running the generic multi-node scripts Kubernetes provides, and failing repeatedly. A while back Sudharshan gave me one of his old OEM desktops, and it became really useful for testing Kubernetes installs. CoreOS is best installed using a Ignition configuration file. It's a JSON file with a specific format that CoreOS would read on the first boot and install the appropriate files or configurations specified. Usually, it is preferred to write these files in YML and then transpile them to JSON with a special tool. A great thing about CoreOS
Next, you have to get a domain to point to your server. You can get free domains from freenom.tk, or use your dynamic DNS provider. You can test that your domain works by visiting your-domain.com:2015 over mobile
Previously, DNS has been a pain to maintain. I was using a cloud DNS service, so for every subdomain, I would have to log on to CloudNS and use their web interface to update DNS records. This made it hard to switch DNS providers and easily edit records. And their three domain limit made it impossible to add my other domains, thus I had to run another DNS server. I made the decision to run BIND, but I had to run a service to update my zone files when my IP address changes because I didn't purchase a static IP.
To simplify my complex setup, I decided to host all my DNS locally and solve the dynamic IP problem at once. I made the switch from BIND to CoreDNS due to its extensibility. To ensure that parent DNS servers are always pointing to the right IP, I got a couple of free domains (an example is "ns.makerforce-infrastructure.gq") and pointed it to HE's DNS service, where I set up dynamic DNS updates. In my local zone files, I could also use CNAME records to point to the same d