chore: fix broken links
This commit is contained in:
parent
1fde207c5a
commit
d468e5cd4c
14 changed files with 48 additions and 75 deletions
|
|
@ -3,8 +3,6 @@ tags:
|
|||
- git
|
||||
---
|
||||
|
||||
# Rebasing
|
||||
|
||||
Rebasing is a way to integrate changes from one branch into another. In this
|
||||
regarding it is like merging a branch B into another branch A. However rebasing
|
||||
differs from normal merging in the way in which it modifies the Git history.
|
||||
|
|
@ -127,11 +125,11 @@ request.
|
|||
## Difference from cherry-picking
|
||||
|
||||
The main difference between the two approaches is that
|
||||
[cherry-picking](Cherry_picking_a_branch.md) is a more selective
|
||||
process, where you can pick and choose specific commits that you want to include
|
||||
in another branch. This can be useful when you only want to apply specific
|
||||
changes or fixes from one branch to another, without including all the changes
|
||||
made in the original branch.
|
||||
[cherry-picking](/zk/Cherry_picking.md) is a more selective process, where you
|
||||
can pick and choose specific commits that you want to include in another branch.
|
||||
This can be useful when you only want to apply specific changes or fixes from
|
||||
one branch to another, without including all the changes made in the original
|
||||
branch.
|
||||
|
||||
On the other hand, rebasing is a more comprehensive process that can include all
|
||||
the changes from one branch to another, but it modifies the commit history,
|
||||
|
|
|
|||
10
zk/HTTPS.md
10
zk/HTTPS.md
|
|
@ -3,8 +3,6 @@ tags: [world-wide-web, internet, encryption, servers]
|
|||
created: Friday, December 14, 2024
|
||||
---
|
||||
|
||||
# HTTPS
|
||||
|
||||
The problem with standard, unencrypted HTTP requests is that the data can be
|
||||
captured in transit and be observed or modified by malicious actors.
|
||||
|
||||
|
|
@ -17,10 +15,10 @@ It utilises two types of encryption to send messages securely:
|
|||
- a single shared key between client and server to encrypt the messages sent
|
||||
between them
|
||||
- asymmetric encryption
|
||||
- two keys are used: a [public key](./bbdcb54f_public_key_cryptography.md) to
|
||||
encrypt the data and a private key to decrypt it. The public key can be
|
||||
shared freely so anyone can encrypt and send data to a peer but only the
|
||||
peer can receive and decrypt it
|
||||
- two keys are used: a [public key](/zk/Public_key_cryptography.md) to encrypt
|
||||
the data and a private key to decrypt it. The public key can be shared
|
||||
freely so anyone can encrypt and send data to a peer but only the peer can
|
||||
receive and decrypt it
|
||||
|
||||
> Symmetric encryption applies once the server has been authenticated and its
|
||||
> public key has been shared with the client. Asymmetric encryption applies at
|
||||
|
|
|
|||
|
|
@ -3,9 +3,7 @@ tags: [internet, ARPANET, ARPA]
|
|||
created: Monday, October 28, 2024
|
||||
---
|
||||
|
||||
# 4a3dc316_key_figures_ARPANET
|
||||
|
||||
- [Paul Baran](385af4b4_Baran_distributed_networks.md) for his work at RAND on
|
||||
- [Paul Baran](/zk/Baran_distributed_networks.md) for his work at RAND on
|
||||
distributed networks as an alternative to the extant
|
||||
centralised/de-centralised phone networks.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ tags: [logic-gates, binary, memory]
|
|||
The **combinatorial digital circuits** we have looked at so far have been
|
||||
non-sequential. The outcome is a function of its immediate set of inputs and
|
||||
everything happens at once: there is no means of storing state for future use.
|
||||
In other words there is no _[memory](Memory.md)_.
|
||||
In other words there is no memory.
|
||||
|
||||
In contrast, the output of a **sequential digital circuit** depends not only on
|
||||
its present set of inputs but also on past inputs to the circuit. It has some
|
||||
|
|
@ -49,8 +49,7 @@ _The representation of an SR Latch in a digital circuit diagram_:
|
|||
|
||||
The circuit diagram latch symbol obviously encapsulates more complex
|
||||
functionality that occurs at the sub-circuit level. We will demonstrate how this
|
||||
functionality can be achieved with two
|
||||
[NOR](Logic_gates.md#nor-gate) gates.
|
||||
functionality can be achieved with two [NOR](Logic_gates.md#nor-gate) gates.
|
||||
|
||||
The two gates are in a **cross-coupled configuration**. This basically means
|
||||
that the wires are crossed back on themselves such that the output of one is
|
||||
|
|
|
|||
|
|
@ -11,10 +11,9 @@ tags:
|
|||
|
||||
### `top`/`htop`
|
||||
|
||||
We can use [ps](Processes.md) to list the
|
||||
currently running processes but it does not provide much information about the
|
||||
resource metrics or how the process changes over time. We can use `top` to get
|
||||
more information.
|
||||
We can use [ps](Processes.md) to list the currently running processes but it
|
||||
does not provide much information about the resource metrics or how the process
|
||||
changes over time. We can use `top` to get more information.
|
||||
|
||||
`top` provides an interactive interface for the information that `ps` displays.
|
||||
It updates in real time and shows the most active processes based on the CPU
|
||||
|
|
@ -60,9 +59,8 @@ _Here I have pressed `u` to show only the processes associated with my user:_
|
|||
$ renice 20 1234
|
||||
```
|
||||
- `VIRT`
|
||||
- The total amount of
|
||||
[virtual memory](Virtual_memory_and_the_MMU_in_Linux.md) used by
|
||||
the process including: program code, data, shared libraries, pages that have
|
||||
- The total amount of [virtual memory](/zk/VirtualMemory.md) used by the
|
||||
process including: program code, data, shared libraries, pages that have
|
||||
been swapped, pages that have been mapped but not used.
|
||||
- `RES`
|
||||
- Stands for _resident size_
|
||||
|
|
@ -110,9 +108,8 @@ procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
|
|||
- Total amount of virtual memory in the
|
||||
[cache](Role_of_memory_in_computation.md#relation-between-cache-and-buffers)
|
||||
- `swap`
|
||||
- Distinguishes amount of memory
|
||||
[swapped](Swap_space.md) in (`si`) to memory and
|
||||
swapped out (`so`) to disk
|
||||
- Distinguishes amount of memory [swapped](Swap_space.md) in (`si`) to memory
|
||||
and swapped out (`so`) to disk
|
||||
- `io`
|
||||
- Disk actions
|
||||
- Amount of data read from harddisk (`bi`)
|
||||
|
|
@ -136,8 +133,8 @@ gives me some useful info about which files VS Code is using:
|
|||
## System calls: `strace`
|
||||
|
||||
A system call is when a process requests a service from the
|
||||
[kernel](The_kernel.md), for instance an I/O operation to
|
||||
memory. We can trace these system calls with `strace`.
|
||||
[kernel](The_kernel.md), for instance an I/O operation to memory. We can trace
|
||||
these system calls with `strace`.
|
||||
|
||||
## CPU performance
|
||||
|
||||
|
|
@ -168,8 +165,8 @@ $ uptime
|
|||
|
||||
We know that processes primarily interact with virtual memory in the form of
|
||||
pages which are then translated to physical blocks by the kernel via the
|
||||
[MMU](Virtual_memory_and_the_MMU_in_Linux.md). There are several tools
|
||||
which provide windows onto this process.
|
||||
[MMU](Virtual_memory_and_the_MMU_in_Linux.md). There are several tools which
|
||||
provide windows onto this process.
|
||||
|
||||
### System page size
|
||||
|
||||
|
|
|
|||
|
|
@ -8,12 +8,11 @@ tags:
|
|||
|
||||
<img src="../img/motherboard-pi.jpg" width="400px"/>
|
||||
|
||||
|
||||
|
||||
The motherboard is the foundation of a computer. It allocates power and allows
|
||||
communication to and between the
|
||||
[CPU](CPU_architecture.md),
|
||||
[RAM](Memory.md),
|
||||
[harddisk](What_are_disks.md) and all other hardware
|
||||
components.
|
||||
communication to and between the [CPU](CPU_architecture.md), memory,
|
||||
[harddisk](What_are_disks.md) and all other hardware components.
|
||||
|
||||
It is a printed circuit board and is always the largest board within the
|
||||
computer chassis.
|
||||
|
|
|
|||
|
|
@ -9,10 +9,9 @@ tags:
|
|||
> key is one **field that uniquely identifies each record**.
|
||||
|
||||
This is essential for carrying out operations across database tables and for
|
||||
creating and deleting database entires in accordance with the
|
||||
[ACID principle](ACID_principle.md). It is also a safeguard: it means
|
||||
you can always identify a record by itself and don't have to rely on generic
|
||||
queries to identify it.
|
||||
creating and deleting database entires in accordance with the ACID principle. It
|
||||
is also a safeguard: it means you can always identify a record by itself and
|
||||
don't have to rely on generic queries to identify it.
|
||||
|
||||
Sometimes you will have a dedicated field such as `UNIQUE_ID` for the unique
|
||||
key. Other times you can use an existing field to fulfil that function. When an
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ AWS to simplify the process of building, deploying and managing serverless
|
|||
applications. It provides a concise syntax for defining the components of a
|
||||
serverless application, such as
|
||||
[Lambda functions](zk/Lambda_programming_model.md),
|
||||
[API gateway](/zk/AWS_API_Gateway.md) and database tables.
|
||||
[API gateway](/zk/API_Gateway.md) and database tables.
|
||||
|
||||
The SAM infrastructure is defined in a YAML file which is then deployed to AWS.
|
||||
SAM syntax gets transformed into CloudFormation during the deployment process.
|
||||
|
|
@ -239,8 +239,8 @@ receive one file as an input. The packaging process consists in creating that
|
|||
single file.
|
||||
|
||||
The packaging proces will first archive all of the project artefacts into a zip
|
||||
file and then upload that to [S3](zk/AWS_S3.md). A reference to this S3 entity
|
||||
is then provided to CloudFormation.
|
||||
file and then upload that to [S3](/zk/S3.md). A reference to this S3 entity is
|
||||
then provided to CloudFormation.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags: [Linux, networks]
|
|||
created: Wednesday, June 12, 2024
|
||||
---
|
||||
|
||||
# Set DNS settings
|
||||
|
||||
## Change the default DNS server
|
||||
|
||||
On Arch and most modern Linux distributions domain name resolution is handled
|
||||
|
|
@ -62,8 +60,3 @@ nameserver 192.168.0.4
|
|||
nameserver fded:2060:8671:0:681:9bff:fe9b:37f0
|
||||
|
||||
```
|
||||
|
||||
## Related notes
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -19,10 +19,8 @@ transitions between them. It also includes error catchers and retry logic.
|
|||
|
||||
At the beginning you define a `StartAt` state which is the entrypoint of the
|
||||
state machine. This can be manually triggered, or more likely, triggered by
|
||||
another AWS service such as a
|
||||
[Lambda](Lambda_programming_model.md), an
|
||||
[API Gateway](AWS_API_Gateway.md) request or a messaging/queue
|
||||
event.
|
||||
another AWS service such as a [Lambda](Lambda_programming_model.md), an
|
||||
[API Gateway](/zk/API_Gateway.md) request or a messaging/queue event.
|
||||
|
||||
The state machine ultimately ends at an end state. In between are various
|
||||
intermediary states which can include:
|
||||
|
|
|
|||
|
|
@ -5,14 +5,12 @@ tags:
|
|||
|
||||
# Handling streams with fs
|
||||
|
||||
When reading from a file, the
|
||||
[`fs.readFile()`](fs.md) method waits
|
||||
until the entire file has been read before executing the callback. It's obvious
|
||||
why this might not be ideal in certain cases. If the file is very large you are
|
||||
utilising a lot of [memory](Memory.md) for a
|
||||
single process. Additionally, the data you need might appear early in the file,
|
||||
in which case, once you find the data you want, there is no need to read to the
|
||||
end of the file.
|
||||
When reading from a file, the [`fs.readFile()`](fs.md) method waits until the
|
||||
entire file has been read before executing the callback. It's obvious why this
|
||||
might not be ideal in certain cases. If the file is very large you are utilising
|
||||
a lot of memory for a single process. Additionally, the data you need might
|
||||
appear early in the file, in which case, once you find the data you want, there
|
||||
is no need to read to the end of the file.
|
||||
|
||||
> An example of this in practice is watching a Netflix film: we don't have to
|
||||
> wait for the whole film to download, we can start watching it immediately
|
||||
|
|
|
|||
|
|
@ -341,7 +341,6 @@ the ABC to make ENIAC.
|
|||
next problem
|
||||
|
||||
- ISP removed the friction:
|
||||
|
||||
- the instructions comprising the program would be prepared on tape or punched
|
||||
cards and read into electronic memory
|
||||
- the hardware configuration of the machine would remain the same accross
|
||||
|
|
@ -382,7 +381,7 @@ variety of different electronic methods for memory:
|
|||
|
||||
- An experimental computer intended to create the
|
||||
[von Neumann architecture](CPU_architecture.md) using
|
||||
[Williams_Tube_RAM](Williams_Tube_RAM.md)
|
||||
[Williams_Tube_RAM](/zk/Williams_Tube_memory.md)
|
||||
|
||||
- Developed at the Univesity of Manchester and completed in 1948.
|
||||
|
||||
|
|
@ -407,7 +406,6 @@ variety of different electronic methods for memory:
|
|||
university departments who were expected to program it themselves. To this
|
||||
end, a formal programming paradigm was forged for the EDSAC which established
|
||||
the following:
|
||||
|
||||
- subroutines as a library of common procedures available to programmers (e.g.
|
||||
printing a result, reading input tape, program checking, mathematical
|
||||
operations)
|
||||
|
|
|
|||
|
|
@ -3,12 +3,10 @@ tags: [cryptography, encryption]
|
|||
created: Friday, December 20, 2024
|
||||
---
|
||||
|
||||
# a4601796_trapdoor_functions
|
||||
|
||||
How does [public key cryptography](./bbdcb54f_public_key_cryptography.md)
|
||||
achieve the feat of making the encyrpted data only decipherable in one
|
||||
direction. In other words how come the same data can be encrypted with one key
|
||||
but only decryptable by another?
|
||||
How does [public key cryptography](/zk/Public_key_cryptography.md) achieve the
|
||||
feat of making the encyrpted data only decipherable in one direction. In other
|
||||
words how come the same data can be encrypted with one key but only decryptable
|
||||
by another?
|
||||
|
||||
It is acheived by the use of **trapdoor functions**. These are functions that
|
||||
are easy to compute in one direction but extremely difficult to reverse. But
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ and wanted a way to communicate with each other.
|
|||
|
||||
## Technology
|
||||
|
||||
Usenet comprised a [distributed network](385af4b4_Baran_distributed_networks.md)
|
||||
of dedicated servers that exchanged messages over the **Network News Transfer
|
||||
Usenet comprised a [distributed network](/zk/Baran_distributed_networks.md) of
|
||||
dedicated servers that exchanged messages over the **Network News Transfer
|
||||
Protocol** (NNTP).
|
||||
|
||||
A user would post a message to their local news server. The server would assign
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue