Hacker Newsnew | past | comments | ask | show | jobs | submit | dwattttt's commentslogin

Yes? Do you think otherwise?

Are you proposing separating responsibility from the language used to talk about responsibility? That's novel.

It's not novel at all, we do it all the time. It's very common to say "program X did Y" without making the conversation about blame or responsibility. But when the program is an AI agent suddenly using it as a subject of a sentence and saying that "agents did X" becomes a sensitive topic for some people.

Air safety is known for its blameless reviews of failures, notably it is not known for responsibility-less reviews.

And we surely need this for AI as the swiss cheese zone is getting rather huge.

My position, and the position of a large number in AI safety, is that you cannot build an intelligence that is both general and safe. The closer you get to generalized the more options the system has to do things that are wildly unsafe beyond human imagination.

This puts the AI labs in a serious bind while holding a bag filled with billions of dollars of debt.

Worse this puts governments in a multi-polar problem where even if the big public labs get shut down, black budget operations have a lot of free reign to make agentic digital weapons. Governments are not well known to take a lot of responsibility when their weapons cause damage unless they lose.


> Otherwise we could jump into any technical argument with "hold on, what actually happened was that some bits were flipped"

You can care about who flipped those bits. If someone flips the bit "autonomous weapon enabled" I'm not going to blame the autonomous weapon.


You could've included a little more nuance. An interpretation of your response is "being the most popular remotely accessible software" != "the most attacked", which would need defending.

25 years ago alache hosted about 10 times as many sites as IIS, yet IIS was always the one being backed.

I imagine anyone with any knowledge of the field could see the flaws in the claim that most popular = most attacked.

Lots of counter examples and definitely no clear relationship. IMO its up to the person making the claim to provide evidence.


Just to expand on that nuance then, "attacked" is not restricted to "successful attacks".

The most popular widely deployed software will be the most valuable to attack. That most fail is a function of other properties of the software.


> as purely empirical as the gradient descent loops

Are you suggesting that gradient descent is an empirically found and not understood technique? It was originally proposed by Cauchy in 1847, its properties are very well understood.

You might be referring to properties of the domains its being applied to.


I’m not saying gradient descent was empirically discovered, I’m saying that its use in machine learning (or elsewhere, I suppose) is itself a form of empiricism in that what it is is essentially a repeated observe/measure error/adjust cycle.

> I’m not saying gradient descent was empirically discovered, I’m saying that its use in machine learning is itself a form of empiricism. A repeated observe/adjust-based-on-data cycle

The data is the input, the output is to generally find the lowest amount of a loss function. It’s a greedy approach because brute forcing is inefficient.

It’s no more empirical than a greedy algorithm for scheduling.


> It’s no more empirical than a greedy algorithm for scheduling.

Right, GP is drawing a distinction between search, ie mechanical exploration of a space, with understanding, ie having a map of the territory such that you don’t need trial and error.


> its use in machine learning (or elsewhere, I suppose) is itself a form of empiricism in that what it is is essentially a repeated observe/measure error/adjust cycle.

"Empiricism" implies that the technique is based on observable, but not mathematically proven foundations. If a problem space is convex, gradient descent is guaranteed to converge to a global optimal solution, regardless of whether you know the exact formulation of the space.

Applying it when you don't understand if a space is convex is another question, but that's not a fault of gradient descent.


I was so primed to expect crazy I had to reread the article and your comment to notice "this bit of English isn't that crazy".

For those who won't read the article, either the word "a" or the word "an" is used before a word. Which is used depends on the first sound of the next word (not whether the next word starts with a vowel, as is commonly understood).

With this rule, only "129 of the 32,455 words in my list needed exceptions.", which is surprisingly regular.


I'm on my phone so maybe I missed something but I didn't even see that this was about exceptions to the rule? It seemed to be more about cases where the first sound couldn't be recovered orthographically. He special cased herb, for instance, because Americans inexplicably pronounce it "erb", or one and onerous because one is w and the other is on.

I can't think of a single true example to the real rule, it's an actually extraordinarily strong and simple rule as English goes.


That's how I've always understood the rule as a native speaker, even though I don't think it was ever taught (to me) in school growing up. It all depends on how the next word sounds.

You're specifically frustrated about unbounded stack recursion exhausting the stack, triggered by multiple thousands of directories? It doesn't sound like this is about multi-thousand-deep directory structures, it sounds like it's about something else.

Because even diving into it, I would agree with a prioritisation decision that puts this bug down the bottom of a priority list.


This isn't the first issue with uutils.

Canonical is just rushing the switch because they want to get rid of software with GPLv3 license, not because there is any technical merit for doing so.


If they want the default to be non-GPLv3 Rust-based that's fine, but some of us don't care (and want the same behaviour everywhere, like on RH-based systems we may also have) and they should leave the GNU as an option. Potentially both could be installed at the same time (it's what update-alternatives is for after all).

That would work, but they also don't want everybody to switch to the better alternative and nullify their effort.

That's a better thing to discuss, and I'd expect there to be better bugs to talk about to go with it. Stack exhaustion in an unrealistic environment should be fixed, but a "stop everything" bug it ain't.

When you put it like that, it seems like it's too dangerous to offer that kind of access! Maybe Google shouldn't sell it.

But can they compete with my shade grown software? It does result in a 40% markup, but there's no putting a price on being raised in a loving environment, is there.

I carefully bottle feed every function by hand, and let it out to pasture at least twice a day.

it's organic right?

GP is not presenting these as evidence for an approach, just notable facts that weren't initially obvious.

The comment concludes with "Conclusion: no, bad advice, except for very simplistic scenarios.", so I don't think I can agree with you on this. My point was that these facts don't (in my analysis) support the conclusion, and suggest a contradictory stance (in particular: planning in advance to dual-boot multiple separate distros, but not being willing to adjust the configuration after installation).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: