Oren’s Tech Blog RSS Feed

The Irrational Square Root of Two

Sat, 14 Mar 2026 06:47:00 GMT

Happy $\pi$ day!

Here I will prove that no rational number, when squared, can equal $2$ .

A rational number is defined as a number $p=\frac {m}{n}$ such that $n\ne0$ and $m$ , $n$ are in lowest terms, meaning their greatest common divisor is $1$ :

gcd(m,n)=1

Another way to say this is that $m$ and $n$ are not both even numbers. If they were both even then $gcd(m,n)\ge2$ .

First we’ll do a little groundwork to set the scene.

Even and Odd Squares

An even number is defined as any number that is a multiple of $2$ and can be written as $2x$ . An odd number is any number that can be written as $2x+1$ .

An interesting property of the even numbers is that any time you square an even number, you get another even number.

We can show this by squaring an even number $2a$ :

(2a)^2 = 4a^2 = 2(2a^2)

Since $(2a)^2$ is in the form of $2x$ , this shows that it is even.

Similarly, the square of an odd number $2a+1$ is odd:

(2a+1)^2 = 2(2a^2+2a) + 1

Since $(2a+1)^2$ is in the form of $2x+1$ where $x=2a^2+2a$ then $(2a+1)^2$ is odd.

With these two facts in hand, we can prove that if $x^2$ is even then $x$ is even.

“if $x$ then $y$ ” can be written as $x \implies y$ , read “x implies y”.

The contrapositive of “P implies Q” is “not Q implies not P”, and they are logically equivalent.

Since “not even” is “odd” and “not odd” is “even”, the contrapositive of $x$ is even $\implies$ $x^2$ is even is:

$x^2$ is odd $\implies$ $x$ is odd

Similarly, the contrapositive of $x$ is odd $\implies$ $x^2$ is odd is:

$x^2$ is even $\implies$ $x$ is even.

The Proof

We can prove by contradiction by assuming there is a rational number $p=\sqrt2$

Substituting $p$ with $\frac{m}{n}$ and squaring both sides we get:

p^2 = (\frac{m}{n})^2 = \frac{m^2}{n^2} = 2

Multiplying both sides by $n^2$ we get:

m^2 = 2n^2

Since $m^2$ is in the form of $2x$ , $m^2$ is by definition an even number.

Based on what we proved above, $m^2$ is even implies that $m$ is even.

And since $m$ is even, we can write it as $m=2k$ . Then:

m^2 = (2k)^2 = 4k^2 = 2n^2

Dividing both side by $2$ we get:

2k^2 = n^2

Since $n^2$ is in the form of $2x$ , this implies that $n^2$ is even and therefore $n$ is even, which means that $m$ and $n$ are not in lowest terms!

Conclusion

I’ve shown that $m$ and $n$ are both even, meaning they share a factor of 2 and $gcd(m,n) \ne 1$ which contradicts the initial assumption that $m/n$ is fully reduced. Therefore no such rational $p$ exists and $\sqrt2$ is irrational.

Search your command history with fzf

Sat, 16 Sep 2023 10:00:00 GMT

Try using history with fzf to search your shell history and find old commands:

Copy

history -f | fzf

history -f will print out a timestamp along with the command so you know when you last used it.

Building llama.cpp on a Windows Laptop

Thu, 07 Sep 2023 00:00:00 GMT

The following steps were used to build llama.cpp and run a llama 2 model on my Dell XPS 15 laptop running Windows 10 Professional Edition laptop.

For what it’s worth, the laptop specs include:

Intel Core i7-7700HQ 2.80 GHz
32 GB RAM
1TB NVMe SSD
Intel HD Graphics 630
NVIDIA GeForce GTX 1050

This guide is based off the following hacker news comment:

https://news.ycombinator.com/item?id=36871730

Run powershell as an Administrator
Install chocolatey
Install git:

Copy
```
choco install git
```

Clone the llama.cpp repository locally:

Copy

git clone https://github.com/ggerganov/llama.cpp

