Once per day, when peeing, do it differently.
1. Release the stream during the in-breath. 2. Stop and hold the stream on the outbreath. 3. If not yet bored or tired go back to 1. Else - finish peeing normally.
That's it.
And note that for most people, a week to few weeks of the exercise give stronger orgasms and ability to delay the ejaculation.
The problem with the Unix lowest-common-denominator model is that it pushes complexity out of the stack and into view, because of stuff other designs _thought_ about and worked to integrate.
It is very important never to forget the technological context of UNIX: a text-only OS for a tiny, already obsolete and desperately resource-constrained, standalone minicomputer. It was written for a machine that was already obsolete, and it shows.
No graphics. No networking. No sound. Dumb text terminals, which is why the obsession with text files being piped to other text files and filtered through things that only handle text files.
While at the same time as UNIX evolved, other bigger OSes for bigger minicomputers were being designed and built to directly integrate things like networking, clustering, notations for accessing other machines over the network, accessing filesystems mounted remotely over the network, file versioning and so on.
People brought up on Unix look at that and see needless complexity, but it isn't.
VMS' complex pathnames are the visible sign of an OS which natively understands that it's one node on a network, that currently-mounted disks can be mounted on more than one network nodes even if those nodes are running different OS versions on different CPU architectures. It's an OS that understands that a node name is a flexible concept that can apply to one machine, or to a cluster of them, and every command from (the equivalent of) `ping` to (the equivalent of) `ssh` can be addressed to a cluster and the nearest available machine will respond and the other end need never know it's not talking to one particular box.
50 years later and Unix still can't do stuff like that. It needs tons of extra work with load-balancers and multi-homed network adaptors and SANs to simulate what VMS did out of the box in the 1970s in 1 megabyte of RAM.
The Unix was only looks simple because the implementors didn't do the hard stuff. They ripped it out in order to fit the OS into 32 kB of RAM or something.
The whole point of Unix was to be minimal, small, and simple.
Only it isn't any more, because now we need clustering and network filesystems and virtual machines and all this baroque stuff piled on top.
The result is that an OS which was hand-coded in assembler and was tiny and fast and efficient on non-networked text-only minicomputers now contains tens of millions of lines of unsafe code in unsafe languages and no human actually comprehends how the whole thing works.
Which is why we've build a multi-billion-dollar industry constantly trying to patch all the holes and stop the magic haunted sand leaking out and the whole sandcastle collapsing.
It's not a wonderful inspiring achievement. It's a vast, epic, global-scale waste of human intelligence and effort.
Because we build a planetary network out of the software equivalent of wet sand.
The point is that it was 1885 and the design was able to support buildings 10× as big without fundamental change.
The Chicago Home Insurance building wasn't very impressive, but its design was. Its design scaled.
When I look at classic OSes of the past, like in this post, I see miracles of design which did big complex hard tasks, built by tiny teams of a few people, and which still works today.
When I look at massive FOSS OSes, mostly, I see ant-hills. It's impressive but it's so much work to build anything big with sand that the impressive part is that it works at all... and that to build something so big, you need millions of workers, and constant maintenance.
If we stopped using sand, and abandoned our current plans, and started over afresh, we could build software skyscrapers instead of ant hills.
But everyone is too focussed on keeping our sand software working on our sand hill OSes that they're too busy to learn something else and start over.
One big privacy issue is that there is no sane way to protect your contact details from being sold, regardless of what you do.
As soon as your cousin clicks "Yes, I would like to share the entire contents of my contacts with you" when they launch TikTok your name, phone number, email etc are all in the crowd.
And I buy this stuff. Every time I need customer service and I'm getting stonewalled I just go onto a marketplace, find an exec and buy their details for pennies and call them up on their cellphone. (this is usually successful, but can backfire badly -- CashApp terminated my account for this shenanigans)
I was a fine dining chef for 17 years. If you were in San Francisco during the 90s, I might have cooked for you. A simple way to increase demand is to remove or change the least popular menu item every week or every month. This technique has been so successful for me I wouldn't waste much time doing anything else. Once I made a Napoleon pastry for a desert special while at La Folie on Polk st. which sadly closed recently. I had extra pastry cream and made Paris-Brest because we never threw out food. One waitress sold Napoleon on every table and the other waitress sold nothing but Paris-Brest. The dishes were fundamentally the same so I made both anytime I did one or the other as a special because waitstaff for reasons not explained in the article will sell nothing but one and others the other. I made cheese dishes to sell before the desert and fruit soups in the summer. This is the mid 90s and we were tracking data. The chef pulled me aside and showed me the sales from the previous month because I sold 1.2 deserts per customer.
Nonetheless, for the last six years I cooked I was a private chef on a mega yacht. People ask me if the guests told me what they want to eat. I say never because I never asked what people want to eat. I cooked what I want to eat and then make enough for the guests and crew. It is the best menu strategy. In fine dining, the customers make decisions all day long and in the case of being a private yacht chef, the guests are making million and billion dollar decisions. The last thing they want to do is have to decide what to eat for dinner. The family I cooked for rarely ate off the boat. And when they did it was because I said something like, "I hear there is a very good restaurant in St. Barts named ....," which was code for "I want the night off."
I believe the reason one waitress would sell every last Paris-Brest and the other would sell every last Napoleon was because they told the guests in the restaurant what they wanted to eat for desert. They made the decision for the guests.
This article represents the death of excellence and craftsmanship. Its the McDonald's-ization of software development. McDonald's does make the most consistent "food" in the world. But nobody would say it makes good food. No chef would ever want to work preparing food at McDonald's.
The author pointed out many good ideas - the problem is the extremism - the author clearly hates software developers and the complexity of software development (a common trait among management), and wants to eliminate the complexity and variability inherent to dynamic human creation. Once you've taken all the creativity and joy out of it, and distilled it down to something any monkey or even ChatGPT can do, yes you've achieved such a system, and it's a quite dreadful place to work.
A less extreme version of what the author proposes can enhance creativity and net velocity - but these systems need to be in balance, supporting and enabling the creative process, not eliminating it.
I like how people in comments are keen to change the world, but I - more realisticly - only focus on gaming the system so I can actually save myself couple bucks right away.
I set pick up and destination, exit the app, open another rides app, wait few minutes for uber to notify me that the price went down.
I only give it initials (instead of full name) and phone number, not even my gender, I rarely rate drivers positively, if it is not a negative experience, I skip reviewing, so they don't know I "like" the service.
When it takes more than a minute to find a ride, I cancel the ride and choose the "others" option, as this is the de-facto the option for "I will just take a cab", so I get inserted on the "churn risk" list.
I use a virtual card that I some time leave empty so payment fail after the ride, and on the next ride I readjust my virtual card limit on the next ride and pay the last bill so I am added on the "poor and miserable riders" list.
Even if they leave a non-RTO company and join a non-RTO company its an interesting effect. It seems that being forced to RTO in the same role can lead to unhappiness and into 'shields down' (https://randsinrepose.com/archives/shields-down/), then people are more willing to look around to see if there's a better deal on offer somewhere else (even if the _other_ deal ends up also being in-office).
Clicking the appeal button is like a trap to permanently ban your account.
You can get it back by paying off a Meta employee through a site like Swapd. It's either that or get your comment to the front page of HN. Those are the only two customer support channels for Meta or Google.
> In my experience, the key to maintaining readability is developing a healthy respect for locality
I think this pursuit of "locality" is what actually causes more complexity. And I think its mainly around our obsession with representing our code as text files in folder hierarchies.
> coarsely structure codebases around CPU timelines and dataflow
This is why I would prefer code to be in a database, instead of files and folders, so that structure doesn't matter, and the tree view UI can be organized based on runtime code paths, and data flow - via value tracing.
> don’t pollute your namespace – use blocks to restrict variables/functions to the smallest possible scope
Everyone likes to be all modular and develop in tiny little pieces that they assemble together. Relying on modularization means that when stuff changes upstream in the call stack, we just hack around these changes adding some conditionals to handle these changes instead of resorting to larger refactors. People like this because things can keep moving instead of everything breaking.
Instead, what we need to do is make it easier to trace all the data dependencies in our programs so that when we make a change to anything, we can instantly see what depends on it and needs updating.
I have actually started to think that, against conventional wisdom, everything should be a global variable. All the issues with global variables can be solved with better tracing tooling.
Instead we end up with all these little mini-databases spread all over our code, when what we should have is one central one from which we can clearly see all the data dependencies.
> group related concepts together
Instead, we should query a database of code as needed...just like we do with our normalized data.
You see the de facto as opposed to aspirational rule of law constrain or even non-trivially inconvenience anything with a 1-3T notional value any time recently?
Binding, truly binding legislation or regulatory oversight is clearly the desirous end state. How in the hell we take even a single step towards that is the 1-3T dollar question.
SBF is in prison, so is Holmes, as was Madoff.
But the burden now trivially rests on the person asserting that the public has any say in the matter to show that it ever happens in the modern era.
The first rule of Crime Club is don’t steal from other rich people. The second rule of Crime Clib is: there are no rules.
A pattern I see over and over, which has graduated to somewhere between a theorem and a law, is that motivated developers can make just about any process or architecture work for about 18 months.
By the time things get bad, it's almost time to find a new job, especially if the process was something you introduced a year or more into your tenure and are now regretting. I've seen it with a handful of bad bosses, at least half a dozen times with (shitty) 'unit testing', scrum, you name it.
But what I don't know is how many people are mentally aware of the sources of discomfort they feel at work, instead of a more nebulous "it's time to move on". I certainly get a lot of pushback trying to name uncomfortable things (and have a lot less bad feelings about it now that I've read Good to Great). Nobody wants to say, "Oh look, the consequences of my actions."
The people materially responsible for the Rube Goldberg machine I help maintain were among the first to leave. The captain of that ship asked a coworker of mine if he thought it would be a good idea to open source our engine. He responded that nobody would want to use our system when the wheels it reinvented already exist (and are better). That guy was gone within three to four months, under his own steam.
That's nothing, the "Silicon Valley" part is what happened after the acquisition. Google was so paranoid about "user data" that they forced us to delete every scrap of our training datasets, going as far as physically shredding any laptop that had contained the data. We had a memorable evening at the office with the onsite shredder truck. It couldn't shred the MacBooks due to the aluminum case and we ended up smashing them with hammers in the parking lot.
When we got to Google of course privacy concerns blocked new data collection until we completed an overengineered project to build a shiny new database with access controls and stuff. About a year later with no technology progress to speak of, the whole eye tracking project was shelved due to a strategy pivot from higher up (unrelated to anything we were or weren't doing) and we all went our separate ways. Fun times!
I highly recommend getting into classical literature. It is incredible and beyond conception — I had a light scattering in my education, but only later and recently have I discovered how incredible it can be.
Suggested Reading for beginners:
* Life of Pythagoras, by Iamblichus
* The Golden Ass, by Apuleius of Numenia (specifically, translation by Robert Graves)
* Life of Alexander by Plutarch
* Education of Cyrus by Xenophon
* Parmenides by Plato
Also, I have found SHWEP.net to be invaluable for a gentle yet rigorous guide through many classics, though it takes an esoteric bent (which I love)
On average cop training with firearms in the US is quite minimal. Most cops are extremely bad shots when intentionally firing their guns.
There's a long, long history of cops negligently firing their guns, even after gun safety tech progressed to the point where true accidental discharges are neigh impossible. It's always negligence now.
"Glock leg" was a common trope among cops, because so many of them were shooting themselves in the leg. They sued both Glock and Sig multiple times because cops were convinced it must be the guns fault. Spoiler alert, it wasn't (well, some hand waving on a certain sig issue, but glocks are impossible to fire without pulling the trigger).
I shoot competitive 3p rifle, and the closest range to me is a cop range. I've seen cops struggle for 5 minutes trying to figure out how to put their targets up. We have rules against drawing from holsters because cops have shot themselves in the leg so frequently (though the cops are still required to do it for testing lol). I've seen cops shooting rifles at the pistol range, which destroys the backstop. I've seen cops shoot at targets on the wrong range.
Like literally other people's targets, up in the air, from a different range. In the direction of an interstate freeway, at an upwards angle. I've seen cops (with aforementioned rifles) shoot groups at 50 yards while rested on a bench that are straight up worse than what I can do at 200 yards while standing up. (For an average non-olympic-tier competitor, you'd expect 200 yard standing groups to be 4-5x larger than 200 yard bench groups, and closer to 20x+ larger than 50yd bench groups).
The average cop doesn't know shit about guns, and doesn't care. And largely that would be fine because most cops will never draw their guns in the blind of duty. Unfortunately we've built up a law enforcement ethos in the US where every cop must be armed even though they really shouldn't have to be.
As a counterpoint, I interned at Jane Street about a decade ago—when they were much smaller than now—and they also built everything in-house. I'm not just talking about the trading/finance-specific systems (I didn't interact with those as an intern), but general-purpose internal tools: a code review system, a pub-sub system, custom binary and text protocols, lots of developer tooling, their own build system, their own standard library and async runtime... All with <100 developers total.
And you know what? It worked amazingly well. I'm not just talking about scale, but also about how much any single developer seemed to be able to do. Their tools and APIs were tastefully designed, tailored to their own needs and fit together remarkably well. I remember that they were consistently building things with just one or a handful of people that would have taken multiple teams at other organizations I've seen.
Looking back, that was a remarkably productive engineering environment because of how much they were willing to do themselves. The key insight is that building something for yourself is qualitatively different from building something for external consumption or using something general-purpose that already exists. You naturally tailor the code and tools to what you need, which is much easier than building something for what you think other people might need—and, surprisingly often, easier than bending a different tool to your own ends.
But, perhaps more importantly, you develop a shared mental model of the system you're developing and how it fits in with everything else that you are doing. That shared mental model is, ultimately, worth far more than the code by itself... but it isn't legible to management, so it's hard to foster and preserve without a strong engineering culture backing it up.
The other lesson I took away from that experience (and others!) is that the high-level questions people focus on ("buy vs build", "monorepo vs polyrepo"... etc) are nowhere near determinative. Whether or not any given approach works out comes down far more to the little details and nuances of what you're doing and how you're doing it, as well as a healthy dollop of circumstances beyond your immediate control.
At the end of the day, if everything else was the same, but the startup you're talking about was using perfectly standard and popular tools, would you expect the outcome to be any different? I've seen far too many Enterprise-grade trash-fires to believe that. If the core dynamics that led to a mess don't change, you can have a "not invented here" mess or an "Enterprise Best Practices" mess or a "buy everything, build nothing" mess—but there's no simple strategic direction that won't get you some kind of mess.
About 7 years ago I was in a meeting with a former Windows core graphics engineer.
My team was attempting to figure out some extremely obtuse workflows with MediaFountain and DirectX.
We had a meeting with this guy and a couple of the other engineers that wrote the APIs and the implementation underneath.
This particular guy literally chuckled as we aired our frustrations and this was his response:
“Yeah you won’t figure those APIs out from the documentation. It was on purpose. You have to go buy the book.”
Proceeded to explain to me that this was how he, and many other core Windows engineers lined their pockets for years - write complex implementations, do the absolute bare minimum documentation, then take a 6 month sabbatical and publish a reference book that was absolutely required to actually use the API.
Apparently many of these guys made 10-20x their salaries on this grift and it didn’t really stop until the mid 2000’s.
As someone who's been both at top startups as well as boring tech companies, my experience suggests that it's not as much a difference of tech stacks or skills as opposed to priorities.
For better or worse, in a lot of tech companies, tech wins hands-down. It has to be the "right" kind of tech (suggesting pragmatic but old-school solutions not fitting the current groupthink might not pan out), but generally, tech nevertheless works (maybe because there are enough resume-driven-developers that regardless of management/politics concerns, pushing for the right tech will always get enough people on your side to win).
In legacy companies, tech alone won't get you very far regardless of its merits - if anything it's the opposite. "Too much" tech will actually be seen as a threat and you may encounter roadblocks, because the tech you're proposing is too good and will threaten some entrenched positions or entire departments within the company.
If you want to succeed as a tech guy in a big legacy company as an employee, you need to stay within your lane and not push the boundaries - the boundaries you are being given (explicitly - or implicitly as in "why hasn't this been done before? this seems so easy") are there for a reason and are there to protect some position(s), and unless you have a direct relationship with the CEO and/or investors, you are unlikely to win this battle (it took me a firing to actually understand that). Remember that you may be hired to provide business value as much as you could be hired to be a number on some manager's direct report's list where your only true job is to pad that list and otherwise not rock the boat too much.
On the other hand if you determine the limits and manage to automate day-to-day tasks well or at the very least automate the BS and make your workday enjoyable, it can be a nice cushy job that only require a couple hours a day - not to mention that doing the right favours to the right people will give you good career progression (if the company itself appears to be on solid foundations). Of course, please do any of the juniors a favour and try to explain them these dynamics in private, so they don't shoot themselves in the foot early and get fired by threatening some high-up position/department.
TLDR: don't join a legacy company because of passion, but join it if you're ready to put morals/perfectionism aside and make a decent bit of dough. The reason their tech is so shit is not because of lack of skills or money but because a lot of existing money depends on nobody having those skills. If you can operate within that environment you will have a good time.
My LinkedIn title has been “Tech Debt Loan Shark” for years and it has garnered some of the funniest cold opens from recruiters over the years. I don’t think there’s a real problem with admitting technical debt at healthy engineering orgs.
I call myself a “Loan Shark” because if you aren’t given an option by leadership to take the time to do something right, “admitting” technical debt is less about “taking blame” than it is about covering your ass. When that debt comes to bite the company later, bring your receipts and use them as leverage to do some proper technical investment driven by the engineers on the ground floor.
1. Yes, most people will tell you not to host your own email, because its too complicated/difficult to get your mail delivered reliably.
A lot of this is FUD. Yes, email is a bit more difficult to get right than say, hosting a web app behind Nginx. It's an old protocol, with many "features" bolted on years later to combat spam.
I'm not sure how email is easier to "hack," unless there is a zero day in Postfix or something. Back in the day, lots of script kiddies would find poorly configured mail servers that were happy to act as an open relay...maybe the stigma persists?
To deliver mail reliably, you need 4 things (in my experience):
- A static, public IP address with a good reputation (ie, not on any spam blacklists)
- A reverse DNS record that resolves back to your mail server's IP
- A ___domain SPF record that says that your mail server is allowed to deliver mail
- DKIM records and proper signing of outgoing messages (DMARC records help too)
2. I have a residential cable internet connection, but pay extra for static IPs. You can probably get by with a dynamic IP and some kind of dynamic DNS service, as long as you don't want to send email. You could still receive email locally if your MX recorded pointed to some kind of dynamic DNS record.
Note that some ISPs explicitly block outbound traffic on port 25 due to spammers. You might need to check with yours.
3. The only things I expose to the internet are Postfix (to send/receive emails), XMPP (to chat with others), and my web server. Everything else (calendar/contacts, IMAP, Syncthing, etc) stays behind my firewall, accessible only to internal hosts. I use wireguard on my Android phone to access these services seamlessly when I leave the house.
I've never bothered to conceal my IP address. For awhile, I experimented with using Mullvad VPN for all my egress traffic. Unfortunately I spent all day solving CAPTCHAs...wasn't worth it (for me, anyway).
EDIT: I should add, that I also have a "normie" email address at one of the usual providers that I use for really important things like bank accounts / utility providers. If I get hit by a bus, I don't want my (very nontechnical) wife to deal with sysadminning on top of my early death.
For all our personal communications though, we use my selfhosted email ___domain.
Your level as an engineer should be based on how much deep work you can do without screwing the pooch. The best engineers can be left alone for months and be sure to return with something cogent. The most junior will be required to have daily design check ins and regular code reviews as they go from start to finish on a project whose problem space needs to be well understood and mapped out before any deep work begins.
It is very damaging to an organisation when someone who cannot create understandable solutions is given the deep work breathing space to go crazy. It is a difficult but important thing to find out about candidates / probationary employees sooner rather than later. It’s important to keep a stash of pre-baked project ideas on hand so that you can use them to assess newcomers to the team, especially if you only have three months to figure out if they are able to meet your expectations before being confirmed as a full time employee.
My wife is a pediatric occupational therapist who works with children in Silicon Valley, including the some of the uberwealthy (Los Altos Hills, Portola Valley ranch wealthy, "would you just come with us on the jet this week" wealthy). She has also worked in pre- and post Katrina New Orleans, college towns, east coast, west coast. tropical islands. She's been around, seen kids at the absolute top and some versions of the very bottom (families living in shipping containers). I'm a physician informaticist. our kids are now 17 and 20. One is going to UCLA, the other is going to run out math at the local community college before he graduates high school.
I generally agree with the others who say if you can solve child-rearing, please let me know, we're going to be rich.
That said, the best advice I can offer is exemplify the adults you wish them to become. To the extent possible, raise children through benign neglect.
That said, screen time is the devil incarnate. You don't want your kids to be the first ones with a phone, or the last, but you should try to be as close as possible to last as you can.
The pediatric in-patient psych beds in California were full a decade ago. Californians are now filling all the psych beds in the neighboring states. It seems to hit young teen girls the worst. If you want a peds psych bed and you live in California, start looking at Denver or Omaha. I personally know two teen girls who are seeing psychiatrists or psychologists. Their younger brothers tend to follow. And two other girls in long term, out-of-state psych wards.
It's dose dependent. BEFORE they have devices (which, again, you should avoid like the plague) get Google WiFi and time-limit their access. If you own a TV, throw it away now. My wife threw ours out in 2007. Best decision ever. We eventually bought a projector, but it only works if it's dark enough ... Which is not much of the day.
Get a lockbox. Put it at the front door. Sometimes, shit's gonna get real and you'll need rules like "Devices go in the box when you get home", "Devices go in the box until homework is done", or "Devices go in the box and hour before bed". You should also have them reflect, even journal, on the experience so they concretely incorporate the knowledge of how they feel with and without the phone.
Once they are in either middle school or high school, encourage them to take notes in bound notebooks. My daughter prefers spiral college rule 8x11, my son prefers Leuchtturm A5 color-coded by subject. Tell them you will keep those notebooks for them until they are old enough to store them themselves.
Encourage paper books.
Buy subscriptions and shun any company that serves ads despite having paid for the subscription.
Take long walks. Get a dog. Get two. Take your kids out into the world. A lot. Every weekend.
Fuck kids sports. My daughter's gymnastics coach broke the Nasser story. Fuck kids sports. The adults are awful. High school sports are pretty healthy. JV is fine. Kids need a lifelong love of exercise, not ACL repairs in high school (record I've heard is a girl who got 7 ACL repairs before graduating college).
Tor is amateur hour. The Feds can easily deanomymize things where a server is up 24/7 servicing requests.
The author of this article is also very wrong: Anonymity is not on a spectrum. It’s all or nothing. Like a Mario game where any mistaken encounter makes you start over (and that’s if you don’t get in trouble for what you did).
First step is to understand that any system could be bugged. Every IRL confidant could sell you out. Every keyboard could have a keylogger, etc. Every store could have a security camera. Phones are giving out their MAC numbers to every cell tower and wifi radio. They now have chips you can’t turn off, and so forth.
You should also assume there is no such thing as an “anonymous” account and that every service COULD sell out whatever information you gave it. (Yes, even Telegram or ProtonMail, however unlikely that may be.)
The below is a playbook for how to become truly anonymous. Continue to live your everyday life but the below is only for your “anonymous” identities, which you can gradually bootstrap as a hobby:
The first thing you do, therefore, is bootstrap your identity by taking advantage of unlinkability that is available to you. Buy a bunch of Android phones on Craigslist for cash, for example. (Or pay a homeless guy to buy a phone in a store for you.) Do not use SIM cards at all, only WiFi. Never take photos, etc. Keep your phone off or in a faraday cage until you use it. For extra points, always use it through a VPN on WiFi at home, which you purchased using the accounts below:
Then make an anonymous google account on the Android phone. Make some ProtonMail accoung usinf such an anonymous Google account. Now you can bootstrap from email addresses.
Buy some Google Play gift cards and download some apps to get a second number. Now you can bootstrap from a phone number. Sign up to Telegram, Signal and other accounts using this. Now you have end to end encrypted messaging.
Frankly, though, realtime messaging is a bit of a luxury to continue to stay in normie world. To stay truly anonymous, you should continue to:
1. Schedule posts and mail send/receive at random times. Do not ever use realtime audio or video because it might be recorded. You might make an exception for early days of your projects when people would have no reason to go out of their way to record you — just to give them confidence you’re a real person. But afterwarss, stop doing that. Let the people build your movement for you.
2. Never mention your anonymous identity or projects from your real one, and vice versa. This means your anonymous identity MUST NEVER have confidants or colleagues IRL. Build up a network of colleagues who are “fronts” for what you do. Eventually you can step back and let the movement do things for you.
3. Pay and get paid in cryptocurrency. Have smart contracts send you the money (think Richard Heart’s Hex origin address, but actually anonymous).
4. You will only ever be able to spend the crypto on paying people for services and DeFi protocols. You can never cash out to fiat, because the IRL purchases catch up with you when they follow the money. There is a surprising amount of online services you can spend $97 million dollars on, while staying anonymous ;-) If you really do need to spend money IRL (because you went broke somehow in your everyday life) then you can cashout using cross-chain bridges and Monero to pay for goods. But still, never get ostentatious wealth IRL!
5. The weakest link then becomes your writing or coding style. Never publish any code or writing, let others do it for you. Make your communication to others from your anonymous identity sufficiently different than anything saved later would not identify you (this is the weakest link, but you can consider “playing a character” when speaking to others).
6. Any private keys that you used to sign your messages can be periodically published in some conspicuous place, effectively giving you plausible deniability about all your previous and future posts. It’s hard to prove a negative (that no one else has access to your private keys before your public disclosure.)
Once per day, when peeing, do it differently. 1. Release the stream during the in-breath. 2. Stop and hold the stream on the outbreath. 3. If not yet bored or tired go back to 1. Else - finish peeing normally. That's it.
And note that for most people, a week to few weeks of the exercise give stronger orgasms and ability to delay the ejaculation.