For the never-ending text file for todos and work journal, I've found great success with org-mode, especially since deadlines automatically end up in my calendar with org-agenda. The outline format of org-mode is quite nice and it took all of 1 day to learn the key commands for making / manipulating the outline, creating links, and cycling through TODO states (using Doom emacs made the start super easy since I already know vi and didn't have to also learn the text editing commands).
I've also found the concept of an "inbox" from the Zettelkasten method very helpful. Anytime something comes up that's not yet in my system, I add it to the inbox for later processing (org-capture on my computer, and beorg on my phone). This way, note entry doesn't require a full context switch. I then just make sure to regularly drain my inbox.
I don't use emacs currently for anything but org-mode but I'm far happier with this than I was with a never ending `.md` file.
Like many things in Software the question is why do you want to hide them?
One way to do it is to archive[0] it which will move it into a local _archive file.
Another way which I'm currently using is to periodically manually archive tasks into a tree of folders and files by date then category (and sometimes subcategory) which allows me to publish an HTML or PDF file of everything from say 2023 for a particular client.
Computer Networking: A Top-down Approach, Jim Kurose
I read this about 2 years into my study of CS. I found the design of the internet, at times intentional and very often emergent / working around constraints, absolutely fascinating. I couldn’t help feeling that algorithms were things I could pull off the shelf but protocols were something I’d need to be able to design well throughout my career.
Come here to recommend this excellent networking book and it's much better than the Tanembaum's one. If you are in networking field you owe yourself to read this book and the latest 8th edition is the best version yet because the authors have removed the chapter on multimedia networking and focusing more on SDN. Heck, any aspiring textbook writer should read this book as a golden reference on how to write a proper textbook.
I'm probably C2 comprehension, C1 speaking in German. I self-taught to high B2 (based off placement into that level in a Goethe Institut Intesivkurs) in 15 months of 2 hours a day. I studied 1-2 hours per day on average and did not miss a single day.
2 hours a week to B1 in German as an English speak seems totally impossible. I was probably B1 in 6 months at the level of study I described. I studied 5 years of Latin prior to starting so the case system wasn't an additional learning curve. Your pace honestly seems standard.
I moved to Germany as well and self taught German to a high B2 level in the 15 months before moving. That was enough where I was able to be conversationally fluent within 3 months of arrival
When I self taught, I primarily used Assimil and Pimsleur daily for the first six months. After completing those programs, I continued with the daily study (that’s the most important part!) and used Easy German the YouTube channel, watched a bunch of German shows, and worked on speaking just by narrating / describing random things and looking up words as needed.
For me it was most important to get books in my field in german, read them slowly and learn all the buzzterms and experssion. Some books you can read without really understanding them, e.g. some best selling paper back without any weight too it. I haven't worked in Germany but it's a perfect country to learn by reading books
This is why I always like to have a `status_history` or `audit` table. You don't have to have event sourcing to still want a trail of who changed what in the system when.
I read Kurose’s book in college and recommend it as the perfect book for this topic. As a neophyte at the time, I remember really drilling into the details of TCP and just being in awe of how well thought out the whole system was. This book laid such a good foundation for my career as a software engineer.
Your reading of this is rather extreme, and I feel you've missed the point by thinking that Russell is advocating to avoid fun intentionally at times so as to preserve a happy life. I read it as more an observation that the boring times, those in which there's a lack of stimulation, are an important part of a balanced, healthy life.
A more modern take on his advice would be to avoid mindlessly surfing the internet every dull moment in which we are waiting a few minutes for some time to pass. If you haven't taken an extended, conscious break from the internet outside of your work needs (no social media, no news, etc), I recommend it. It was very enlightening for me to feel this lack of stimulation. I certainly enjoy my time on the internet when I'm there because I want to be there, not because I'm just looking for something to kill the time.
Similarly, I've stopped listening to music while coding because I realized that the listening without mindfulness was killing my passion. After doing so, the passion has been restored.
His words, too, remind me of the drug user's plight. My sister works in drug rehabilitation and has told me about the struggles many go through known as Post Acute Withdrawal Syndrome. From my naive understanding, these people have adapted to the constant, unnatural amount of dopamine flowing through the brains during addiction by producing more dopamine receptors. When the drug is gone, those receptors are still there. But, the body is not capable of naturally releasing the dopamine required to fill these receptors even during the highest of natural moments, leading these people to experience serious anhedonia -- an intense lack of pleasure from everyday life. It takes a long time for these receptors to downregulate, which is the reason for such a high rate of relapse for certain drug types.
I think of Emerson's words a bit: "If the stars should appear one night in a thousand years, how would men believe and adore; and preserve for many generations the remembrance of the city of God which had been shown!"
While mitigating a number of attacks, MFA with these types of physical tokens is still only as strong as their setup/enrollment process, which in many cases can be compromised via phishing.
From my experience, there’s a difference between trying to compromise someone with good opsec (many readers of hacker news) and compromising regular non technical people
How are you envisioning practically attacking deployment of FIDO tokens via phishing? Compared to conventional phishing or spear phishing attacks this seems very difficult to execute.
Suppose BigCorp users are supposed to enroll the new tokens they all received at mfa.bigcorp.example which I dunno maybe they're reaching via a link from blog.thebigcorp.example because of course these organisations have a dozen different domains used interchangeably.
I can see how you could try to redirect some or all employees to mfa.b1gc0rp.example which you control, and that's an opportunity to steal their non-token credentials, but now their token doesn't actually work.
Even though they've enrolled with mfa.b1gc0rp.example you don't directly gain working token credentials for bigcorp.example this way, and almost as importantly for this attack, nor do they. So they're going to call the company IT desk.
I guess if you own a suitable token, you could conduct this as a spear phishing attack where the victim tries to enroll at your bogus site, then you replay the non-token credentials they used for that to enroll your real token on the real site, but again the victim doesn't end up with a working token, so it seems like you're up against the clock.
And while during the pandemic I'm sure new employees were routinely enrolled off-campus, I suspect that's just not the case in normal times, even at organisations which have a very broad work-from-home policy.
I was specifically thinking banking and it’s exactly this type of spear phishing attack that happens (although with other types of tokens the Fido). In these scenarios, you only need to move the money once.
You definitely have a point with regard to non-transaction usage that requires long term access
Most MFA solutions are vulnerable to attack because there is a real challenge handling enrollment and lost tokens. It requires verification of the user, which guess what? Hard to do especially with remote users.
So, for any sort of FIDO token (a Yubico Security Key, Google's Titan, numerous cheaper products) the browser is working together with the physical token to authenticate you with U2F (on sites that didn't upgrade yet) or WebAuthn (the standard replacement)
During enrollment the site gets a unique random-looking identifier, a public key and a signed message that proves your token knows the associated private key. It stashes the identifier and public key. They aren't secret.
During authentication the site gives back one or more identifiers to ask you to prove you've still got one of these tokens you enrolled, and if your token recognises the identifier for this DNS name, it can sign a new message with the corresponding private key proving you still have the token.
Now suppose I'm a scammer, I am trying to phish users of the site realsite.example with my phishing scam site fake.example but they all use FIDO tokens. I can get realsite.example to give me the IDs for tokens (perhaps I guessed the user name and password or got it earlier by phishing), but then I'm blocked. I could try a few things:
1. I give them the realsite.example ID and I pretend my site is realsite.example. The user is never bothered by this because their web browser knows this website isn't realsite.example, I'm clearly a scammer, my attempt is ignored.
2. I give them the real IDs from realsite.example but I admit to the web browser that this is fake.example. This doesn't work because those IDs are for realsite.example and my site is fake.example. There isn't any "Wrong name, override? Y/N" type pop-up, there's no way for any component to guess what happened, it just doesn't work. Maybe the user will retry a dozen times. Maybe they'll eventually spot that it's a scam. They can't give me working credentials for realsite.example because they aren't at realsite.example.
3. I give them a nonsense ID and I admit this is fake.example, this doesn't work, their token doesn't recognise the nonsense ID.
4. I have them enroll their token on fake.example. This "works" fine, but now all I can do is authenticate this user on my site, the resulting credentials are completely useless on realsite.example, these are credentials for fake.example and nothing about them is the same.
I've also found the concept of an "inbox" from the Zettelkasten method very helpful. Anytime something comes up that's not yet in my system, I add it to the inbox for later processing (org-capture on my computer, and beorg on my phone). This way, note entry doesn't require a full context switch. I then just make sure to regularly drain my inbox.
I don't use emacs currently for anything but org-mode but I'm far happier with this than I was with a never ending `.md` file.