Install CMake for windows
Install Visual Studio Community Edition. Make sure to add the “Desktop development with C++” workload for core C and C++ support.
Install the NVIDIA Cuda toolkit
Download llama 2 model from here: ~~https://huggingface.co/TheBloke/Llama-2-13B-chat-GGML/resolve/main/llama-2-13b-chat.ggmlv3.q4_0.bin~~ (see discussion here) https://huggingface.co/TheBloke/Llama-2-13B-chat-GGUF/resolve/main/llama-2-13b-chat.Q5_K_M.gguf. Note the location where the file is downloaded.
In the llama.cpp repo, make a subdirectory and change into it:

Copy
```
mkdir build
cd build
```

Prepare the llama.cpp build using:

Copy

cmake .. -DLLAMA_CUBLAS=ON

Here is the full output of the build:

Copy

PS C:\Users\orenf\llama.cpp\build> cmake .. -DLLAMA_CUBLAS=ON
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
-- The C compiler identification is MSVC 19.37.32822.0
-- The CXX compiler identification is MSVC 19.37.32822.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.37.32822/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.42.0.windows.1")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Found Threads: TRUE
-- Found CUDAToolkit: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v12.2/include (found version "12.2.140")
-- cuBLAS found
-- The CUDA compiler identification is NVIDIA 12.2.140
-- Detecting CUDA compiler ABI info
-- Detecting CUDA compiler ABI info - done
-- Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v12.2/bin/nvcc.exe - skipped
-- Detecting CUDA compile features
-- Detecting CUDA compile features - done
-- Using CUDA architectures: 52;61;70
-- CMAKE_SYSTEM_PROCESSOR: AMD64
-- x86 detected
-- Configuring done (34.7s)
-- Generating done (0.7s)
-- Build files have been written to: C:/Users/orenf/llama.cpp/build

To build the release binary run:

Copy
```
cmake --build . --config Release
```
Once it finishes building, run the model specifying the absolute path to the model:

Copy
```
 .\main.exe -m <Downloads location>\llama-2-13b-chat.Q5_K_M.gguf --color -p 'tell me some cool facts' 2> $null
```
Note: the 2> $null is used to suppress the debugging output.

Here was the response:

Here are some cool facts about the human brain:

Your brain is made up of about 100 billion neurons, which are specialized cells that process and transmit information. Each neuron has an average of 7,000 synapses, or connections to other neurons, making the total number of synapses in the human brain around 1 quadrillion (1,000 trillion).
The human brain is incredibly energy-hungry, consuming about 20% of the body’s entire energy expenditure. To put that in perspective, your brain uses more energy than your heart does.
Your brain weighs about 1.4 kilograms (3 pounds), but it makes up only about 2% of your body weight. Despite its small size, it contains over 100,000 kilometers (62,000 miles) of blood vessels, which is enough to circle the Earth four times.
The human brain is incredibly resilient and can survive for up to five minutes without oxygen before suffering permanent damage. This is because brain cells are highly adaptable and can switch to alternative sources of energy when needed.
Your brain has a unique “fingerprint” that is made up of the patterns of nerve fibers in your brain. This fingerprint can be used to identify you, much like a fingerprint on a crime scene.
The human brain is incredibly flexible and can rewire itself in response to changes in your life. This process, known as neuroplasticity, allows for the recovery of lost functions, such as language skills after a stroke, and can even help you learn new skills like playing a musical instrument.
Your brain has a specialized system for recognizing and remembering faces, known as the fusiform face area. This system is so powerful that it can recognize faces in just 100 milliseconds (a tenth of a second), even if the face is upside down or partially obscured.
The human brain has a built-in “default mode network” that helps you daydream and think about the future. This network is active when your mind is at rest, and it allows for the creation of mental scenarios and stories that help you plan and prepare for the future.
Your brain has a specialized system for processing music, known as the auditory cortex. This system is highly developed in humans and is responsible for our ability to appreciate and understand complex musical patterns.
The human brain contains around 100 billion neurons, each of which can form thousands of connections with other neurons. This incredible complexity is what gives you your unique thoughts, feelings, and experiences.

New RSS feed for my blog

Tue, 05 Sep 2023 00:00:00 GMT

An RSS feed, which stands for Really Simple Syndication or Rich Site Summary, is a standardized format for delivering regularly updated web content. It allows users to subscribe to websites, blogs, news sources, and other online publications and receive automatic updates whenever new content is published. RSS feeds are typically in XML format and provide information about the content, such as the title, summary, publication date, and a link to the full article or post.

