dijksterhuis

it's only now the issues are coming into the commons in a way that industry / society needs the regulatory clarity.

you mean like the regulatory clarity surrounding stealing shit to make the LLMs in the first place?

[There is] extensive litigation on the limits of Fair Use to AI development. Currently, we only have 3 first instance decisions out of the 53 cases being tried. It will likely take a decade before we understand how Fair Use applies to any one step in AI training, let alone all.

https://www.britishcopyright.org/wp-content/uploads/BCC-Fair...

The government should a) legislate and b) create test cases and run them through the courts so that we can have clarity.

if so, it would be nice if they approached the instances of stealing shit chronologically. but that's just my view.

"Keep ruling over and over" is way too strong. There have maybe been two rulings, nothing nationally binding, and most of the litigation is still ongoing.

yep

https://www.britishcopyright.org/wp-content/uploads/BCC-Fair...

This ambiguity has resulted in extensive litigation on the limits of Fair Use to AI development. Currently, we only have 3 first instance decisions out of the 53 cases being tried. It will likely take a decade before we understand how Fair Use applies to any one step in AI training, let alone all.

In the three lower court decisions so far, one held Fair Use did not apply (Thomson v Ross), one held Fair Use could apply (Kadrey v Meta) with the court suggesting more evidence was needed on the fourth factor ‘harm to the market’, and the third case held Fair Use may apply to some AI. As Fair Use is dependent on the specific facts at issue, none of these cases help educate the market or the public as to the limits of Fair Use in AI contexts.

Courts keep ruling over and over that an LLM trained on copyrighted works qualifies as a transformative work and is therefore fair use. They don't have to dismiss copyright law, this has always been allowed.

*USA only.

the UK has fair dealing, which is more restrictive

https://www.gov.uk/guidance/exceptions-to-copyright#fair-dea...

https://www.britishcopyright.org/wp-content/uploads/BCC-Fair...

distillation has been around for 12 years. it's not new in terms of ML techniques.

https://arxiv.org/abs/1503.02531

although i doubt there has been a legal case over it yet in the context of the legality of stealing shit but IANAL.

Instant Ubik has all the fresh flavor of just-brewed drip coffee. Your husband will say, Christ, Sally, I used to think your coffee was only so-so. But now, wow! Safe when taken as directed.

use plain apt, fewer letters ;)

in the next few centuries

assuming we can make it another few centuries, which seems increasingly unlikely.

fyi you can report an editorial issue via email https://www.bbc.com/news/55077304

recent jon oliver last week tonight segment on kratom and the wider 7-oh stuff.

Gas Station Drugs: Last Week Tonight with John Oliver (HBO) https://www.youtube.com/watch?v=mRZqHzDG_c8

John Oliver discusses the sprawling industry of “gas station drugs” – a world of questionable supplements and boner pills – which is posing a risk to the public by putting underregulated substances over the counter, and, more importantly, could prevent people from saving up for a Honda Civic.

addendum because that was admittedly a bit of a low effort reply.

throwing a token generator at an idea is not really fun. there’s a reason show hm rules say something about not posting quick one offs (pretty sure this was originally posted as a show hn?). the fun for someone like me is in the appreciation of the effort, not the result.

quirky idea? sure. but not fun

except it’s not really fun.

i originally wrote users from the wider public or something but then decided to edit the comment down. fair point i suppose for the ~1% of users of these sites that are super tech nerds

it doesn't remove any choice for users. users don't get a choice on the offending sites currently. they only get infinite scroll. so the eventual infinite scroll replacement will be just that, the replacement.

on removing possible UI design choices for social media companies -- i have a very small violin on hand.

people have done regex-filtering hn clones, ai to detect the ai, etc. been a few show hns. but threads like this would get caught up in that (no perfect solution).

i just manually hide anything ai related.

first pass: hide anything related to AI on front page.

second pass: is there anything interesting left on the front page?

sadly the answer to the second question is often no nowadays :/

I don't think self-hosting gitlab is enough to claim ISO/IEC 27001

probably not. but it does mean you can focus on the rest of your stack rather than having to go through every single process from the ground up.

i learned the SCRAP mnemonic a long while ago: Situation; Complication; Resolution; Actions; Politeness.

works when the recipient is attuned to it. when the recipient is attuned to flowery/over-polite language i've found they can get upset/assume you're being rude/dismissive.

one reason (among others) — compliance.

a corporate/b2b saas environment without stuff like this is often a non starter.

- SOC2

- ISO/IEC 27001:2022

- ISO/IEC 27017:2015

- ISO/IEC 27018:2019

- VPAT 508

https://about.gitlab.com/security/

