it’s interesting they call it windows subsystem for linux

- oh, so it’s a subsystem for Linux?

- no, it’s a windows subsystem

- …for Linux?

- kind of, I guess

Wireless devices let me use 2 different tables and an armchair+TV. That would simply not be an option otherwise.

The benefits of going wireless vastly outweigh an occasional connection annoyance to me. And worst case I can still plug them in.

I use rustdesk for remote desktop. Screen sharing is usually on zoom as it’s what my workplace uses.

deleted by creator

rest in plasma

toilet simulator - to experience what’s like to not be constipated.

kali is for posers, professionals use hannah montana

but modal editing is exactly what I don’t like about vim

I knew she was cheating on me

C was my first language some 18y ago, and I wouldn’t recommend it to anyone starting today. If anything, learning C is a great way to teach why, maybe, we shouldn’t be using it to build customer applications, web servers, and whatnot.

Keep your gold, I’ll stick to sane error messages, memory management, a packaging system, and a dozen other things that actually make working on multiple projects somewhat doable and not a constant fight against seg faults.

that’s one way to swing the pendulum all the way back to the 1970s

You probably don’t have to write to specific broswers. Just stick to the baseline and you’re golden. Optionally use a headless chrome for e2e testing to be sure.

I’ll admit that in 10 years using git, I don’t think I’ve ever used reflog once.

don’t forget to activate your linux distro

https://github.com/MrGlockenspiel/activate-linux

it does work though, on windows i can see ads and intrusive crap all the time. Linux distros don’t bother you at all, it’s like linux is not even trying at this point.

tldr

1. Keep Commits Small: Ensure commits are small and manageable to facilitate easy reverts and debugging.
2. Continuous Refactoring: Prioritize frequent, minor refactorings to simplify future changes.
3. Deploy Continuously: Regularly deploy code to ensure it works in production, as working software is progress.
4. Trust Frameworks: Avoid over-testing framework capabilities; focus on application-specific logic.
5. Create Independent Modules: Place functions in new modules if they don’t fit existing ones, preserving code organization.
6. Write Tests Early: Use tests to design APIs and guide development, but don’t be rigid about TDD.
7. Avoid Duplication: Prevent repeated code by abstracting similar implementations after copying once.
8. Embrace Change: Accept and adapt to evolving designs, understanding that change is intrinsic to software development.
9. Manage Technical Debt: Focus on minimizing immediate blockers and plan for potential future issues.
10. Prioritize Testability: Ensure that your code and design facilitate easy testing to maintain code quality and coverage.

Scientists using macs connecting to servers and other machines running Linux.

Unknown share is high too; Linux usage on desktop in Antarctica could be as high as 15%.

mah man

man man

oh man

The misleading behavior is about what you expect to execute in the source code you’re looking at vs what’s actually executed.

What you describe is a logic ambiguity that can happen in any program / language.