> It's fine to rewrite copyright in a way that explicitly allows things like Copilot, as long as FOSS gets to copy bits of proprietary code, too.
This is exactly what I was thinking about. If Copilot is fair use, it means that all proprietary source code, as long as they're publicly available to read, will be free to use as training materials for a hypothetical free and open source machine learning project, which I think would be a good thing. An example is a proprietary program released under a restrictive "source available" license, you can read it but not reuse it under any circumstances (and I believe these projects are already included in Copilot's training data). This is why I said fair use can be a good thing and a ruling to reduce the scope of fair use can potentially be used by proprietary software vendors against the FOSS community.
It would be even better if training from all forms of available proprietary binary code can be fair use, too. It may allow the creation of powerful static binary analysis or code generation tools by learning from essentially all free-to-download proprietary software without copyright restrictions. However, the situation of proprietary binary code is more complicated here. Reverse engineering proprietary binary code is explicitly permitted by the US copyright laws, but the "no reverse engineering" clause in EULA overrides it, and this can be a bad thing. It makes FOSS's fair use right meaningless, meanwhile giving proprietary software vendors a free pass to ignore FOSS licenses.
Thus the outcome is unclear, it may go either way, this is why I said such an issue requires careful considerations.
The position of the FSF is severely misrepresented by the title. Open the full article, you'll see that all FSF says is GitHub Copilot is proprietary software and SaaS, and all forms of proprietary software and SaaS are unacceptable and unjust. What about the copyright issue of machine learning, then? FSF says it's a new thing with many open questions, they are not really sure, right now they are calling for whitepapers from the public to hear your comments [0].
I think it's a reasonable position to take. Reducing the scope of fair use to strengthen copyleft is a double-edged sword, as it simultaneously makes copyright laws more restrictive, such a ruling can potentially be used by proprietary software vendors against the FOSS community in various ways. It's an issue that requires careful considerations.
Note: The author is not entirely serious. It's part of a series called Mystifications: A short series of semi-satirical pop science articles, called "Here's why we don't understand". The science presented is mostly accurate. The first article was "we don’t understand electricity" and now it's "we don’t understand flight". You'll find the articles more enjoyable if you think of it as a thought experiment about the depth of knowledge - the author is a physics professor and he clearly knows what he's talking about.
Usually it's inductor coils and transformers, occasionally it's ceramic capacitors (all grades other than NP0 are microphonic, SMD or not), both problems are common in switched-mode power supplies, for example, powering the calculator LCD. I've never seen a singing resistor, very unlikely.
I remember seeing an interesting Audio Engineering Society's presentation (2005) [0] on a similar problem in balanced audio interfaces. Interestingly, an old-school audio transformer is more robust, it has higher CMRR in the real world when there's some common-mode impedance imbalance in the system, on the other hand the CMRR of an opamp seriously degrades. Designs which naively rely on the opamp CMRR were responsible for many noise problems in balanced audio.
> Where Did We Go Wrong? TRANSFORMERS were essential elements of EVERY balanced interface 50 years ago ... High noise rejection was taken for granted but very few engineers understood why it worked. Differential amplifiers, cheap and simple, began replacing audio transformers by 1970. Equipment specs promised high CMRR, but noise problems in real-world systems became more widespread than ever before ...Reputation of balanced interfaces began to tarnish and “pin 1” problems also started to appear!
> Why Transformers are Better. Typical “active” input stage common-mode impedances are 5 kΩ to 50 kΩ at 60 Hz. Widely used SSM-2141 IC loses 25 dB of CMRR with a source imbalance of only 1 Ω. Typical transformer input common-mode impedances are about 50 MΩ @ 60 Hz. Makes them 1,000 times more tolerant of source imbalances – full CMRR with any real-world source.
> CMRR and Testing. Noise rejection in a real interface depends on how driver, cable, and receiver interact. Traditional CMRR measurements ignore the effects of driver and cable impedances! Like most such tests, the previous IEC version “tweaked” driver impedances to zero imbalance. IEC recognized in 1999 that the results of this test did not correlate to performance in real systems... My realistic method became “IEC Standard 60268-3, Sound System Equipment - Part 3: Amplifiers” in 2000. The latest generation Audio Precision analyzers, APx520/521/525/526, support this CMRR test!
The experienced and mysterious audio engineer "NwAvGuy" [0] praised the virtue of using two gain stages and moving the volume control away from the first input to reduce Johnson noise in audio amplifier designs [1]. It's a good example of how the basic principle applies both to mundane audio and cutting-edge science: the system noise is dominated by the first amplifier stage. Adding some noise before the first stage significantly degrades signal-to-noise ratio, but adding the same noise after the first stage is often acceptable since the signal is much stronger now. To reduce noise, you move the noise-generating resistor away in an audio amp, or cryogenically cool the resistor in a radio telescope front-end.
> One of the big claims for many audiophile op amps is lower noise. The chip manufactures make a big deal about it and audiophiles, not surprisingly, have jumped on the bandwagon. But, in reality, it’s often the Johnson Noise that limits the noise performance of a headphone amp, not the op amps. Johnson Noise is, literally, self generated noise that’s present in any resistor. The larger the resistor value, the more noise you get. Many DIY headphone amp designs have the volume control at the input to the gain stage. And it’s, at the lowest, usually 10,000 ohms. By comparison the O2 has 274 ohms in series with the input. That’s a huge difference in Johnson Noise. The way volume controls work, the noise is typically worst at half volume where you have 5000 ohms in series with the source and 5000 ohms to ground. So, at typical volume settings, you get a fair amount of Johnson Noise from the volume control that’s amplified by whatever gain your amp has. That noise typically exceeds the op amp’s internal noise. If you put the volume control after the gain stage its Johnson Noise is no longer amplified. And, as a bonus, the volume control at lower settings now attenuates noise from the gain stage. For more, see O2 Circuit Description and Circuit Design.
> To put these numbers in perspective, referenced to the old 400 mV they’re –105.3 dBr and –108.2 dBr. On the exact same test, at half volume, the Mini3 had nearly 11 dB more noise and measured –94.5 and –97.5 dB. Noise of –113 dB below 1 volt is under 3 microvolts.
Fun fact: for the most demanding RF applications, namely, radio astronomy, the front-end low-noise amplifiers are indeed cooled to cryogenic temperature by liquid nitrogen. Here's how it's done at NASA for the Deep Space Network [0]. It's a long paper, see Chapter 4 Cryogenic Refrigeration Systems, PDF page 179 (text page 159). Also, nice photos in page 183 and 188.
I always want to make a nice-looking infograph for Wikipedia on the TV color bars, with colors, labels, and explanations of the staircase waveforms, black level, color burst, etc (basically combining all annotations in a textbook to a single image). Most people have only seen the color bars as an image, but the more interesting aspects can only be seen on a TV waveform monitor, if the signal is properly adjusted, you can see the "staircase" waveform align to the etched mark on the CRT (not a particularly good graph: https://www.maximintegrated.com/content/dam/images/design/te...). Currently, Wikipedia articles on NTSC/PAL don't have any explanation on how an analog video signal is made. Too bad that I don't know anything about image editing (I did export a waveform from the ADS simulator, waiting to be visualized indefinitely).
Also, if anyone has a high quality photo of the Philips PM5544 video signal generator, please upload it to Wikipedia. This machine is an important artifact of popular culture, yet photos of the signal generator itself is uncommon on the web (and many people mistakenly believed the PM5544 is just a test card, not a signal generator), but so far there's no high-quality photo under a free license. (Or leave a comment if you have the actual machine, I'd pay $1000 for that. If I ever get the machine, I'll take a photo and upload it, and write a blog post about how the circles and lines are drawn by the analog circuitry). Finally, manuals, manuals and manuals: I'm willing to buy any documents about the Philips PM5544 (or any notable signal generators) to get them digitized. Currently the only document on the web is an issue of Philips Electronic Measuring and Microwave Notes [0] that only briefly mentions a tiny bit of its inner working.
Good news: It's very likely that the copyright has expired. If you were to scan them, remember to upload them to archive.org for everyone else to see.
Bad news: It's only the case if the copyright hasn't been renewed by the owner. Usually most owners don't renew them, but to determine whether or not this is the case, you need to go through huge catalogs of registered entries from the U.S. copyright office.
> PCB assembly shops are usually unwilling to work with externally-produced PCBs, so there's no point in making the PCB yourself.
I think these PCB processes and machines are all really designed for prototypes and experiments, it's the aspect that they're great for. If you find that you need to send them to an external PCB assembly shop, you probably shouldn't make your own board to begin with. Same for externally-produced professional PCBs - I order a raw board rather than a fully-assembled prototype because my chip is an uncommon part and they don't offer this chip for prototype assembly.
> Unless, of course, you are really good at soldering. But for me, 0.5mm pitch ICs or 0.4mm pitch connectors are way out of my motor skill league.
Speaking of soldering, I have no problem with 0.5mm pitch LQFP ICs with a good stereo microscope - for me I can just use brute force. However, my own problem is 0.5mm QFN - I have to use stencil printing and reflow soldering since I'm not good enough to hand solder that. I find a high quality board with accurate solder mask between the pin (no bridging), and with ENIG surface finishing (maximum flatness) are extremely helpful. I don't think a simple DIY PCB can handle these applications (but I'd be glad to find otherwise). But again, this was a 1 Gbps+ board.
Conclusion: I still believe DIY PCBs have their places for prototypes and experiments, but if one argues it's not useful because it cannot be assembled by a PCB shop or it cannot reach 1 Gbps, it would be demanding too much and not really fair for these simple boards.
I bet many people will say that today's circuit boards are so cheap and making one at home is just too troublesome - and these days you can't make a good digital system on a two-layer circuit boards without a ground plane and controlled impedance, so why bother? And the usual reply is that you can get a board immediately without waiting, and for low-speed analog circuits or small microcontrollers, two-layer boards are usually adequate.
I believe while both are true, there's also an important application that is not always mentioned - RF prototypes. It's still very expensive to buy a circuit board made of specialized low-loss RF laminate, such as the Rogers series. But raw boards can be purchased at a reasonable price. Having a CNC/milling machine can be extremely useful to prototype RF planar circuits in the GHz realm.
PaX's implementation of W^X (MPROTECT) is stricter - you can disallow any attempt to introduce new executable code, including writing to memory first and giving it executable status later.
I always believe allowing any forms of JIT (in userspace programs) by default creates unnecessary security risks - only a handful of programs use it. The sysadmin should have a choice to enforce strict W^X on all programs and to whitelist JIT-enabled applications only when needed.
The kernel space BPF JIT in particular, is an huge attack vector and has been repeatably exploited (or facilitated other exploits) in the past. If you don't need BPF JIT, I recommend disabling it. Sure, tcpdump or nftable may be slower, but often it doesn't matter, unless it's a cutting edge production system which actually relies on BPF JIT. It can either be removed completely when building the kernel, setting "net.core.bpf_jit_enable" in sysctl to disable it globally, or setting "kernel.unprivileged_bpf_disabled" to disable it for unprivileged programs.
Fan fact: Shugart is today's Seagate, the name was changed because the founder, Alan Shugart Shugart, had two companies, one for HDDs (Shugart Technology) and another for FDDs (Shugart Associates), both named after him. Later the FDD company was sold to Xerox but kept the name, so the HDD company had to change its name to Seagate. The rename was quite clever, it still rhymes with the original word.
That pqRSA paper by DJB is a joke, but it's mathematically correct and an interesting thought experiment - RSA really becomes post-quantum when you use a 1 TB key because it outgrows what Shor's algorithm can scale at that point. The paper is actually better, it proposed an original algorithm, GEECM, that's faster than Shor's algorithm for numbers with many small factors, then also showed pqRSA is safe from GEECM. He even submitted the algorithm to the NIST Post-Quantum Competition for review (among his more practical algorithms like Classic McEliece), it's just hilarious.
> DJB yelling from the back of the room "How much RAM does the NIST benchmarking machine have??" Dustin Moody replying "Dan, we're not benchmarking pqRSA!"
At least don't make it worse. Every time a new program uses the name "Z3", Konrad Zuse rolls in his grave. Using it for a single program shows homage and dedication, using it twice or more is excessive.
This is exactly what I was thinking about. If Copilot is fair use, it means that all proprietary source code, as long as they're publicly available to read, will be free to use as training materials for a hypothetical free and open source machine learning project, which I think would be a good thing. An example is a proprietary program released under a restrictive "source available" license, you can read it but not reuse it under any circumstances (and I believe these projects are already included in Copilot's training data). This is why I said fair use can be a good thing and a ruling to reduce the scope of fair use can potentially be used by proprietary software vendors against the FOSS community.
It would be even better if training from all forms of available proprietary binary code can be fair use, too. It may allow the creation of powerful static binary analysis or code generation tools by learning from essentially all free-to-download proprietary software without copyright restrictions. However, the situation of proprietary binary code is more complicated here. Reverse engineering proprietary binary code is explicitly permitted by the US copyright laws, but the "no reverse engineering" clause in EULA overrides it, and this can be a bad thing. It makes FOSS's fair use right meaningless, meanwhile giving proprietary software vendors a free pass to ignore FOSS licenses.
Thus the outcome is unclear, it may go either way, this is why I said such an issue requires careful considerations.