CMCDragonkai

Understanding the Memory Layout of Linux Executables

Required tools for playing around with memory:

• hexdump
• objdump
• readelf
• xxd
• gcore

CMCDragonkai

Rust/Haskell: Higher-Kinded Types (HKT)

A higher kinded type is a concept that reifies a type constructor as an actual type.

A type constructor can be thought of in these analogies:

• like a function in the type universe
• as a type with a "hole" in it

CMCDragonkai

File/Directory Attributes on ls, gci, dir or Get-ChildItem

Powershell allows you to use ls (and related) commands to view your files and directories.

# list files/directories at current working directory
ls
# show hidden files and protected operating system files as well!

CMCDragonkai

Regular Expression Engine Comparison Chart

Many different applications claim to support regular expressions. But what does that even mean?

Well there are lots of different regular expression engines, and they all have different feature sets and different time-space efficiencies.

The information here is just copied from: http://regular-expressions.mobi/refflavors.html

CMCDragonkai

SQL Foreign Key Relationships

We can use foreign keys to represent:

• 1 - 1 (invertible injective relationship a.k.a. bijective relationship)
• 1 - 0,1 (partially injective relationship or partially surjective relationship)
• 1 - * (0 or more)
• 1 - + (1 or more)
• M - N

CMCDragonkai

Understanding Nix Inputs

Every Nix derivation produces a Nix store output that has 3 things:

• Executables
• Libraries
• Data

Executables are always exported using the PATH environment variable. This is pretty much automatic.

CMCDragonkai

HTTP Streaming (or Chunked vs Store & Forward)

The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.

However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on

CMCDragonkai

Building a Nix Package (The C&C++ Version)

Nix can be used to build any kind of package. But here I'm just going to focus on the simple C&C++ case.

Firstly we have to know that the final built packages will located inside /nix/store. Which is globally readable directory of all build inputs and build outputs of the Nix system. The emphasis is on readable, not writable, that is /nix/store is meant to be modified by the user or programs except for the Nix system utilities. This centralises the management of packages, and keeps our packages and package configuration consistent.

So what exactly are we trying to build. Our goal is to build a directory that will be located in /nix/store/*-package-version/, where * is the hash of the package. Preferably a version is also available, but some C&C++ packages don't have versions, so in that case, there's only /nix/store/*-package/.

What will be inside this directory? It follows the GNU Coding Standards descri

CMCDragonkai

from osgeo import gdal, ogr

def clone_data_to_mem(ds, name=''):
  if (isinstance(ds, gdal.Dataset)):
    return clone_raster_to_mem(ds, name)
  elif (isinstance(ds, ogr.DataSource)):
    return clone_vector_to_mem(ds, name)
  else:
    raise TypeError('Data source must be of GDAL dataset or OGR datasource')

CMCDragonkai

Linux Kernel Modules for NixOS

You can find what kernel modules are loaded using lsmod.

However some kernel modules are required at stage 1 boot. Basically preloaded in the initial ram disk before switching to the root filesystem. These kernel modules are mostly needed to deal with peripherals, storage devices, filesystems and network devices. You may need to be wary of these required modules:

• sd_mod - SCSI, SATA, and PATA (IDE) devices