dylnuge

>I counted about THIRTY em-dashes, which any frequent generative AI user would understand to be a major tell.

Dude, plenty of people write with em-dashes and semicolons; I personally use them constantly (and I don't use LLMs at all). Em-dashes are trivial to type on MacOS (Alt+Shift+Dash) and even on Windows—I used to have the alt code muscle memorized (Alt+0151) but now I just use the Mac version with an AutoHotkey script. I get being wary of LLM spam now that it's pretty much everywhere, but this is not the "tell" you think it is.

To be clear, you're free to dislike this writing style, but I'm 100% confident that it has been common since long before LLMs were in widespread usage.

> his real writing style when you read his actual written work is great.

You're doubling down on this not being "his real writing style" despite acknowledging you were wrong about this being written by ChatGPT?

I'm part of several small/mid-sized communities where people voluntarily do sysadmin work so that the group can have some nice shared services, and that's to say nothing of the number of people I know running personal homelabs/self-hosting setups at decent cost just for fun. You could of course say that fun, maintaining something for friends you care about, or having a dream of less corporately locked-in software are all incentives, but they're not monetary ones.

Really, it's easy to get sysadmin types interested in this; the problem is that most people aren't sysadmins and don't know any. If you really wanted a business model out of this, it'd probably be a managed service that lets non-tech-savvy users spin up their own versions of this without learning the details.

> Without this, it will work --- in the same way that open source works --- without any guarantees or commitments whatsoever.

There are plenty of successful economic models around open source, and plenty of open source software is used in high-reliability contexts. What comparison are you trying to make?

And from what they do show, it doesn't look like the sites.google.com link was actually clickable, which will reduce the success rate of the attack substantially. I'm not sure if it's not clickable because the OAuth App Title field that the phishing contents is put in won't produce clickable URLs, because the email itself has been flagged by Gmail as suspicious and disabled links, or possibly both.

From what we do see we can also clearly see the "forwarded message" details are present at the top of the email. Then the author writes that the email has "no typos" while ignoring that it has very suspicious formatting. It's still likely people will fall for it, but the article author clearly is being deceptive about how sophisticated this attack actually appears.

I've never heard anyone define memory safety that way. You can segfault by overflowing stack space and hitting the guard page or dereferencing a null pointer. Those are possible in languages that don't even expose their underlying pointers like Java. You can make Python segfault if you set the recursion limit too high. Meanwhile a memory access bug or exploit that does not result in a segfault would still be a memory safety issue.

Memory safe languages make it harder to segfault but that's a consequence, not the primary goal. Segfaults are just another memory protection. If memory bugs only ever resulted in segfaults the instant constraints are violated, the hardware protections would be "good enough" and we wouldn't care the same way about language design.

Which is a very intentional (and successful) marketing ploy by companies to get users to not care about them. It sounds like a boring technical thing instead of "we need your permission to let massive advertising networks track you around the internet" (consent isn't needed for site functionality; you can use cookies and never mention it if you don't use them for tracking).

Unfortunately this is a challenge with regulation; companies find a way to break the spirit of it as much as possible while following the letter. It's better that companies need consent to track us than not, but consent managers are dark patterns designed to deeply annoy us at the prospect of saying no.

Neither the 404 Media article nor this one claim otherwise. I think the key "AI angle" here is this (from the 404 Media article):

> Hackers are increasingly targeting AI tools as a way to break into peoples’ systems.

There are a lot of AI tools which run with full permission to execute shell commands or similar. If the same kind of compromise happened to aws-cli, it could be equally catastrophic, but it's not clear that the attack vector the hacker used would have been viable on a repo with more scrutiny.

There's not a strong differentiation between "official" policies and guidelines and "unofficial" specific consensus on Wikipedia. Individual arguments are generally built out of policy and policy is just longer-standing consensus and can be changed. It's not like there's a different group of editors setting policy from those who argue on talk pages.

> I'm not terribly convinced that software engineering is harder

I don't think it really matters what jobs are "harder". Nothing in the article is making the claim this is unique (or for that matter universal). The author's experience was in engineering management, and that's what they're writing about.

It's relevant to our industry insofar as it's reflective of an experience in the industry. I'm personally a bit cautious around claims of what is harder or easier because they tend to be pointless comparisons mostly used to dismiss valid criticism with whataboutism.

> I'm now 20 years into my career and never once have I come across this attitude. People take sick days all the time for mental health. I feel terribly for this person that they felt like they couldn't but this is far and away the exception rather than the rule.

I have definitely worked at organizations with a tech-bro startup culture where working non-stop (and drinking heavily) were idolized and anyone talking about mental health would have likely gotten a "man up"-esque speech (regardless of their gender, though shockingly these companies are mostly men). I have also worked at places where mental health was nominally respected but, like anything else, substantially more leeway was given to people perceived as high performers. I'm glad you haven't had to encounter anything like that, but I wouldn't even call it uncommon, nonetheless exceptional.

I'll say it's entirely possible this is an overreaction. I was writing up a fun weekend investigation of a weird looking project as I dug into it. There's a reason it's a series of posts on Mastadon and not anything more formal than that.

To clarify one thing, I'm not concerned that they "work in marketing". I am concerned that that the marketing page is fake: it's a bunch of AI generated faces and fake LinkedIn profiles. This does not lead me to the conclusion that they work in marketing at all.

As for your version of the script, it still strikes me as a _little_ weird (why put a self-install inside the .zshrc that is only expected to run once per system you have it on), but clearly far less concerning than the version they have in the current docs.

All code execution involves some degree of trust. There's enough here to make me personally not trust the developer, but if the information here doesn't give someone else the same qualms, that's entirely fine.

Yeah, the example was artificial to illustrate that it does come up in search results. I think I noted this later in the thread, but I originally stumbled onto this while specifically searching for some stuff on zprof. I don't recall the exact query I used, since I got pretty deeply sidetracked once I landed here.

I worked on the data warehouse for federal storage of Medicaid and CHIP data (US government-sponsored healthcare programs that cover ~25% of the population, especially people with low-income, for non-US folk).

It's not the flashiest or most glamorous project I've worked on, nor was it the most technically challenging, but I think far and away it's the most useful code I wrote by pretty much any measure of useful.

Alas, the company I was at that was doing that work moved away from it before we could finish everything we had planned to build because it wasn't profitable in the way that could justify keeping it alive once it had accomplished its goal of being a cool line item we could say we did in investor pitches.

It's not akin to that at all. External recruiters are typically paid for placement (i.e. they get a commission paid on a hired employee after they're hired, typically 20–30% of base salary). There are good ones, but a non-trivial portion are just cold-email spamming everyone whose LinkedIn profile looks even remotely like it might match the jobs they're recruiting for and forwarding on anyone who replies.

For a company/hiring manager, one great candidate a month is far more valuable than a few dozen ones who aren't even close to matching the role. They're not saying "do the work for us", they're saying "if you want us to take your sourcing seriously, send us quality, not quantity."

I suspect they're taking issue with the implication that these things are universally life changing, not that they can be meaningful at all. I have no doubt the author of this article uncovered personal truths, but the whole thing is framed as if they become an expert on everyone else's mental health by breaking free from their own depression.

Personally for navel-gazy articles like this I think it's more useful to focus on telling one's own story instead of making broad edicts and sprinkling in some science in an effort to lend legitimacy to them. What works for one person won't work for everyone, but "I was in X situation and did Y and it helped me" is far more likely to be helpful for someone else than simply "Do Y", especially when you're writing for a wide audience.