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

> AI writing smell is as bad as bad grammar

It sounds to me like you want to censor perfectly fine phrasing just because AI rolled the dice to use it. Let's not forget that AI learned to "speak" from people in the first place.

Not to mention that as people shift their phrasing to avoid being accused of using AI, the AI will keep evolving, training on the new phrasing and then adopting it, too.

I understand the language evolves, but evolving language just to sound different from AI feels like wasting effort better spent elsewhere. On actual substance of the message for example.


You can believe what you want. I don't censor bad grammar, but it's not good writing, and it will have negative effects on someone's writing and who will read it. You can have your fingers in your ears or you can adapt.

> I don't censor bad grammar.

We're not talking about bad grammar, but sentences that are correct and sensible, and if you wrote them before AI, nobody would bat an eye. But because they are used by AI, these days they make people dismiss the whole piece.

It's not really different from dismissing people because they happened to use the same phrasing as Stephen King. You can't even tell if it's because they read Stephen King that much, Stephen King wrote it for them, and they are now trying to pass it as their own, or just coincidentally arrived at the same literary construction.

Whenever I see those threads, they usually don't discuss the merits of the writing. They claim that AI must have been used, so it's not even worth reading.


When I lived in Sweden I had an 8-digit pin and biometrics enabled, indeed.


> I think the real problem is Google Play Services. It's far, far too tightly integrated in a way that it just seems like Android was designed to be unusable without.

Wasn't the point of Play services to enable keeping OS "updated" regardless of the manufacturer schedule? Which is to say: they are tightly integrated because they were designed to be part of an operating system that Google can keep updated through Play Store even if the device OEM is slacking on porting upstream updates to the users.


No, the point was to keep Android proprietary.


I think it was one of those cases where "the road to hell was paved with good intentions".

I'm old enough and was very pro-android in the early days when it first released. I absolutely remember the frustrations around having vendors just REFUSE to update the OS on devices. Even things that were brand spanking new often got left to rot, and the OS updates in those days were genuinely meaningful software updates - Lots of new capabilities.

So I was actually ok with Google going down the route of moving critical software into an installable package that they controlled, that would provide a way to get new capabilities onto devices that manufacturers didn't give a shit about anymore.

---

But the problem is that "Google" today sure as hell isn't the google that I liked back then (and even that google was starting to shift tone).

And now this package is a backdoor that they can use like a beat-stick to force vendors to stay on their version of Android, and it functions to make "Android" (the distro that users actually use) functionally closed-source and non-permissive.

---

I still strongly believe that the appropriate regulation for this situation (across both iOS and Android) is that the company that makes the OS should be prohibited from running any sort of app store, and app stores must be selectable at device initialization (ex - the Internet Explorer ruling, but for app stores).


Why would you want a forced selection of app store? Just make it so you can execute executables. If the user wants an app store, they'll install one.


Which is why, The Year of Desktop Linux is the fragmentation it is on, versus using Android, ChromeOS or WebOS.


Because a selection of app stores totally isn't fragmented. How will you get on that list, by the way?


PlayStore gets you on Android, ChromeOS.

WebOS is anyway only relevant for TVs, and any PWA will do.


Somewhat, but only relevant when it comes to things like WebView but not other things. If there is a vulnerability elsewhere, your device on an older OS that the manufacturer has stopped supporting will not get any patches.

Google may think it's important to keep WebView always up to date with Play services. I couldn't care less. I still have to buy a new phone to get all updates.


All the speedrunners just kill the guy in the jar to get the medallion: you don't have to talk to him.

Also, all you have to do in the Snowfield is to take a teleporter: that's not very secret, is it?


It's not secret, but it's not exactly easy; you can find one part of the medallion just by exploring (iirc its description says what it's for), but not sure if the second half is that straightforward.

And even then, while an item may say "use it here", if it's been dozens of hours since you got it you may just straight up forget about it.

That said, I think that the target audience for the DLC was always people who thoroughly played through the game.

Same with the other games' DLC; for Bloodborne's you need to be yoinked by an invisible enemy while in posession of an item; while it's very possible people were accidentally yoinked on their first playthrough, they will forever know that the item is a trap and will avoid getting yoinked.

(unless the item in question explicitly said "get yoinked to go to DLC", I forgot)


Oh, yeah, the Snowfield itself is secret enough, but getting to the palace afterwards is just a matter of exploration. The teleport is not that hidden.

FWIW, after you get one half of the medallion, get invaded by Gideon's lackey and then talk to Gideon, he will tell you to look for the Albinauric woman, so at least they give you this much.

All in all, I find the quests in the base game relatively straightforward, but anyone with any prior experience in their games will have an inkling that if they care about quests' results, you need to double-check with the wiki.


Well for DS1 DLC, you had to kill an enemy from one of the latest area you unlock, then go to the back of an early zone, without any indication that you had to do so.


> That said, I think that the target audience for the DLC was always people who thoroughly played through the game.

That's true, but it is strange that you get there and get early-game upgrade materials, like Smithing Stone 2, etc. It seems like they wanted to emphasize that the Scadutree Fragments are the important things for scaling, and not your Base Game level, but you already have to be pretty high level and upgraded to beat Mohg.


The peasants did not live for long, though, did they? Hard to say if and how the diet contributed, but just because people rarely ate meat then, for example, doesn't necessarily mean it's better for your health. Even if we could agree that people these days eat too much.

People talk about how we spent generations adapting to certain aspects of diet, and so following the habits of old is surely safer, but seem to forget that evolution only really "cares" about producing offspring, not your longevity, or quality of life in old age.


Code review just means you need an accomplice. It makes it harder, not impossible.


Not even that. Bury it in a sufficiently-large PR and there’s a very good chance it’ll be rubber-stamped because no one wants to take the time to carefully review the entire set of changes.


Or be convincing to a LLM.

Humans reading code is so "legacy"...


I never got the idea from git itself that changing history is encouraged. What makes you say otherwise?


git rebase

Is a widely accepted command as a daily part of a development workflow. This command rewrites history.


Its mere availability is not "encouragement."


I don't think the internal design is/was that similar. We switched from CVS to git, and were evaluating multiple choices. What tipped the scale in the end was our trust in the internal data model, which for git was the idea that it stores the snapshots, and they are immutable. The diffs you can get out of it are calculated on demand. Even if on-disk storage can end up using some diffs to save on space, the actual conceptual model of every operation is based on those snapshots, and that is also how every new commit is stored before repacking the repository.

This appealed greatly to us, and always meant that it is effortless to undo any operation because it only creates new snapshots, while the previous ones stay there for a while in case you need to recover the previous state.

This is in contrast with Mercurial, where the data store is (was?) a sequence of diffs, and then the state of the working tree at any time is reconstructed on demand from those diffs.


Meh. While I agree that Mercurial had easier to use CLI, there was maybe 1 time over the last 15 years or whatever when I needed anything other than git reset --hard.

Although, I suppose part of this is just that manipulate index with something like lazygit.


The way I remember it was that bookmarks were added because the git branching model became so popular. The "branches" in Mercurial were allegedly not designed with short-lived feature branches in mind.


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

Search: