The argument is not esoteric. An Apple employee working on a reverse engineered GPU driver might (intentionally or not) incorporate internal knowledge that they are contractually obligated to keep secret or write an implementation that is too close to proprietary code they had access to, to the point that it could be argued that it is a derived work.
This sort of thing has always been a concern for projects that re-implement some existing piece of software, e.g. there were concerns early on during development of the GNU project about people contributing after having been exposed to Unix source code. Similarly, it is an ongoing concern for the Wine project[1], as well as ReactOS. The later even had a code freeze and internal audit in 2006, after allegations came forward that code had been derived from disassembled Windows binaries[2].
Exactly! That’s why companies create a clone every time they hire someone, put a clone into vat, and upon person quitting, the person is disposed of and the clone is sent to his family to take upon his role, without leaking company’s internal knowledge.
> the "IDunno" of archeology - "It most likely served ritual and cultural purposes"
If all you know about archeology is from daytime television and clickbait articles, all you know about history is what you vaguely remember from school, you never met anybody working in those fields and actually don't even have a passing interest to engage with the subject, then yes, you might be inclined to believe that's how it works.
EDIT: of course this comment accumulates nothing but drive-by down votes from arrogant computer touchers, presumably before heading off to other comment sections to discuss law, macroeconomics, quantum physics and whatever else they are experts at, having watched YouTube videos. You see, only CS requires years of study and is divided into dozens of intricate sub fields, everything else is simple, straight forward and can be "disrupted".
Remember, when it was "dig" even if it is destructive. Now its scan, map- return when the scanners get better, read scrolls of ash via scanner. We are 10 years away from a "Do not disturb ground" sign on every suspected digsite.
> Then it would be possible to reuse old embedded equipment.
Unlikely, virtualization/emulation has been a thing well before this project and you can just buy USB to RS232 adapters. There are GPIO solutions for industrial PCs other than the parallel port. Or you can simply buy new industrial PCs which have those ports.
If you find an industrial appliance controlled by genuine old PC hardware that hasn't been replaced, the RS232 ports are the least of your concerns.
In my experience, such machines usually have something insanely proprietary plugging into a custom ISA card, and whatever is connected to it usually doesn't take too kindly if the bus timings are off. And neither does the accompanying bare metal software that relies heavily on timing loops and hardware peculiarities.
I've been holding on to a couple of fanless industrial PCs as much for their cases (I could drive my truck over one, and it wouldn't even make a dent) as for any possible future uses. As time moves on, being able to use them looks less and less likely.
supposedly with a minimum of 4M RAM even! [1] I have a machine with twice that clock and twice that RAM that a friends parents wanted to toss out[2]. I spent the better part of a day getting Windows 3.11 and Office 4.3 to run. Playing around with it for a bit, I highly doubt that Windows 95 on minimum requirements would be anything but endlessly frustrating. I was not masochistic enough to try.
I ran Windows 95 on a 386SX-16 with an 80387, with 5MB of ram for a year as my main machine. It ran about as well as 3.1 did. The only real drawback was the disk space required for 95 over 3.1 + DOS.
There is no such thing as an "X11 clipboard" that something can be written to. As the poster goes on to allude, X11 has a concept of a "selection" (a primary and a secondary one).
It goes roughly like this: when you select a text in a window, the X client tells the X server "I have the selection now", when you paste in another window, the client behind the other window asks "who has the selection?" and requests the selection contents from the other client, the data is then forwarded through the server. The client that claimed ownership has to properly handle some associated requests/events for the whole thing to work.
The key point is, there is no central "clipboard" style repository like on Windows, the client that does the "copy" is responsible for the data, the client that wants to "paste" has to talk to it. If I try to copy/paste and quit the source program before the paste, the data is gone. That's why modern desktop environments usually come with a dedicated daemon that immediately reacts to selection ownership changes, grabs the data for itself and then claims the selection ownership to emulate the Windows style behavior.
If we play devils advocate, it's possible the Zoom client tries to do just that, not trusting whatever desktop environment. I don't use this software, so I'm going out on a limb here, but I'd guess that the "Zoom Desktop Client" is just another browser in disguise? It might be actually Chromium or whatever underneath that does this?
It's not chromium. But what's happening here is that even if you don't click paste, zoom is actively listening to clipboard events and consuming pastes.
Tbh, if they aren't harvesting clipbakrds data which is a weird thing to do and is unlikely, this doesn't really mean much. Anyways any X client can read.
I suspect it's something like: a bug report that said that I copied the link but when I opened zoom and pasted it it didn't it work. I.e, they probably closed the source application and thus the selection owner is gone, and the selection is gone too. This fixes that. I would test that maybe. See if paste after source app close works. Then again, if you use a ownership changing clipboard manager this shudnt be a problem.
You might be interested in GNU poke[1][2], a hex-editor type program that can actually parse and visualize the structure of binary data (using a DSL for describing formats).
Given the context and your reference to Quake, I assume by "the older days" you mean the 90s, and specifically PCs and early Windows?
If you weren't previously aware of "The Old New Thing" blog, Raymond Chen has been sharing stories about Windows 95 development for decades at this point. So many in fact, he published a book under the same name (the book is essentially a best-of collection from the blog in paper form).
The os2museum[1] blog is also a gold mine. Tim Paterson at one point tried to start blogging, sharing a few anecdotes about the early days of DOS[2]
Speaking of books, you might enjoy "Showstopper!" about the development of NT, even tough it is a bit shallow on the technical side. For the technical aspects, you might want to get it together with "Inside Windows NT" (first edition) by Helen Custer.
You might also enjoy: "Another Boring Topic" [3] YouTube channel, covering (among other things) early Windows development in excruciating detail and "Old Computers Sucked" [4], actually trying to run the software on era appropriate hardware. "Cathode Ray Dude" is all over the place but often also covers hardware and software of roughly that era[5].
A sibling comment already mentioned JWZs blog, if you have fond memories about Netscape, you might enjoy "Project Code Rush" [6].
This sort of thing has always been a concern for projects that re-implement some existing piece of software, e.g. there were concerns early on during development of the GNU project about people contributing after having been exposed to Unix source code. Similarly, it is an ongoing concern for the Wine project[1], as well as ReactOS. The later even had a code freeze and internal audit in 2006, after allegations came forward that code had been derived from disassembled Windows binaries[2].
[1] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
[2] https://en.wikipedia.org/wiki/ReactOS#Internal_audit
reply