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

There is no code sharing anymore.

Other people's code is a security risk.

Just point Claude to a project, and make it clone it, in a safe way.


I might be falling for Poe's law, but how is code written by a server you don't control less of a security risk?

"make no mistakes"

Your sentences are weird and your praise does more harm than good for the project, in the first order at least. In the second order, comment counter is probably the most valuable ad on HN, so your comments (and mine, and all the replies) contribute positively to that.

Or you could have 2 (or 3) separate browser sessions, one for only important stuff, and one for fun.

Or Firefox containers.

Not sure how that partitions the files on disk though, would probably need some code changes to work with some kind of firejail setup.


I don't see what you don't see here.

Automating buying up GPUs when there is a huge demand or shortage* and no risk simple fraud free money from Spotify don't seem any similar to me morally or legally.

* unless there is a special offer by the shop that only allows a limited number of purchases by person. Breaking that would be much closer


I don't get your reasoning but I also don't think your conclusion holds.

A simple solution is just a saner redistribution of the money paid by users according to their listening habits. Isn't that what you've proposed?

Assume that currently:

  Alice listens 1 hour/month to Ed Sheeran
  Bob listens 730 hours/month to BobTunes
and they both pay $10 a month. Spotify gets its percentage, say 10%, then $18 gets redistributed as $17.99 to BobTunes's label and $0.01 to Ed Sheeran's label.

Solution:

Both Alice's $9 and Bob's $9 should get redistributed according to what they individually listen. In this simple example they both listen only 1 artist so both of their $9 go to Ed Sheeran's label and BobTune's label.

I think this is a simple solution against bots (or rather, the current distribution type has a serious flaw), and I don't see why wouldn't labels want this.


I haven't proposed anything, I just stated why the fairer distribution of listening time from subscriptions doesn't exist: the major labels will lose money they get from having a split pot from all subscriptions.

Your example makes it perfectly clear, even though BobTunes has 730 hours/month in this example from Bob, in the aggregate of all users listening time their share % of total listening time will be much lower than the total listening time of Ed Sheeran; Ed Sheeran will have millions of people maybe listening a few minutes/an hour while BobTunes might have low thousands, you'd need every BobTunes listener to stream orders of magnitude more time to compensate.

In the current scheme, having major artists with a broad audience listening a little gets a share of the pot that every subscriber funds, for the labels this is great, they make money from the total pot even from non-listeners of their artists, smaller artists from indie labels get a smaller share of the total pot even if they have mega-fans that only listen to them.

That's exactly why the system you describe doesn't exist, the major labels would lose money since they won't collect a share of the pot from subscribers who aren't interested in their artists (like me, for example).


> I haven't proposed anything,

Oh it was cortesoft who proposed this and not you. Should've double checked instead of going with the idea that you forgot your position in 2 replies.


I've never really considered the classic Skynet scenario, maybe because I've never watched Terminator.

But I agree with the article, it seems reasonable that when AI has enough factories to sustain itself it just decides to wipe out all the humans.

(I don't know about you all, but I was very worried around GPT-2/3 and I've been grieving since. We've already lost so much with the latest introductions of thinking machines, and it keeps taking, likely it will take our lives soon.)


> If LLMs helps programmers get heard - good

It does not, it does the opposite. It gets the programmer ignored.

Comments like "don't say this, this is LLM-ism" are the things that help the programmer get heard, whether she isn't good at English or she was just lazy and used LLM to generate text.


Based on the repo short description and the first sentence of the readme:

It is called 'Docker' as the company, and it has nothing to do with the container technology.


> Why would Google executives want to stop it?

Google and Mozilla executives. The 'why' is not public knowledge. Maybe someone has a personal vendetta against some people involved in jxl.


> you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)

It's an attack vector for images to have different thumbnail/first bytes than the final image so software still have to decode the whole image.


How would that work in an attack?

For serious, general purpose programs when thumbnails are shown people expect them to correspond to the full images, and not something else. Windows explorer, android gallery, gnome file picker etc can't show made-up thumbnails, or people would send or delete the wrong images, or would have no idea what images do they actually have.

png/webp (just as jxl) can store thumbnail in their meta, but no operating system, gallery, browser etc uses that because it has no usage that is safe.

I am not sure how easy it is to create a jxl image that starts differently from how it ends. If it is super easy then I expect programs not relying on it for thumbnailing (especially that they already have a way to generate and store thumbnails). Maybe browsers will support progressive loading, but it has no use for local images.


I believe the image would need to be present in the full size image, so I think that would limit to some extent the attack vector, but I don't know how far you could push it.

Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

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

Search: