grayhatter

I would teach my kid anything and everything they were willing to learn.

I imagine you have some sort of argument, I'm guessing it's a flavor of optimizing for opportunity cost?

Try to apply that same argument to English, or math... does it still hold? I'd hope not!

Instead, teach them to find joy in life. Encourage them to find passion in something creative or expressive.

I would teach my kid programming, I'll also teach them how to make a fire from friction. It doesn't matter if they ever actually need to use it, it'll make them a better human. Maybe they find they love programming, maybe they find out they love backpacking and decide to hike the PCT.

Either way I've given them a skill that might help them with some future I can't possibly predict for them.

I dislike FUD like this :/

> I am an engineer. I hire other engineers. I run a company that ships usable software for small businesses.

> We do this every day. I'm sorry to say, we are indeed shipping in days what used to take weeks.

I've been searching for months for evidence of this kinda thing. Do you have receipts you can share? Or is it more of the same "just trust me bro"?

> I feel its a very telling skill of engineers whether or not they can communicate issues in an effective manner urgently and figure out the best course of action to unblock.

I could be this person that appears not communicate, but the reason is because I've never had a manager that could unblock me faster than if I didn't tell anyone and just did it myself. For the longest time, every manager I've ever had was mostly useless (for unblocking some issue), it took quite a few years before I got an EM that actually makes shit happen. Only then did it become a habit I had to break.

It doesn't make sense to tell someone who can't or won't help you that you're blocked on something. Eventually you just default to never asking.

> Google's going through a lot of effort to release a model that will give everyone a very poor first impression of what on-device models are capable of, souring it for everyone for a long time afterwards.

I wonder what that will do for the competition between hosted genai and local models...

> Framing it around consent is unnecessarily inflammatory and makes it harder to have a discussion, not easier.

For me the most significant problem is the lack of consent. I assume it's just not how you want to frame the problem. Ignoring the problematic parts or behavior of some sort of behavior is a common problem in modern software, and it's actually what the article is complaining about.

I'm not sure the uptime or UX of codeberg is meaningfully better?

> These things are always a cost/benefit calculation.

Yes, without a doubt! Just like all security measures. The difference being with real security measures, the security increases faster than the negative side effects. When using obscurity as a security measure, the gain is marginal at best, and even when done "perfectly" the down sides are significant.

> but it usually has a positive ROI because it's cheap to add.

My experience has always been the inverse. It is cheap to add, but more often it does nothing meaningful to the security of the system.

> I'd say obscurity is beneficial much more often than ~never.

Do you work in security? I used to think so too, back before I had to teach security fundamentals to the average software engineer.

To be clear, none of the above should be read as a refutation. I don't disagree with your opinion, per se. But in my experience, I've been frustrated many times when some non-security expert tries to add some kind of obscurity, but can't remember a single where I've thought "thank god we made this thing much more complicated". Sample bias to be sure... but if it was actually useful, I would assume I would have encountered a single time where I was glad for the added obscurity.

It's true that it's possible to increase the security of the system by adding some layers of obscurity. But not only have I've never seen it be worth the cost. The same is true about turning the system off... so when doing the cost/benefit calculation it's important to remember and account for the fact that going by history, it's never added meaningful security, and trying to work around it is almost always annoying.

> Can you substantiate this claim a bit?

I might, depending on how much objective evidence you'd demand for substance. The problem with obscurity as a security feature, is the group(s) that feels the impact the most. Heuristically, you can create 3 groups that are impacted. APTs, skiddies, devs/maintainers.

Obscurity will stop skiddies... effectively 100% ....but so will everything else. Regular updates, and a half good password also stops skiddies to effectively 100%. Obscurity has a net negative effect on the system because it doesn't increase the attack cost on skiddies, but does increase the maintenance cost to engineering. This is the vast majority of attackers you'd want to deal with.

Your Advanced Persistent Threats, will be slowed by some amount of obscurity, but they will not be be stopped by it at all, at best it's a road bump. Persistence and intent will overcome any amount of obscurity. Same idea as give enough eyes, all bugs are shallow. Given enough time, any/all amount of obscurity will be understood by the baddies.

The downsides to obscurity is it's cost both to maintenance of the system as a whole, but also to the heuristics non-security developers use to find/understand bugs. Obscurity introduces significant complexity into the system. That complexity makes it harder to find and understand real bugs, but worse, it also obscures the security of the system itself to non-experts. I do believe we'll never escape the reality that most developers see obscurity, and think "this 'secret' makes this secure" but obscurity is *not* a secret. It doesn't provide additional security/safety. It only marginally increases the time to find and deploy the exploit. Here, this extra layer of obscurity actually decreases security because developers will stop looking for ways to harden the system, because this "secret" is good enough. I.e. the obscurity added only has the opportunity cost replacing the effort that would have been spent on real security.

If you have a full security team managing the obscurity the maintenance cost to the system, will be less than the cost to your APTs, but if you don't have a full time team working on it (or at least a strong expert in both how obscurity benefits the system, but more important, a strong expert in real security), the maintenance costs will exceed the time/delay until exploitation.

It's likely that I could deploy some system securely, with obscurity layered over top. But I often don't because I don't wanna deal with it. It makes debugging harder. Depending on what specific flavor, it might also give the baddies a place to hide, because the signal of attacks no longer looks like the signal everyone expects.

If you can avoid *ALL* of the pitfalls. It will, without a doubt, increase the time to exploit. The problem being, if you're unable to avoid all the pitfalls of it, the negative aspects will have a much stronger cost and influence on the maintenance of the system, and the devs, contrasted with the cost it might have on any attack.

If the model you're using tries to claim something that is false is actually true. Yes, your model is wrong.

no because it's still possible to find the data using standard techniques, it doesn't count as obsecurity it's still possible.

I.e. just because you* don't know where something is, doesn't mean it's using obsecurity to hide.

The reason is important, because words mean things: If you say, knowledge of some secret is security though obsecurity. That means passwords are security though obsecurity.

*: that may or may not be available to the attacker.

it other words, just because a secret exists, doesn't put that secret into the 'obsecurity' category.

> Security through obscurity, as an additional layer, is good!

If and only if the security advantage it gives outweighs the the numerous disadvantages.

It never* does. That's why the comment calling it bad got so many upvotes. Mixed in with those cargoculting the meme, are people like me who have had to deal with obfuscation techniques, written by someone else, that the bad guys understood before I did.

Obfuscation as a security measure is bad, because it feels like it's positives can compete with it's negatives; but that's rarely the case.

*: effectively never

> Researchers are under no obligation to engage in coordinated disclosure and are free to sell 0day for profit.

Uh... no? If you mean legally, some people might, depending on jurisdiction. But also, ethically? yes, researchers are ethically obligated to disclose responsibly.

> Just fyi.

...

> Be glad it was disclosed at all. Be glad a patch was available prior to release.

I am glad that a patch was available. Equally I can be glad that the linux community is strong enough to respond quickly, while also being angry that this person behaves unethically.

Likewise, when people in my industry behave poorly, or unethically; I'm now the person ethically obligated to both point it out, and condemn it. Not to become an apologist demanding I should be happy watching bad things happen, when much of the fallout could have been prevented with a bit less incompetence and ignorance.

> but hardly illegal or forbidden any more than any other service restriction

Intentionally (or negligently) anti-competitive behavior is illegal in the US.

> Don't like it, cancel your plan.

Don't like being abused by a company? Just pretend it's not happening! Anyone else exactly as smart as you were, they deserve to be cheated out of their money too!

> consider how many bugs you've been responsible for over the course of your career that you didn't intend.

Through some amount of carelessness that ended up costing people money? 0.

Maybe 1 if you want to count the automated monthly charging system that did over charge (extra erroneous charges for the same month) a handful of clients too many times. I noticed before anyone else did, and all of those 1am charges were reversed before 4am. So I don't think that one counts because it was a boring bug that would have been very bad if I wasn't paying attention.

Incompetence to the point of negligence can reasonably be considered malicious. If you're an engineer by trade, you have an ethical and professional responsibility to make sure things like this can't happen. And then, when bugs introduce said complications, fixing them, and remediating the damage.

Gross negligence is malicious.

no cite?

> imagine you are a company and you sit with literal gold in a sqlite DB and you are like hmmm no let's not do this query, that makes no sense from a business standpoint.

I expect all humans to treat other humans with dignity and respect. I acknowledge that many people will likely fail to meet that expectation, quite often I'm sure. But I'm never going to accept or become an apologist for this asshattery.

It's wrong to violate the privacy and dignity of other people. The correct response when you see people hurting others is not to make up an excuse about "business need", instead some anger, disappointment, and loud condemnation is required.

Stop making excuses for those hurting others so they can make money.

> some of the code. No one is evaluating all of the code of libraries they use. You can certainly check some!

I do.

I don't review the whole repo, but every single time I update dep versions, I always look at the full diff between the two. It doesn't take that long

The daily worry was real, but not enough to take 5m out of your day to call a family member, say "hi I'm thinking about you, hope your day is going well, can't chat long I have to go back to work"?

So the solution is have AI call your "loved one" so you don't have to?

You learned how to identify them better, and the community is hiding their identity less.

Nothing happened, except maybe you forgot what it means to be a hacker.

> the other hand, most users are non-paying users, and a 99.5% availability for a free service seems to me to be a reasonable tradeoff relative to the potential cost of improving reliability for them.

If they are using your data, you're still paying just not in cash.

As a former reliability engineer, I'm trying hard to remember back when we had multiple months in a row never reaching 100% uptime, and I can't. Yes, we've seen runs of painful months, but also runs of easy months without down time.

But let's talk root cause here, the cost of improving them here, is someone caring. This isn't simply a hard problem, it's a well understood hard problem that no one who makes decisions cares about. Which as a reliability engineer is an embarrassment. Uptime is one of those foundational aspects that you can build on top of. If you're not willing to invest in something as core as your code or service works. What are you even doing?

