The two challenges there are firstly - that analog design has been a separate electrical engineering school for most of a century, so there are few who could design it - and secondly - that every single chip will have subtle variations in its computations, necessitating some sort of model finetuning per chip. Possibly the chip could be characterised at the factory, and ship with the characterisation data burned into a controller rom or something, but if that doesn’t pan out the whole thing is likely a non-starter.
If it could be made to work, you could run a fable-grade model in tens of watts.
This made me smile. A true test of human-like intelligence. Maybe they could take some entry level jobs (“I can make a nice Wordpress site”) and build a CV?
Wouldn't B's publication of the information make it by definition no longer a trade secret? It is now public knowledge, regardless of whether the current or former engineers might be liable for the original leak.
Any other interpretation would mean trade secrets have essentially infinite protection/NDAs apply to all of humanity.
The NDA doesn't apply to people who haven't signed it, but copyright law does. If you know the material you're receiving is under copyright (eg proprietary source code), and you publish work based on that copyright material, the fact that it's now widely available is not an effective defense against claims of copyright violation.
Person B in this scenario hasn't violated the NDA, but they could be sued for copyright infringement.
The point of a clean-room implementation is that the only thing passing from A to B is a detailed specification written from scratch, because functional details cannot be copyrighted.
Which I think you know, so I don't understand your argument.
You said in another comment "However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer."
It being proprietary and/or secret information doesn't affect the copyright of the clean-room output. If there's trade secret implications those are worth discussing, but as a separate issue.
Functional details can’t be copyrighted, but once you’ve seen a copyrighted implementation, it’s an argument in court over similarity and function.
A clean room implementation by people who haven’t seen the original work means there can be no discussion of copying, which makes it much cheaper and more reliable to fight an infringement claim.
Assuming I understand what you mean by "people", then this comment sounds completely correct and contradicts your last comment.
Your last comment said person B could be sued for copyright infringement. But the essence of clean-room is that person B "hasn't seen the original work which means there can be no discussion of copying".
Person A is not giving the original documents to person B, they only give functional details.
One of your earlier comments had a vague description of clean-room that wasn't clear on this aspect. But you were responding to someone that gave a clear and correct definition, so I assumed you were also using the actual definition.
If you've actually been talking about fake not-really-clean-room then sure someone could get sued. But that's obvious. The suggestion by alightsoul was actual clean-room.
Arguing in court over whether the details in question were functional or copyright is time-consuming (thus expensive), and risky.
Once it's established that person A has given _any_ details to person B, the upper bound on "expected cost of an effective defense" is dramatically higher.
> Once it's established that person A has given _any_ details to person B, the upper bound on "expected cost of an effective defense" is dramatically higher.
Yeah but that's what clean room is.
You said "A clean room implementation by people who haven’t seen the original work means there can be no discussion of copying, which makes it much cheaper and more reliable to fight an infringement claim."
Something doesn't add up.
If you were thinking about a situation where the developers don't get the original work, and nobody feeds them info based on the original work either, that's not clean room, that's something much harder.
So what if person a and person b are unrelated and person b found it on their own? There are countries in the global south that never had an industrial revolution and don't speak English and never had factories for export nor made anything in a factory industrially that isn't building material and food and maybe fuel for local consumption so they've never had an IP infringement case
I'm seeing people who _used to be_ like that losing that understanding without realizing it's happening - they have a superficial idea of what the code is doing, enough to feel like they understand it, but the change is apparent when watching them handle something unexpected.
That's certainly what I expect to happen. LLMs will ruin your software if you don't hand-hold them, but it'll take time for that to happen. And until that does happen, businesses hell bent on using them won't have anything to push them into realizing what a mistake it was to use them.
1. "Nonsense, if it was a code-quality issue from the AI stuff, we'd have seen problems sooner, like in the first few months or a year. Oh, sure, some engineers complained, but that was just an adjustment period because they stopped once we told them we didn't care and mandated that they up-skill into the new AI-centric workflow future."
2. "The bold new AI initiative I put into place can't possibly be wrong, this failure is on the engineers who were responsible for overseeing its operation. This is supremely disappointing because we made their jobs so easy, they no longer have to write code, just review several dozens of pages per day with unremitting paranoid vigilance and attention to detail."
This, plus anyone responsible dodging that as soon as possible via job hopping. Harder to do in the current job market but internal transfers are still available, most of the time.
I was pretty early in the LLM stuff and I got called out on using it back in the day, because I showed the exact symptoms we see now, but as soon as management jumped on the train all the coworkers did a 180 and I alt tabbed out into a different department thinking it would change something... well it didn't :'D
I guess it will take some years till we are sane again or not...
I revisit it to see if the promises are unbroken now from time to time with every other update and these days it doesn't look so good. It is non deterministic all the way down.
If you're going to put the graphics and NIC into separate VMs, surely the secure screen can be another of those semi-privileged VMs rather than part of dom0
Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places.
Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places.
If it's technically.implemented uniformely without thought of user access patterns, then yes it's a bad idea causing friction and frustration.
If I drag&drop a file in an app or it's icon, or by right click. The permission would be implicit.
For configuration files they could be part of allow rules, since they are so common if they follow the XDG specification.
For saving files, flatpak apps could be allowed to save anywhere in the users home sub-directories (not home top-level) as long as it doesn't overwrite any existing file. There are downloads, public, documents pictures, videos, that are barely used by default.
There is plenty of room for better desktop based integration, while of course lacking funding and care for users (thinking of particular devs in this case).
Currently it's a mishmash of separately using flatseal (and equivalents) and having your fingers crossed if you're likely to exfiltrate or not your data.
I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently.
If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
The list of files that such app would try to access by default on initial startup would be finite and well defined. So, a Flatpak package of such app should already, if done "properly", (I'm just imagining here, not an expert) include allowed access to those paths by default.
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
I don't think this is going to work out. With the way progressive loading works in JXL, you don't really hit "good looking" points aside from at DC resolution.
Just being able to get 1/2, 1/4 or 1/8th of the image resolution would already cover most of the srcset use case and the results are good enough for many existing image decoders to already use this optimization for the decoding if not the network part.
reply