The Apple logo character isn't a real symbol, it's just a space from the Unicode private-use area (the 'anything goes' area that's not codified and is reserved for niche local uses) that Apple decided would render as the Apple logo in iOS and macOS, probably to allow them to draw their logo as text. It's not something that should be used in browsers or anything that can render outside of Apple's ecosystem. It's not a great sign that something this front-and-center, immediately apparent on any non-Apple devices, wasn't tested by them on any other platforms.
Ironically it was quiet enough in our previous apartment, but moving to a house we now have the neighbor using their awfully loud snow-spitting machine before 6AM after snowy nights... (And it snows a lot)
(if I were to nitpick, for large grids one might want to make the separating line a bit thicker every 5 blocks for faster counting, and repeat numbers at the bottom/right -- but at the size the examples are in neither are needed)
(BTW you didn't mention for overlapping but there's a nice trick: just try from either end, count how many cells are leftover, and take that off the starting side of each block)
>> You definitely can use Linux with few simple servers with 128 MB RAM.
>
> This is not difficult, you just need to run `htop` and perform addition of the RES column (which is in KB unless a unit is shown). Example:
I'm not quite sure what points this makes... That's supposed to fit on 128MB? And it doesn't include memory consumed by the kernel itself (which is not negligible at this scale), and linux needs spare for cache to work remotely decently.
$ awk '{ tot+=$2 } END { print tot /1024 }' < list
214.035
I'm sure you can run a linux with 128MB of ram, but certainly not with systemd and a default kernel... Perhaps DSL (damn small linux) or alpine.
The point was that most of the shown software is optional, and you can check how much selecting those parts you care about sum up to.
To provide "conclusive proof" that it's possible to run a 128 MB Linux system.
For example, if you remove (or configure smaller memory use for) journald, the Amazon daemon, oomd, timesyncd, you are already at around 128 MB userspace, with more that can be removed if desired.
And this is on a distro that is not at all designed to be minimal in memory usage.
How much cache is good depends entirely on what you want the system to do.
> This article does not mention that environment variables are also visible by process in /proc/*/environ (which has restrictive permissions, but is completely visible to root).
He's explicitly not using export, so they won't show up there. Plain variables are not in the environment.
(it's good to bring up this file as well as getting inherited by child processes though)
I believe that unexported shell variables will be visible in /proc/*/mem, so it would be prudent to overwrite then unset them as soon as reasonably possible in their usage.
mem, yes, definitely. I'm not sure how you can protect yourself from that (or root user using ptrace or equivalent debugging tool) though...
Oh, memfd_secret?
The memory areas backing the file created with memfd_secret(2) are visible only to the processes that have ac‐
cess to the file descriptor. The memory region is removed from the kernel page tables and only the page tables
of the processes holding the file descriptor map the corresponding physical memory. (Thus, the pages in the re‐
gion can't be accessed by the kernel itself, so that, for example, pointers to the region can't be passed to
system calls.)
Before Linux 6.5, memfd_secret() was disabled by default and only available if the system administrator turned it on using "secretmem.enable=y" kernel parameter.
[...]
"To prevent potential data leaks of memory regions backed by memfd_secret() from a hybernation image, hybernation is prevented when there are active memfd_secret() users."
I'm sure other languages have equivalents but I rarely see this.. for example I was about to say serde doesn't do it, but it looks like it's possible with a wrapper type? https://docs.rs/redactrs/latest/redactrs/
Anyway, this kind of tagging is good, I want more!
I don't get why a bad guy couldn't dump the current log / hash, then load a kernel module that'd just replay the same values whenever someone asks for it?
Does the log have a challenge/nonce from the client that'd change the hash everytime it's obtained? (if the client loads their own kernel module they can check it's on the list, but the whole point is about not having to do that, right..)
I had the same problem on our home server.. I just stopped the git forge due to lack of time.
For what it's worth, most requests kept coming in for ~4 days after -everything- returned plain 404 errors. millions. And there's still some now weeks later...
I get a new fingerprint id everytime I refresh the page (firefox, linux) -- so that might be sampling a tiny bit too much.
audio and canvas fingerprint are constant though so it's probably plenty enough...
reply