Put any distro in front of me and provided I don’t need to master it, I’m good. Ubuntu is fine. Debian is fine. RedHat is fine. Fedora is fine. I even have a tiny low-end system that is using Bohdi. Whatever. We’re all using mostly the same kernel anyway.

90% of what I do is in a container anyway so it almost doesn’t matter; half the time that means Alpine, but not really. That includes both consuming products from upstream as well as software development. I also practically live in the terminal, so I couldn’t care less what GUI subsystem is in play, even while I’m using it.

The only time I’ve encountered people that care a little too much about what distro is being used, is right after having transitioned to Linux; the sheer liberating potential of the thing can make you lose your head.

I’ve come across a lot of professional bias about Linux distros, but that’s usually due to real-world experience with tough or bad projects. Some times, decisions are made that make a given distro the villain or even the hero of the story. In the end, you’ll hear a lot of praise and hate, but context absolutely matters.

There’s also the very natural tendency to seek external validation for your actions/decisions. But some people just can’t self-actualize in a way that’s healthy. Sprinkle a little personal insecurity into the mix and presto: “someone is getting on great with that other Linux I don’t use, so Imma get big mad.”

I agree with the post. It’s coded derogatory speech while being technically correct. Personally, I would go as far to say it’s a dog-whistle and is absolutely a flag, especially if it renders any speech clunky and labored, or side-steps a person’s gender transition status.

Also, here’s something I’ve observed that may be relevant.

IMO, most of the time people use gender when telling a story, it’s not relevant information in the first place. In light of recent events, public awareness, and politics, non-gendered speech (in English at least) is automatically the most inclusive way to go and it’s a good habit to develop. The exceptions here are where it’s information that supports the story, disambiguates complicated situations (e.g. talking about a drag persona), or where it’s gender affirming in some way (e.g. respecting pronoun preferences).

I see this happen a lot, especially where woman/female is used as extra information when expressing anger, frustration, and disgust. For example, I hear “this woman cut me off in traffic” far more than “this man cut me off in traffic”, with “this person” or “a BMW driver” as a maybe-neutral-but-also-likely-male coded qualifier. To me, it suggests a kind of negative bias for gender, which may or may not be unconscious (depends on the person). It may seem like a small thing, but it’s freaking everywhere and it’s gotta stop.

For the rare occasion where sex or gender supports the story, “my teacher, who is a woman, …” or “my teacher, (s)he…” does the job. Yeah, it’s is a bit tougher on the tongue, but you should only need to say it once for the whole telling.

It’s worse than that. They think that toeing the line and refusing to deviate is the strong position to take here. Always has been.

It’s also worth noting that the launch PS3 also had a whole PS2 inside of it, which partially explains the inflated price point. I say partially since I’m prrety sure that a PS2 slim cost a lot less than $330 in 2006 dollars; they could have just bundled both consoles or offered a rebate on a PS2 purchase and called it a day.

In a paper bag no less. You guys are fun.

Thank you!

people customers always just cut it off 5 words in for some reason…

Fixed that for ya. ;)

I firmly believe this is how we wound up with tabs as a feature in the first place.

Great jebus. It looks like something Ginger Billy would build. There’s no way that’s street legal, nevermind the lack of license plate.

Mom, I want a cybertruck.

Honey, we have a cybertruck home.

Cybertruck at home:

Honestly, this is why I tell developers that work with/for me to build in logging, day one. Not only will you always have clarity in every environment, but you won’t run into cases where adding logging later makes races/deadlocks “go away mysteriously.” A lot of the time, attaching a debugger to stuff in production isn’t going to fly, so “printf debugging” like this is truly your best bet.

To do this right, look into logging modules/libraries that support filtering, lazy evaluation, contexts, and JSON output for perfect SEIM compatibility (enterprise stuff like Splunk or ELK).

Heisenbugs are the worst. My condolences for being tasked with diagnosing one.

• Gratuitous amounts of energy
• Energy Legs
• 400 babies

Last time I did anything on the job with C++ was about 8 years ago. Here’s what I learned. It may still be relevant.

