

🫂 beautiful name btw <4
My biggest hurdle to making the switch is that it takes effort.
Thats pretty understandable honestly. If my old netbook wasn’t so bogged down from Windows, there’s a chance I wouldn’t have switched to Linux. In a way, I’m glad for it, but it woulda been easier if it just came with Linux preinstalled <3
The biggest thing I remember was driver support being awful. I guess it’s a lot better now?
In my experience drivers have been pretty solid… except for NVIDIA. People seem to either have 0 issues or tons. Fingers crossed the upcoming Nova+NVK driver combo brings a more consistent and stable experience for all :)
I’m not sure, but I think the windows progress bar thingy includes the time spent actually writing to disk, whereas on Linux (or i guess cinnamon) only shows when it gets to disk-cache. If you are full on RAM or tried shutting down immediately afterwards it should take a bit longer since it has to actually write it to disk
Thats my guess anyway
Nope. I use left shift for everything.
Even if you do use both shift keys correctly, it still feels awkward to me since you have to sacrifice a pinky from home row and shift your hands.
It’s why I’ve been curious to try a layout where Shift and Alt are swapped, that way you can use your thumb to press shift and keep your fingers in place.
we have a truly marvelous application process, which this margin is too small to contain
$ cat
You sound very nice :)
You sound very nice :)
Bye<ctl-d>Bye
Oh wait, and cool too
Oh wait, and cool too
<ctl-d>
$
The Ctl-D didn’t end the file when i typed “Bye” :( it only worked when I pressed Ctl-D on its own line. So how does cat know that it should ignore the EOF character if there is some text that comes before it?
What Ctl-D does is flush the input to the program, and the program sees how big that input is. If the length of the input is 0 that is interpreted as EOF. So Ctl-D is like Enter because they both flush the input, but Ctl-D is unlike Enter because it does not append a newline before flushing, and as a consequence you can send empty input (aka an EOF “character”) with Ctl-D.
On any reasonable terminal, RETURN has a key of its own
This reminds me of a time at work when I was not on a reasonable terminal. I was explaining to a co-worker how I automated some tasks by running some scripts, but in my demo my RETURN key didn’t work, so I had to improvise and use CTRL+M which worked, hahaha. I don’t know how the terminal got in such a bad spot but it was probably something to do with msys on Windows… honestly not sure. It was perfect timing to have happen while teaching of course ;)
I would also be doing a disservice not to share what the book you linked says about CTRL+D. Right after your quote, it says:
Other control characters include ctl-d, which tells a program that there is no more input
This is pretty good for an introduction, but it is not the full story. It explains CTRL+D properly later (chapter 2, page 45):
Now try something different: type some characters and then a ctl-d rather than a RETURN:
$ cat -u 123<ctl-d>123
cat
prints the characters out immediately. ctl-d says, “immediately send the characters I have typed to the program that is reading from my terminal.” The ctl-d itself is not sent to the program, unlike a newline. Now type a second ctl-d, with no other characters:
$ cat -u 123<ctl-d>123<ctl-d>$
The shell responds with a prompt, because
cat
read no characters, decided that meant end of file, and stopped. ctl-d sends whatever you have typed to the program that is reading from the terminal. If you haven’t typed anything, the program will therefore read no characters, and that looks like the end of the file. That is why typing ctl-d logs you out — the shell sees no more input. Of course, ctl-d is usually used to signal an end-of-file but it is interesting that it has a more general function.
This is why the article says it’s “like pressing enter,” because it flushes the input just like enter. The difference is that enter sends a newline, but CTRL+D does not, so you can exploit that to send no data (and the program chooses to interpret that as an EOF).
not true. try this:
$ date<C-d>
bash did not terminate stdin, because when i press enter it still runs the command, and my shell continues to work as normal!
you can also try this:
$ bash --noediting
$ date<C-d><C-d>
and it will print the date.
so something else is happening here! thats what the link talks about in detail
Aw man :( Asahi Lina and her GPU project has been an inspiration for me. Hope she is alright.
Something i didnt know for a long time (even though its mentioned in the book pretty sure) is that enum discriminants work like functions
#[derive(Debug, PartialEq, Eq)]
enum Foo {
Bar(i32),
}
let x: Vec<_> = [1, 2, 3]
.into_iter()
.map(Foo::Bar)
.collect();
assert_eq!(
x,
vec![Foo::Bar(1), Foo::Bar(2), Foo::Bar(3)]
);
Not too crazy but its something that blew my mind when i first saw it
I noticed it and placed a few pixels :D
Here’s one on the claw
More progress on the Finite Projective Plane (incidence matrix) generation from last week. There already exists an algorithm to generate boards of order p+1 where p is prime. It is stateless, so with CUDA we can generate huge boards in seconds since all you need is the x, y position and board size. 258x258 under 3s!
However, p+1 isn’t the only sequence. It seems by our observations that the fermat numbers also generate valid boards, using our “naïve” algorithm.
Unfortunately 3x3, 5x5, and 17x17 might not contain all the nuggets of generality to find a nice algorithm like the p+1, so we’re gonna generate the next up: 257x257. We’ve been improving the naïve algorithm since it is too slow. (The resulting image would be 65793x65793)
true
elements would be using row and column indexes. This is okay because of the constraint which limits how many true
elements can be in a row/column
slice::contains
, use slice::binary_search(...).is_ok()
Next steps:
Apparently generating “Finite Projective Planes”. For context on how I got here, I went camping with my family and brought the game Spot It. My brother was analyzing it and came up with the same type of pattern.
When we got home he made a python script to generate these boards, but it was quite slow, so he half joked asking me to rewrite it in Rust.
I kinda struggled a bit since I didn’t fully understand what it was doing. Near the end I even got a segfault using safe code😃! (i was spawning a thread with a large stack size, and allocating huge slices on its stack, rather than you know… boxing the slice Lol.) When I finally got it working, it ended up being in the ballpark of a 23x speedup. Not bad for changing the language choice!
There’s lots of room for improvement left for sure. The algorithm could benefit with some running statistics about cols/rows and the algorithm itself is quite naïve and could maybe be improved too :P
If they aren’t equal, there should be a number in between that separates them. Between 0.1 and 0.2 i can come up with 0.15. Between 0.1 and 0.15 is 0.125. You can keep going, but if the numbers are equal, there is nothing in between. There’s no gap between 0.1 and 0.1, so they are equal.
What number comes between 0.999… and 1?
(I used to think it was imprecise representations too, but this is how it made sense to me :)
Imagine they have an internal tool to check if the hash exists in their database, something like
"SELECT user FROM downloads WHERE hash = '" + hash + "';"
You set the pdf hash to be 1'; DROP TABLE books;--
they scan it, and it effectively deletes their entire business lmfaoo.
Another idea might be to duplicate the PDF many times and insert bogus metadata for each. Then submit requests saying that you found an illegal distribution of the PDF. If their process isn’t automated it would waste a lot of time on their part to find the culprit Lol
I think it’s more interesting to think of how to weaponize their own hash rather than deleting it