Had I not seen this thread, I would have assumed they consented to it, and I'd never willingly interact with Raycast or it's team in any way. I still have a somewhat negative opinion, so I think it's safe to say there are damages.

The extent of the utilization is new.

The number of bots that try to hide who they are, and don't bother to even check robots.txt is new.

> Lord forbid if people disagree with you.

This is too shallow of a take. Especially when your very next point objects to what he uses as a default reference frame that you disagree with. Lord forbid drew disagree about, I think priorities, and values?

> why not change your frame of mind from "Why don't others understand how awful it is?!" to "People are seeing something I'm not, what am I missing?"

It's the same question. I sympathize with both questions, I constant feel both frustrated, and broken with how few people care about quality, and participating fairly. I try very hard to find the positive aspects "everyone" claims llm codegen provides. I'm looking hard, and can't find them. It's painfully average, often worse so when it gets lost. It doesn't and can not help me, only get in the way, what am I doing wrong? Why is everyone missing something I see as obvious? But again, both could easily be true from both frames you suggest. "Why can't people identify this as trash" could very easily be followed by "what I'm I missing from the equation?" and be the same thought/idea.

> so your article could actually contain something else than personal and emotions rants?

I mean, it's titled, A Eulogy for Vim. That seems to be what it says on the tin, no?

> I need to find ways to talk to people who want to hear and understand me.

Ask more questions. It takes work when dealing with smart people who think beyond the question you asked, adding their own context, and then replying with a different question. But those are the people who are willing to engage with you. Statements without questions can be ignored, and people who engage with different questions than the ones that you asked can be safely ignored as those who don't want to engage.

The cure to a purely adversarial conversation is educated curiosity. The educated part being being able to differentiate the threads that will lead down a tribalistic path vs those that will lead down an exploratory one.

More important than all of the above, is knowing when to walk away. It's barely a majority, but that barely majority "want" to waste your time. Ignore their DOS attempt, and save your time for people who want to engage, fairly. The fairly part being the most important.

> but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change.

> I want to do good engineering, not produce slop, but for [...]

IFF this is true, you can already stop. This will never be good engineering. Guess and check, which is what your describing, you're letting the statistical probability machine make a prediction, and then instead of verifying it, you're assuming the tests will check your work for you. That's ... something, but it's not good engineering.

> That has to be worth something.

if it was so easy, why hasn't someone else done it already? Perhaps the cost value, in the code base you don't understand isn't actually worth that specific something?

> I could see a few ways forward:

> Send it, but be clear that it came from AI, I don't know if it works, and ask the reviewers to pay special attention to it because of that...

so, off load all the hard work on to the maintainers? Where's that 2 days of eng time your claiming in that case?

> Or Send it as normal, because it passes tests/linters, and review should be the same regardless of author or provenance.

guess, and check; is not good engineering.

> Interestingly, the pro-AI folks almost universally doubled down and said that I should use AI more to gain more confidence – ask how can I test it, how can we verify it, etc – to move my confidence instead of changing how review works.

the pro-ai groups are pro AI? I wouldn't call that interesting. What did the Anti-AI groups suggest?

> the AI "fixed" so many things to "improve" the code that I completely lost all confidence in the change because there were clearly things that were needed and things that weren't, and disentangling them was going to be way more work than starting from scratch.

Yeah, that's the problem with AI isn't it? It's not selling anything of significant value... it's selling false confidence in something of minimal value... but only with a lot of additional work from someone who understands the project. Work that you already pointed out, can only be off loaded to the maintainers who understand the code base...

General follow up question... if AI is writing all the PRs, what happens when eventually no one understands the code base?

Objecting to your reply is exactly why I made my original comment. It's the same thing as the cliche; "we can talk about who's turn it is to do the dishes; but first we need to talk about why you're so upset about it?", or the other "you might not shoot the messenger, but you also won't invite him to dinner".

You might not feel the vitriol is warranted for this specific example, but you tell anyone that they are wrong to feel the way they do, at your own peril.

Is it that big of a deal? IMO, no and I say that as someone who was pissed off by it too. But then again the straw the breaks the camel's back never does seem heavy.

But in context:

> every post is turned up to 11.

Everyone is being disrespected all the time, from every direction. Here, it feels like Firefox is doing it too. Every one is already at 11, Firefox added an AI button nobody wanted, with no (real) way to disable it. And we now have an 11.05 post. As everyone paying attention would expect.

about:config where you need a search engine to find all the key strings does not count as easy in this context. And it's unreasonable to pretend it is.

This isn't as simple as making everyone happy.

It's about the disrespect of not asking. Could Firefox have asked if users wanted to enable AI features? Of course they could have, did they? Of course not, just think about how would asking would effect the shareholders!!

I don't disagree with the premise that it's hard to make everyone happy, but the problem isn't about pleasing everyone, it's about treating users with respect, and not jumping on the AI everywhere bandwagon, without asking first. Especially because Firefox has billed itself as privacy protecting, and AI is definitely not privacy focused. One might even say, privacy violating... From the privacy focused browser...