How to blackout your window without drilling Previous failed attempts Updated 2025-06-17 +Created 1970-01-01
Thick cardboard paper and Gorilla Tape: the intense Sun heat made the cardboard bend, and even the Gorilla tape could not hold it, leading to light leakage. Even worse, it started to smell a bit, and I got afraid that it could catch fire, so don't do this! Maybe I will try coating with aluminium foil next time, but I'm afraid it might stick to the glass. In any case, even if those setups work, your room may be permanently very dark depending on how far the window opens, which can lead to other problems such as mold. Another downside of this method is that the tape is extremely sticky, and especially difficult to remove if it touches the glass, where you can't use metallic items to scrape it off without scratching the glass. I had to get a solvent and use a lot of elbow grease to get rid of it.
I have tried a few sleeping masks, but none of them were enough on their own. There is always some light leakage around the nose, especially as you turn around in the night. And some of them are too hot. I have tried:
- Sleep Master (archive): www.amazon.co.uk/gp/product/B0015NZ6FK (archive). Also too hot.
- Muji Eye Mask
I also considered getting one of those "Perfect Fit Blinds" www.blindsdirect.co.uk/perfect-fit-roller-blinds (archive) which fit between the glass and the insulation. This looks like it could work. But I didn't go for it in the end because my window has 3 glass panels, so I would have to get three of those blinds separately.
x86_64 uses 48 bits (256 TiB), and legacy mode's PAE already allows 52-bit addresses (4 PiB). 56-bits is a likely future candidate.
But that would mean that the page directory would have
2^18 = 256K
entries, which would take too much RAM: close to a single-level paging for 32 bit architectures!x86_64 uses 4 levels in a
9 | 9 | 9 | 9
scheme, so that the upper level only takes up only 2^9
higher level entries.The 48 bits are split equally into two disjoint parts:
----------------- FFFFFFFF FFFFFFFF
Top half
----------------- FFFF8000 00000000
Not addressable
----------------- 00007FFF FFFFFFFF
Bottom half
----------------- 00000000 00000000
A 5-level scheme is emerging in 2016: software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf which allows 52-bit addresses with 4k pagetables.
Consider this is a study in failed computational number theory.
The approximation converges really slowly, and we can't easy go far enough to see that the ration converges to 1 with only awk and primes:Runs in 30 minutes tested on Ubuntu 22.10 and P51, producing:
sudo apt intsall bsdgames
cd prime-number-theorem
./main.py 100000000
. It is clear that the difference diverges, albeit very slowly.
. We just don't have enough points to clearly see that it is converging to 1.0, the convergence truly is very slow. The logarithm integral approximation is much much better, but we can't calculate it in awk, sadface.
But looking at: en.wikipedia.org/wiki/File:Prime_number_theorem_ratio_convergence.svg we see that it takes way longer to get closer to 1, even at it is still not super close. Inspecting the code there we see:so OK, it is not something doable on a personal computer just like that.
(* Supplement with larger known PrimePi values that are too large for \
Mathematica to compute *)
LargePiPrime = {{10^13, 346065536839}, {10^14, 3204941750802}, {10^15,
29844570422669}, {10^16, 279238341033925}, {10^17,
2623557157654233}, {10^18, 24739954287740860}, {10^19,
234057667276344607}, {10^20, 2220819602560918840}, {10^21,
21127269486018731928}, {10^22, 201467286689315906290}, {10^23,
1925320391606803968923}, {10^24, 18435599767349200867866}};
Paging makes it easier to compile and run two programs or threads at the same time on a single computer.
For example, when you compile two programs, the compiler does not know if they are going to be running at the same time or not.
And thread stacks, that must be contiguous and keep growing down until they overwrite each other, are an even bigger issue!
But if two programs use the same address and run at the same time, this is obviously going to break them!
Paging solves this problem beautifully by adding one degree of indirection:
(logical) ------------> (physical)
paging
Where:
As far as programs are concerned, they think they can use any address between 0 and 4 GiB (2^32,
FFFFFFFF
) on 32-bit systems.The OS then sets up paging so that identical logical addresses will go into different physical addresses and not overwrite each other.
This makes it much simpler to compile programs and run them at the same time.
Paging achieves that goal, and in addition:
- the switch between programs is very fast, because it is implemented by hardware
- the memory of both programs can grow and shrink as needed without too much fragmentation
- one program can never access the memory of another program, even if it wanted to.This is good both for security, and to prevent bugs in one program from crashing other programs.
Or if you like non-funny jokes:
Comparison between the Linux kernel userland memory virtualization and The Matrix
. Source. Is this RAM real?This is the most extreme and final form of peer tutoring, it's natural final consequence given the Internet Age.
When the process changes,
cr3
change to point to the page table of the new current process.A simple and naive solution would be to completely invalidate the TLB whenever the
cr3
changes.However, this is would not be very efficient, because it often happens that we switch back to process 1 before process 2 has completely used up the entire TLB cache entries.
The solution for this is to use so called "Address Space Identifiers" (ASID) as mentioned in sources such as:
Basically, the OS assigns a different ASID for each process, and then TLB entries are automatically also tagged with that ASID. This way when the process makes an access, the TLB can determine if a hit is actually for the current process, or if it is an old address coincidence with another process.
There are unlisted articles, also show them or only show them.