bcaa7f3a8bbc

> 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.

[0] https://www.fsf.org/blogs/licensing/fsf-funded-call-for-whit...

Occupy Wall Street

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.

> radical leftism ("freenode autonomous zone")

Previously he also claimed "the freenode network is its own sovereign state", So I'm pretty sure he's just trolling here.

> This is a new idea, and has barely been tried. What do you think?

As the author later pointed out: it's not a new idea, FreeBSD has been doing it for decades. Nevertheless, I agree it deserves broader uses.

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!

[0] https://www.aes-media.org/sections/pnw/pnwrecaps/2005/whitlo...

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.

[0] https://spectrum.ieee.org/tech-history/silicon-revolution/nw...

[1] https://nwavguy.blogspot.com/2011/07/o2-headphone-amp.html

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.

[0] https://descanso.jpl.nasa.gov/monograph/series10/Reid_DESCAN...

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.

[0] https://frank.pocnet.net/other/sos/Philips_PM5544_PM3400_Pub...

> from 1930

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.

It seems that even a megacorp like McDonald needs the right to repair...

On second thought, not exactly the megacorp, but the franchise owners.

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!"

https://crypto.stackexchange.com/questions/59591/why-is-pqrs...

Here's his explanation of the idea:

https://cr.yp.to/talks/2017.06.27/slides-djb-20170627-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.

Yes, all HIGH severity vulnerabilities (even MODERATE) have lead time.

e.g. see https://mta.openssl.org/pipermail/openssl-announce/2021-Febr...

Imagine if computer engineers have a religion of burning down and rebuilding the entire computer architecture every 20 years, hardware and software, from scratch. Everything will be cleaner, and the problem raised by Jonathan Blow [0] can be addressed too (it's basically: modern system has low understandably & maintainability, everything is extremely complex, and only a few people in the world can understand systems at each low-level component, it only takes a moderate social disruption for the entire digital civilization to collapse").

[0] https://news.ycombinator.com/item?id=25788317

Elliptic Curve Cryptography still has an excellent theoretical security record, and will likely keep its record until the advent of quantum computers. Also, trustworthy digital signature is actually not too difficult even given the doomsday scenario - if all public-key cryptosystems are broken, as long as you still have a secure hash function, you can use Merkle signature [0].

[0] https://en.wikipedia.org/wiki/Merkle_signature_scheme

I noticed HN user fractionalhare has made a comprehensive reply to my questions, but it wasn't posted as a reply to me, so now it has fallen to the bottom of the page. You can see it here: https://news.ycombinator.com/item?id=26331747

1. Claus-Peter Schnorr, a well-established and reputable cryptographer, publishes a paper and claims he found a new algorithm for integer factorization, which is faster than the best known algorithm today (Number Field Sieve).

2. If it's all the paper says, it probably won't attract that much attention, at best it leads to a new wave of RSA keysize upgrade (or transition to ECC). But today, this paper appeared on the Cryptology ePrint Archive, and its abstract reads "This destroys the RSA cryptosystem", the use of strong language is extraordinary, a reader may interpret it as "the speedup is significant and all RSA keys can be broken." Researchers usually don't make such claims.

3. Meanwhile, it's also very suspicious for two reasons. First, this claim didn't appear in the actual paper, only the ePrint Archive web page, and it also includes an embarrassing typo. Also, the submitted paper wasn't even the latest version, which is available at Schnorr's web page, but an old version from 2019. Many people suspected that the paper was submitted by someone else, who happened to see an earlier version on the web and got too excited about it, and added the "destroys RSA" claim.

4. But now, personal communication with Schnorr confirmed the paper was indeed submitted by him, and he indeed makes the "destroys RSA" claim. Schnorr also said he uploaded the wrong file.

5. About 10 minutes ago, an updated preprint was published, that includes the sentence, "This destroys the RSA cryptosystem".

If my understanding is correct, Schnorr converts the integer factorization problem to lattice problems: SVP and CVP. Then he claims he had an efficient algorithm to solve this particular instance of SVP and CVP, thus RSA is destroyed. But, the hardness assumption of SVP and CVP in general is the very foundation that another branch of public-key cryptosystems - lattice-based cryptography - is built upon. So, if Schnorr's claims are true (uncertain and still to be determined), I can't stop to think about its impact on lattice cryptosystems: Can we use the same technique to attack them? I think it's a more important question than RSA [0] - lattice cryptosystems are the candidate for Post-Quantum Cryptography, meant to replace all of the existing public-key cryptosystems of today (e.g. RSA and ECC). Even if the attack is purely theoretical, if it can solve other instances of SVP and CVP, it'll certainly affect the security assessment of lattice-based PQC (e.g. NTRU, also LWE).

Of course, I don't know what I'm talking about.

[0] Factorization had a history of speedups, both theoretical and practical. It doesn't really affect the practical security but always comes at a cost of either decreasing confidence or constantly increasing the keysize, so I won't be too surprised if Schnorr really has new insights to speed it up further. In fact, "We need something with a better security record than RSA" was one of the main arguments for transitioning to ECC - which has already completed at large on today's Internet, RSA is only used for digital signature, almost all key exchanges are ECC now. You can't decrypt post-2016 web traffic by breaking RSA.

I'd love to read a post-mortem.

You missed its context.

In real mode, the interrupt enable/disable status is controlled by the global CPU flag, in bit 9. If you saved the entire FLAGS register when interrupt was enabled with "pushf", and later you use "popf" to restore the flags, there's no reason to use "sti", since the interrupt bit was already restored, it was perfectly legal in real-mode DOS. However, in protected mode under an OS, it's unacceptable for a single program to disable interrupts of the entire CPU, so the global CPU interrupt flag is always enabled and controlled by the OS, but each program had its own virtual interrupt state controlled by "sti" and "cli", and cannot be changed by "pushf" and "popf" anymore.

What actually happened: This problem was already recognized in the beginning, documentation contains multiple warnings and examples of correct code, but developers ignored all the warnings and instructions, continued misusing "popf" and doing it wrong in as many different ways as possible.

Under PAE, each process is still limited to a 4 GiB address space, but the total usable physical memory is extended beyond 4 GiB.

Unfortunately, PAE on Windows is a sad story. Unlike what the knowledge base said, in practice, you cannot use PAE for this purpose on Windows. Officially, PAE is only supported on Windows Server, and unusable on desktops.

Technically it's supported and almost always activated by Windows (since PAE is needed for the NX bit / DEP). But on desktop systems, Microsoft intentionally crippled PAE by locking the maximum memory to 4 GiB by a software license restriction [0]. Microsoft didn't do it because it wanted to force you to buy licenses, but due to compatibility problems, especially, all types of device drivers are problematic. Using more memory requires patching the kernel to bypass this license restriction, with unpredictable consequences due to incompatibilities.

TL;DR: PAE on Windows is practically useless.

[0] https://en.wikipedia.org/wiki/Physical_Address_Extension#Mic...

And this:

> Example 36: One program deserves a special award for the code that gets executed when you save a large scenario. It frees a data page, then allocates and frees bunches of more memory, and then a while later, goes back and touches the data page that it freed a long time ago.

> (Ironically, after writing this program, the author came to work for Microsoft on the Windows 95 team! When he learned that the application compatibility team had discovered and worked around his bug, he apologized to me in person.)