no mention of these on the forejo site, so i can’t put “our internal software is all SOC2/ISO NUMBER compliant” as a bullet point on a slide deck.

it is theatre. but it’s industry theatre.

non-deterministic system behaves non deterministically. in other news, water is wet.

But are they problems worth spending time?

They're not problems people need solved. They're problems people think they want solved. need != want.

the high street bakers needed reliability with improved efficiency at an affordable price (cost of risk). they didn't need improved efficiency, less reliability and still really expensive.

yeah i'd agree with you there with lack of experience. and that was definitely a thing at my place. i think it plays a part in the research stuff too. cos if without relevant experience a lot of bad assumptions get made.

"FOSS is universally unreliable" was one of such assumptions i had to push back against 5 years later. they meant academica produced software. but they assumed all foss is the same as all academica produced software.

Where did the story go sideways? At what point what character could have prevented the disaster?

for me the company should never have existed in the first place. and that lies with the founder. starts with them. falls on them.

i'm biased i suppose because my part in the "10%" part of my story was finding out just how little research anyone actually did... they all just wanted to play the role of important businessmen, big brain dev, co-founder etc. etc.

thank you for writing this. i'm still trying to come back from crashing and burning at that place. i might read this a few more times as it felt like my story too. the another Engineer part touched me. that's who i was in my story. it hurt.

edit -- https://news.ycombinator.com/item?id=48774444 hits the nail on the head with their last bullet point. bad leadership innit.

learned a similar lesson at last company. should have left after six months as "lead" engineer (of two people, not really much to lead there... which is related to why i crashed and burned out, funnily enough)

i was definitely the another Engineer in my story.

original title too long:

Startup sues Palo Alto Networks' Koi Security, saying an AI-hallucinated report falsely linked it to Chinese espionage

when i was reading this i thought of writing some quick and dirty cli tool that checks commit co-authors. wouldn't be perfect, but would eliminate a good chunk of low hanging fruit.

previous Show HNs

- https://news.ycombinator.com/item?id=48496242 -- 11 points | 20 days ago | 7 comments

- https://news.ycombinator.com/item?id=45174724 -- 64 points | 9 months ago | 40 comments

blog post 3 days ago: https://news.ycombinator.com/item?id=48712122

without knowing the people involved, or any further nuance/context -- i had a PhD supervisor like this. he was always looking for holes. always disliked the way i was proposing something. always looking to find the thing that's wrong. the way to deal with him was to have thorough answers to as many questions he might ask before he asks them. learning to predict his questions was the real training for my PhD.

it taught me to show my working, as if i were in math class. which meant fully writing things up before meeting with him.

how the reviewer would prefer to design it

sounds like they're trying to find holes. dunno if you do this already, but if not, try to fill the holes beforehand with conclusive and extensive write up (show the working). maybe ask them before coding how they would design X and then dedicate a section of the write up to why X cannot or was not designed that way.

answer their questions before they have a chance to ask the questions.

it's still weird. if i'm talking about something i wrote 10 months ago i'd say something like, "when i originally wrote this i was trying to say ...".

not "when the author wrote this, he was trying to say"

I've found real and significant bugs doing code review. In large part because I understand the codebase better than the author. That's finding and preventing bugs.

this. was a lead in small businesses working with very inexperienced people in one team -- literally having to teach them git -- and another with outsourced devs who had one day a week for us and could barely remember cos they context switched onto other projects for the other 4 days a week etc.

my job was to always know the most about the systems, what we're trying to achieve with the systems and what is in the codebases. answer questions. send links to people. know which devs to ask for more detail etc. i never necessarily knew everything about frameworks, libraries, package updates, new tools etc., but i knew our system/devs/goals/products inside and out.

as i said to several people, your first PR submission is just your first public draft. i will find bugs. i will find things that need changing. it's not personal. it's just about making your PR better than it was. this is an opportunity to learn from me.

the author of the article seems to be considering code review from an idealised situation -- this never occurs in reality, most of us have to make do.

and that means changing focus of code review for what is needed, rather than what is ideal.

A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.

it’s not always a safe assumption.

planned a full rewrite of a product at last company. i knew things were fucked 3 months in. i started really planning the rewrite 1.5 years in.

that year taught me just how fucked it was: bugs galore, race conditions, crashing frontend, testing in customer environments, data loss, rolled their own security (users from any group could login to any other instance).

previous big brained devs really fucked it and there wasn’t much of anything to show for it.

i fixed a bunch of it. but it still needed a rewrite because they had built the wrong thing. which was the bigger issue i realised 3 months in.

good rewrites are good. bad rewrites are bad.

you’ll only find out which kind of rewrite you’re doing once you start it.