This website now publishes an RSS Feed to the rss.xml file here.

Enjoy staying up to date with my latest content!

My Zoom-based Hebrew Lessons

Mon, 04 Sep 2023 00:00:00 GMT

This is an app I created several years ago when I was teaching Hebrew school over zoom. It allows teachers to have interactive instruction with kids as they take turns reading the hebrew letters, words, and phrases.

Click Here for Hebrew Lessons

Instructions:

Select a Lesson from the dropdown at the top of the screen.
Add your students names
Click Next Challenge or Random Challenge to present a challenge to a student

Optionally:

you can pass onto another student using the Let another student try button
Click Display Cheatsheet to show the Hebrew letters and vowels

The source code for this application is available here on GitHub.

בהצלחה!

(good luck!)

Terraform State Surgery

Mon, 14 Aug 2023 00:00:00 GMT

The Condition

For users of the AWS Terraform Provider, using an aws_security_group resource to declare security group rules as inline blocks (known as Attributes-as-Blocks) can lead to painful consequences.

For example, if you wanted to add a rule to a particular security group, you would not be able to export the security group from the module and attach a rule directly to it since inline rules and standalone aws_security_group_rules will conflict with each other.

The terraform documentation for security group rules acknowledges this and explains that you can safely use one or the other but not both:

Terraform currently provides both a standalone Security Group Rule resource (a single ingress or egress rule), and a Security Group resource with ingress and egress rules defined in-line. At this time you cannot use a Security Group with in-line rules in conjunction with any Security Group Rule resources. Doing so will cause a conflict of rule settings and will overwrite rules.

Using inline ingress and egress security group rules causes a condition that complicates our ability to add rules outside of the module. If we elect to refactor the module to use standalone aws_security_group_rule resources, we can avoid future complications.

The Correction

Refactoring the security group module involves removing inline attributes as blocks and then replacing them with standalone resources.

For example, this security group module (called old_sg_module) consists of an aws_security_group resource with dynamic inline ingress rules:

Copy

resource "aws_security_group" "sg" {
  name        = "the security group"

  dynamic "ingress" {
    for_each = ...
    content {
      from_port   = ...
      to_port     = ...
      protocol    = ...
      cidr_blocks = ...
      description = "ipv4 cidrs"
    }
  }
}

We can refactor this module to use standalone resources instead of dynamic attribute blocks (and call it new_sg_module):

Copy

resource "aws_security_group" "sg" {
  name        = "the security group"
}

resource "aws_security_group_rule" "ipv4_cidrs" {
  for_each          = ...
  type              = "ingress"
  from_port         = ...
  to_port           = ...
  protocol          = ...
  cidr_blocks       = ...
  description       = "ipv4 cidrs"
  security_group_id = aws_security_group.sg.id
}

The module has now been refactored to create standalone security group rules that ostensibly provide redundancy for the previous inline rules. Unfortunately, migrating to this new module is not as simple as applying it directly.

The Complication

Even though it looks like we can safely provision the new rules, if we try to run terraform apply with the new module then we see the following error:

Copy

╷
│ Error: [WARN] A duplicate Security Group rule was found on (sg-0325937ab0b75e23d). This may be
│ a side effect of a now-fixed Terraform issue causing two security groups with
│ identical attributes but different source_security_group_ids to overwrite each
│ other in the state. See https://github.com/hashicorp/terraform/pull/2376 for more
│ information and instructions for recovery. Error: InvalidPermission.Duplicate: the specified rule "peer: 172.31.1.15/32, TCP, from port: 443, to port: 443, ALLOW" already exists
│       status code: 400, request id: 7138a67d-626a-45fe-9abd-38896e5d2128
│ 
│   with module.security_group.aws_security_group_rule.ipv4_cidrs["0"],
│   on new_sg_module/main.tf line 10, in resource "aws_security_group_rule" "ipv4_cidrs":
│   10: resource "aws_security_group_rule" "ipv4_cidrs" {
│ 
╵

Running terraform apply directly with the refactored module will not work because the AWS provider is trying to provision rules that already exist. This is because security group rules are identified as a string containing the attributes of the security group.

For example, take a look at the provider code here. This shows examples of how the rules are identified internally as strings that concatenate the security group id, the type, the protocol, the to/from ports, and any source/destination ipv4/ipv6 CIDRs, security groups, or prefix lists:

Copy

sg-09a093729ef9382a6_ingress_tcp_8000_8000_10.0.3.0/24
sg-09a093729ef9382a6_ingress_92_0_65536_10.0.3.0/24_10.0.4.0/24
sg-09a093729ef9382a6_egress_tcp_8000_8000_10.0.3.0/24
sg-09a093729ef9382a6_egress_tcp_8000_8000_pl-34800000
sg-09a093729ef9382a6_ingress_all_0_65536_sg-08123412342323
sg-09a093729ef9382a6_ingress_tcp_100_121_10.1.0.0/16_2001:db8::/48_10.2.0.0/16_2002:db8::/48

Security group rules are defined by these parameters and will have a naming collision when identical rules are provisioned since they already exist as inline rules in the security groups.

One rough solution would be to rip out all the security groups and rules in AWS and reprovision them with the new module, leading to downtime in production.

A more elegant solution would be to surgically manipulate only the terraform state without affecting anything in AWS in order to achieve a zero-downtime transtion.

Here is the choice: Either bite the bullet and incur painful downtime by destroying and recreating the infrastructure, or employ the terraform state and terraform import commands to make precise state changes for a painless, zero-downtime migration.

Since hard things are the only things worth doing, we’re going to go the zero-downtime route and manipulate the state using our precision tooling. Indeed, this can be a tricky operation and I’ve heard it called Terraform State Surgery.

The Surgical Plan

Now we see that the security groups will need to be surgically separated from the inline rules in order to make the terraform state match reality. Here is a high level overview of the steps we’ll need to take to restore the integrity of the terraform state:

Remove the security groups from state: Removing the aws_security_group resources from the state will remove the bond between the security group and the inline rules.
Import the individual rules to the state: Next we need to import the existing rules into the standalone aws_security_group_rule resources.
Import the security groups back to the state again: Finally, importing the security groups again will exclude the rules that were imported already into standalone resources.

By utilizing the current and planned states, we can render the terraform commands needed to execute this operation.

Preoperative Staging

First we’ll need to get the current terraform state as JSON and write to a file current_state.json:

Copy

terraform show -json > current_state.json

Getting the planned state involves writing out the plan to the file out.tfplan, converting it to JSON, and write to a file planned_state.json:

Copy

terraform plan -var-file=vars.tfvars -out=out.tfplan
terraform show -json out.tfplan > planned_state.json

Lastly, we’ll cache the JSON representations of the security groups that we will be removing from and then importing back to the state using the file sgs.json. To do this we will need to recursively descend into the current state and search for aws_security_group resources named sg:

Copy

jq -r \
'.. | select((type == "object") and (.type == "aws_security_group") and (.name == "sg"))' \
< current_state.json > sgs.json

Now that we have those three items, we are ready to begin.

The Procedure

Now we have the current state, the planned state, and the cached existing security groups in JSON. We are going to use jq to render the terraform CLI commands that will migrate us to using the new module.

The first step is removing the existing security groups from the state.

Copy

jq -r '@sh "terraform state rm \(.address)"' < sgs.json

This will render the following command:

Copy

terraform state rm \
'module.security_group.aws_security_group.sg'

Running this command will remove the resource with address module.security_group.aws_security_group.sg from the terraform state.

The next step is to import all the security group rules into their own standalone resources. This will use a somewhat beefy jq filter on the planned state that we can cache in a file called filter.jq:

Copy

.resource_changes[] 
| select((.type == "aws_security_group_rule") and (.change.actions[] == "create")) 
| {address} + .change.after 
| {address} + {id: [.security_group_id, .type, .protocol, (.from_port|tostring), (.to_port|tostring), .cidr_blocks // .ipv6_cidr_blocks // .source_security_group_id // .prefix_list_ids] 
| flatten 
| join("_")} 
| @sh "terraform import -var-file=vars.tfvars \(.address) " + .id

Here is what this filter is doing:

filter out the resource changes that involve creating aws_security_group resources
compose a new object that includes the rule details and the terraform resource address
join the details of the security group rule with underscores to generate the string identifier discussed above
render the terraform import command used to import the security group rule

This filter can be executed on the planned state as follows:

Copy

jq -r -f filter.jq < planned_state.json

Which renders the commands:

Copy

terraform import -var-file=vars.tfvars \
'module.security_group.aws_security_group_rule.ipv4_cidrs["0"]' \
sg-0bbbc82520894df6d_ingress_tcp_443_443_172.31.1.15/32
terraform import -var-file=vars.tfvars \
'module.security_group.aws_security_group_rule.ipv4_cidrs["1"]' \
sg-0bbbc82520894df6d_ingress_tcp_443_443_172.31.1.16/32
terraform import -var-file=vars.tfvars \
'module.security_group.aws_security_group_rule.ipv4_cidrs["2"]' \
sg-0bbbc82520894df6d_ingress_tcp_443_443_172.31.1.1/32

Finally, we need to re-import our security groups. We will once again use the cached security groups to generate the necessary commands:

Copy

jq -r '@sh "terraform import -var-file=vars.tfvars \(.address) " + .values.id' < sgs.json

This will render the following command:

Copy

terraform import -var-file=vars.tfvars \
'module.security_group.aws_security_group.sg' \
sg-0bbbc82520894df6d

Running all the previous terraform commands in the shell will modify the state so that there is integrity between it and what currently exists in AWS.

Running terraform apply to adjust some defaults such as setting revoke_rules_on_delete=false and timeouts {}, then terraform plan will confirm:

No changes. Your infrastructure matches the configuration.

Postop

Now the terraform is fully migrated over to the new security group module that uses standalone rule resources. We’ve shown that it is possible to modify the terraform state so that no infrastructure in AWS is affected. At this point we can rest assured that the operation was a success and no downtime was incurred.

Before you try this on your own infrastructure, there are a few things to consider.

The size of your terraform state: if the state is large then terraform commands may take a long time to run
The duration of AWS credential validity: if the AWS credentials become invalid while running the script, you may not be able to import any resources
Others performing terraform apply operations on the same backend while you are running the migration script: this should be avoided since if you need to revert to an old state then any new resources will no longer exist.

It may be possible to lock the terraform state for the backend manually and then run terraform commands with -lock=false so that they do not attempt to acquire the state. This can be risky and should be used at your own discretion.

Good luck! All the code used for this blog post can be found on github here:

https://github.com/orenfromberg/terraform-sg-demo

How to install golang securely on linux

Tue, 29 Mar 2022 00:00:00 GMT

Securely installing the Go programming language (golang)

On Windows and MacOS the golang installers are signed so that the operating systems can verify that they have been published by Google.

With Linux-based operating systems there are various methods that will depend on the distro you use. For example, Ubuntu offers snap and apt to install specific versions of golang. Other distros have their own software management tools like yum.

These software managers will let you install certain releases but not all. If you want to install a newer or different version of golang from a tarball archive then the integrity must be checked manually.

Installing from tarball archive

The linux installers/archives for various architectures are found on this page here.

The latest stable version 1.18 (as of March 2022) is displayed with a list of released artifacts:

To install the amd64 artifact, first download the file with curl:

Copy

$ curl https://go.dev/dl/go1.18.linux-amd64.tar.gz -OL

The -OL options will write the file to your disk and handle 3xx redirect responses.

Now compare the sha256 hash to what is on the website:

Copy

$ sha256sum go1.18.linux-amd64.tar.gz 
e85278e98f57cdb150fe8409e6e5df5343ecb13cebf03a5d5ff12bd55a80264f  go1.18.linux-amd64.tar.gz

Looks good!

If you trust that this web page and these artifacts were really published by Google then you can stop here and follow the rest of their installation instructions.

But if you want to verify with the least uncertainty that this file and checksum have been published by Google, then you’ll want to verify the signature using Google’s public key.

Checking the signature on the archive

Verifying the signature on the archive gives us confidence that Google has released this archive for our use.

The signature for the archive isn’t listed as an artifact but can still be downloaded by concatenating .asc to the filename:

Copy

$ curl https://go.dev/dl/go1.18.linux-amd64.tar.gz.asc -OL

Now download and import the google public key to your GPG keyring:

Copy

$ curl https://dl.google.com/dl/linux/linux_signing_key.pub -OL
$ gpg --import linux_signing_key.pub

You can list the keys in your keyring with the following:

Copy

$ gpg --list-keys
pub   rsa4096 2016-04-12 [SC]
      EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796
uid           [ unknown] Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
sub   rsa4096 2019-07-22 [S] [expires: 2022-07-21]
sub   rsa4096 2021-10-26 [S] [expires: 2024-10-25]

Note that the fingerprint for their primary public key is EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796 and that it is set to expire on July 21, 2022. If you are reading this post and it’s past that date, make sure to import their latest public key!

The best thing to do is try to find the Google public key from multiple locations to increase the likelihood that it is authentic. Don’t trust me!

Finally, verify the signature:

Copy

$ gpg --verify go1.18.linux-amd64.tar.gz.asc
gpg: assuming signed data in 'go1.18.linux-amd64.tar.gz'
gpg: Signature made Tue 15 Mar 2022 12:54:40 PM EDT
gpg:                using RSA key 78BD65473CB3BD13
gpg: Good signature from "Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796
     Subkey fingerprint: 2F52 8D36 D67B 69ED F998  D857 78BD 6547 3CB3 BD13

Note the primary key fingerprint matches above.

You can ignore the WARNING since we haven’t verified their public key by signing it.

Now you can sleep well at night knowing that you are safe from supply chain attacks on the golang binaries!

Some content for this post came from this github issue.

Let's play Hebrew Bingo!

Thu, 28 May 2020 00:00:00 GMT

Hebrew numerals are often used to represent dates on the Hebrew calendar.

For example:

לַ״ג בָּעוֹמֶר — Lag B'Omer
ט״וּ בִּשְׁבָט — Tu B'Shvat
ט״וּ בְּאָב — Tu B'Av

Dates on a Ketubah (Jewish Marriage Contract) are written with Hebrew Numerals, and so are dates on a Jewish grave stone.

I made this Hebrew bingo game to help my students (5th graders) build the skill of decoding Hebrew numerals. They were able to quickly master the skill and had a lot of fun doing it.

First, it helps to review the Hebrew alphabet and point out that each letter is given a value, and this system is called gematria. Here are the letters according to a simple encoding:

א	ב	ג	ד	ה	ו	ז	ח	ט
1	2	3	4	5	6	7	8	9
י	כ	ל	מ	נ	ס	ע	פ	צ
10	20	30	40	50	60	70	80	90
ק	ר	ש	ת	ך	ם	ן	ף	ץ
100	200	300	400	500	600	700	800	900

Next, it helps to observe how Hebrew numerals work. For Bingo we only need to focus on the numbers 1 though 75. The numerals are pretty straightforward between 1-10, by tens 10-100, and by hundreds 100-900. The tricky parts are between, and there are a couple of gotchas to watch out for.

So for example, the numbers 21-29 are:

כ״א	כ״ב	כ״ג	כ״ד	כ״ה	כ״ו	כ״ז	כ״ח	כ״ט
21	22	23	24	25	26	27	28	29

It’s easy to observe the pattern there, that it is the tens value followed by the gershayim mark ״ and the ones value.

The gotchas live in the numbers between 11-19:

י״א	י״ב	י״ג	י״ד	ט״ו	ט״ז	י״ז	י״ח	י״ט
11	12	13	14	15	16	17	18	19

Notice the numbers for 15 and 16 are slightly different than the earlier pattern, however their sum still equals the same amount. These forms are avoided because the combinations of yud with hey and yud with vav are too similar to The Holy Name.

Now that these gotchas are pointed out, it’s time to play.

Navigate to this page and start adding players by their names.

When you add a player, their name will appear below with a link to their bingo sheet. Copy the link and send it to the player by email or another method.

Once all the players are ready to play, click Pick Number! to pick a bingo number from the hat. If the player has the number, they can click on their bingo sheet to mark it.

When a player gets bingo and calls it out, a gold star ⭐ should appear next to their name to indicate that they won.

Click Reset Game to reset the hat and play again.

That’s it, I hope you enjoy the game. Please leave any feedback in the comments below.

Setting up a Headless Raspberry Pi

Mon, 25 May 2020 00:00:00 GMT

These are the steps I take when setting up a headless Raspberry Pi.

Headless means that there is no other way to interact with it besides connecting to it via SSH. There’s no monitor and no keyboard or mouse. It will sit somewhere in my house running quietly, just doing its thing, whether it’s a cron job or hosting some kind of web service.

Some of the information in this post comes from here and here.

I hope this is useful to you!

Using this tool on my host machine, I flash the latest version of Raspbian lite to an SD card.
After it finishes imaging, I open a terminal window in the /boot partition of the SD card and run the following script ~./headless-init.sh:

Copy
```
#!/usr/bin/env bash

# enable SSH
touch ssh

cat > wpa_supplicant.conf <<EOF
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
 ssid="${WIFI_SSID}"
 psk="${WIFI_PASSWORD}"
}
EOF
```
I keep the script in my home directory so I run it like this (Replace the SSID and Password with your own):

Copy
```
$ WIFI_SSID=Linksys WIFI_PASSWORD=hunter2 ~/headless-init.sh
```
You may want to hardcode those values, but having them written out explicitly might keep those credentials fresh in your mind.
Eject the sd card and insert it into the Pi and power it up. After a minute, SSH into it and use the default password raspberry:

Copy
```
$ ssh pi@raspberrypi.local
```
Make sure that Raspbian has the latest and greatest updates:

Copy
```
$ sudo apt update -y; sudo apt upgrade -y; sudo apt autoremove
```
Run raspi-config:

Copy
```
$ sudo raspi-config
```
These are the items that need attention:
- Change User Password
- Network Options -> Hostname
- Advanced Options -> Expand Filesystem
- Advanced Options -> Memory Split -> 16
- Update
Then I SSH back into the Pi and get all my public keys on it so I can SSH in from any of my host machines without a password:

Copy
```
$ mkdir .ssh
$ wget https://github.com/orenfromberg.keys -O ~/.ssh/authorized_keys
```
Disable password access for sshd:

Copy
```
$ sudo vim /etc/ssh/sshd_config
```
Then make sure password authentication is set to no:

Copy
```
PasswordAuthentication no
```
By disabling password authentication, any user would need to have one of the private keys that are associated with the public keys that we fetched from GitHub in order to log in to the Pi.

Install ufw:

Copy

$ sudo su -
# apt install -y ufw
# ufw default deny incoming
# ufw default allow outgoing
# ufw allow from 10.0.0.0/8 to any port 22 proto tcp
# ufw allow from 172.16.0.0/12 to any port 22 proto tcp
# ufw allow from 192.168.0.0/16 to any port 22 proto tcp
# ufw allow from 169.254.0.0/16 to any port 22 proto tcp
# ufw allow from fc00::/7 to any port 22 proto tcp
# ufw allow from fe80::/10 to any port 22 proto tcp
# ufw allow from ff00::/8 to any port 22 proto tcp
# ufw status
# ufw enable
# exit

This step involves denying all incoming connections on all ports and then whitelisting the SSH port 22 on all kinds of private IP CIDR ranges for IP4 and IP6. See here for more info.

After this, if you want to enable incoming connections on any ports, you’ll need to whitelist the port. For example, if you want to enable access for HTTP:

Copy

$ sudo su -
# ufw disable
# ufw allow 80/tcp
# ufw enable

Install fail2ban:

Copy
```
$ apt install -y fail2ban
```
See more info on fail2ban here.

That’s it. Now I’ve got a fresh headless Raspberry Pi ready to go. Let me know if you have any ideas how I can improve this in the comments below.

GitHub Actions

Thu, 31 Oct 2019 00:00:00 GMT

Getting Started

On November 13th, GitHub will ship a new feature called Actions — tight automation integrations that are available to all GitHub repositories, and can automate many software workflows.

I decided to try using Actions to build, test and deploy my blog. The first step was adding a workflow, which was pretty simple since it was already available as a starter workflow for Node.js apps. To do this, I clicked on the “Actions” tab on my repository page:

Then I clicked the “New Workflow” button:

Because my blog is a Node.js project, the first starter workflow it showed was exactly the one I needed for building and testing the code:

This starter created a file in my repo called .github/workflows/nodejs.yml. I adjusted some things like the versions of Node.js in the node-version strategy matrix, as well as the condition that the workflow would execute under (on push to the master branch):

Copy

name: Node CI

on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [10.x]
    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: npm install, build, and test
        run: |
          npm ci
          npm run build --if-present
          npm test
        env:
          CI: true

Adding the Action for deploying with AWS

I use AWS to host and distribute my blog. Fortunately, there is a GitHub Action for that here.

These actions would be responsible for syncing the build with the s3 bucket that hosts the static content as well as invalidating the CDN cache on Cloudfront. To do this, I needed to create an IAM user on AWS that had a custom policy attached to it that would give it permission to do those two things. (some info here is intentionally left out.)

Copy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObjectAcl",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:DeleteObject",
        "cloudfront:CreateInvalidation",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:cloudfront::<AWS ACCOUNT NUMBER>:distribution/<CLOUDFRONT DISTRIBUTION ID>",
        "arn:aws:s3:::<S3 BUCKET>",
        "arn:aws:s3:::<S3 BUCKET>/*"
      ]
    }
  ]
}

Once the user had the policy attached to it, I generated some credentials and then added them as secrets to the repository by clicking on the settings gear:

Then clicking on “Secrets”:

Then I was able to add the secrets using the dialog:

At this point, I needed to update the build job steps to include Deploying to S3 as well as Invalidating the Cloudfront Cache:

Copy

- name: Deploy to S3
  uses: actions/aws/cli@master
  with:
    args: s3 sync ./public s3://${{ secrets.AWS_S3_BUCKET }} --acl public-read --follow-symlinks --delete
  env:
    AWS_REGION: ${{ secrets.AWS_REGION }}
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
- name: Invalidate Cloudfront Cache
  uses: actions/aws/cli@master
  with:
    args: cloudfront create-invalidation --distribution-id ${{ secrets.CDN_DISTRIBUTION_ID }} --paths \"/*\"
  env:
    AWS_REGION: ${{ secrets.AWS_REGION }}
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Now when I commit the code to the master branch and push to origin, the Action runs automatically. If you click on the Actions tab, you can see the console output of the actions in real time. In the case that the Action fails, GitHub will email you a notification to let you know. It is satisfying to watch the Action complete and display the green checks on the screen. If you want, you can add a badge to your README.md file that will show the current build status of a workflow:

Copy

[![Actions Status](https://github.com/orenfromberg/orenfromberg.tech/workflows/Node%20CI/badge.svg)](https://github.com/orenfromberg/orenfromberg.tech/actions)

It looks like this:

Conclusion

I like having automation available to me from within my repository on GitHub. This feature is free for all open-source projects so hopefully this will encourage more open-source development.

Welcome to my tech blog!

Thu, 24 Oct 2019 00:00:00 GMT

Welcome to my tech blog! I will use this space to write about the things I love, especially technology.

This blog uses gatsby, a node.js based static site generator. The source code for my blog is open source and can be found here on GitHub.

Enjoy!

Sincerely,

Oren

א	ב	ג	ד	ה	ו	ז	ח	ט
1	2	3	4	5	6	7	8	9
י	כ	ל	מ	נ	ס	ע	פ	צ
10	20	30	40	50	60	70	80	90
ק	ר	ש	ת	ך	ם	ן	ף	ץ
100	200	300	400	500	600	700	800	900

א	ב	ג	ד	ה	ו	ז	ח	ט
1	2	3	4	5	6	7	8	9
י	כ	ל	מ	נ	ס	ע	פ	צ
10	20	30	40	50	60	70	80	90
ק	ר	ש	ת	ך	ם	ן	ף	ץ
100	200	300	400	500	600	700	800	900

א	ב	ג	ד	ה	ו	ז	ח	ט
1	2	3	4	5	6	7	8	9
י	כ	ל	מ	נ	ס	ע	פ	צ
10	20	30	40	50	60	70	80	90
ק	ר	ש	ת	ך	ם	ן	ף	ץ
100	200	300	400	500	600	700	800	900