• C++14 was alright, but still wasn’t everything you need. The language has improved a lot since, so take this with a grain of salt. We had to use Boost to really make the most of things and avoid stupid memory management problems through use of smart (ref-counted) pointers. The overhead was worth it.
• C++ relies heavily on idioms for good code quality that can only be learned from a book and/or the community. “RAII” is a good example here. The language itself is simply too flexible and low-level to force that kind of behavior on you. To make matters worse, idiomatic practices wind up adding substantial weight to manual code review, since there’s no other way to enforce them or check for their absence.
• I wound up writing a post-processor to make sense of template errors since it had a habit of completely exploding any template use to the fullest possible expression expansion; it was like typedefs didn’t exist. My tool replaced common patterns with expressions that more closely resembled our sourcecode¹. This helped a lot with understanding what was actually going wrong. At the same time, it was ridiculous that was even necessary.
• A team style guide is a hard must with C++. The language spec is so mindbogglingly huge that no two “C++ programmers” possess the same experience with the language. Yes, their skillsets will overlap, but the non-overlapping areas can be quite large and have profound ramifications on coding preferences. This is why my team got into serious disagreements with style and approach without one: there was no tie-breaker to end disagreement. We eventually adopted one after a lot of lost effort and hurt feelings.
• Coding C++ is less like having a conversation with the target CPU and more like a conversation with the compiler. Templates, const, constexpr, inline, volatile, are all about steering the compiler to generate the code you want. As a consequence, you spend a lot more of your time troubleshooting code generation and compilation errors than with other languages.
• At some point you will need valgrind or at least a really good IDE that’s dialed in for your process and target platform. Letting the rest of the team get away without these tools will negatively impact the team’s ability to fix serious problems.
• C++ assumes that CPU performance and memory management are your biggest problems. You absolutely have to be aware of stack allocation, heap allocation, copies, copy-free, references, pointers, and v-tables, which are needed to navigate the nuances of code generation and how it impacts run-time and memory.
• Multithreading in C++14 was made approachable through Boost and some primitives built on top of pthreads. Deadlocks and races were a programmer problem; the language has nothing to help you here. My recommendation: take a page from Go’s book. Use a really good threadsafe mutable queue, copy (no references/pointers) everything into it, and use it for moving mutable state between threads until performance benchmarks tell you to do otherwise.
• Test-driven design and DevOps best-practice is needed to make any C++ project of scale manageable. I cannot stress this enough. Use every automated quality gate you can to catch errors before live/integration testing, as using valgrind and other in-situ tools can be painful (if not impossible).

1 - I borrowed this idea from working on J2EE apps, of all places, where stack traces get so huge/deep that there are plugins designed to filter out method calls (sometimes, entire libraries) that are just noise. The idea of post-processing errors just kind of stuck after that - it’s just more data, after all.

My unqualified opinion: I think It’s easier to craft a wig this way.

I’ve found that when I’m exhausted, I literally don’t have the energy/bandwidth to be anxious, let alone indulge in any mild dysmorphic hallucinations from the mirror. Even my typical ADHD symptoms are muted a bit. A tired brain is a much happier brain; just don’t ask me to do math or anything complicated and we’re good.

You say this, but have you ever tried to drive a car (sober) that is packed full of drunk people? It’s not easy, and they all might just get you pulled over anyway.

Outright prohibition never works. They have to get a lot more clever to work against addiction.

Reading the article, I see why this is a problem to be addressed. At the same time, I’m not sure how in the world you would directly “fix” this other than outright banning unruly customers after they cause problems.

The best course of action might be to quietly work with restaurant managers in major airports to start watering down mixed drinks, and serve lower-gravity beer and wine, on heavy travel days. I’m mostly sure this is how amusement parks operate; they just need to consult with Disney or SixFlags on this one. The threat of airlines (or the airport) banning heavy restaurant customers might be motivation enough. That way, restaurants make more money, airlines have (maybe) less nonsense to deal with, and there’s no documented limit on beverages.

I’m pretty much in this camp.

I’ve tried some of the stimulant treatments, but they leave me feeling completely wrung out by the end of my shift. And being on that stuff for more than 12+ hours just seems like a recipe for heart disease.