anonymousisme

Lots of tech giants are forcing DoH so their apps can phone home despite safeguards such as pi-hole. There's not a lot that you can do about that (if they are using certificate pinning, which they probably are). You can however do something about 8.8.8.8 (and 8.8.4.4). Just put a static route in your firewall that points those to your DNS of choice (or to a black hole).

I do not understand why more people don't switch to a decentralized DNS such as OpenNIC (https://www.opennic.org)

Governments have abused their control of DNS. A distributed system (with trust and safeguards) is the better way.

I've used the LKML to contribute changes, and I'm also an amateur radio operator. I guess that makes me a fossil.

Linux has had the LKML for almost three decades. It still works well for them.

https://en.wikipedia.org/wiki/Linux_kernel_mailing_list

Not directly related to the article, but I've been doing a lot of interesting stuff with WireGuard for the past few years. I've observed some odd behavior by some mobile service providers. Right now I have two permanently deployed WireGuard VPNs using terrestrial wireless carriers. One VPN uses AT&T Wireless while the other uses T-Mobile. That AT&T VPN worked fine out the box. The T-Mobile VPN required some odd tweaks to MTU/MRU in order to get it working. I found that the MTU on the mobile end needed to be 1220 or less, and the MTU on the remote end needed to be 1380 or less. This took a while to debug.

Is Whoogle a Lougle wannabe?

https://whatculture.com/film/10-famous-things-invented-movie...

Never visited that shop because I could fix my own stuff, but I am from the area and frequented many other electronics shops. The only one still standing is Torrance Electronics (3 miles away from where Acme was). Torrance Electronics opened around the same time as Acme.

https://torranceelectronicsinc.com/

The thing I liked about Aztec C was that they gave you the source code for their libc. You could easily write and integrate your own I/O drivers for stdin and stdout. It really made embedded C development easy.

I was thinking the same thing. You don't get something for nothing. Assuming the water heater is in the conditioned space, it will just make the central heater work harder (and consume more fuel) during the winter months. Maybe this is offset during summer months when it can help the AC cool the space.

None of this applies if the water heater is not in a conditioned space, but that's not feasible in (common) environments with cold winters.

Interesting writeup here: https://etherealmind.com/ethernet-jumbo-frames-full-duplex-9...

It claims that CRC32 is sufficient to detect errors in frames as large as 9000 bytes.

From what I recall, the 1500 number was chosen to minimize the time wasted in the case of a collision. Collisions could happen on the original links because instead of point-to-point links like we have today, they all used the same shared channel. (This was in the days of hubs, before switches existed.) The CSMA (Carrier Sense, Multiple Access) algorithm would not transmit while another node was using the channel, then it would refrain from transmitting by a random length of time before sending. If two nodes began transmitting at the same time, a collision would occur and the Ethernet frames would be lost. Error detection and correction (if used) occurs at higher layers. So if a collision occurred with a 1500 byte MTU at 10Mbps, 1.2mS of time would be wasted. IIRC, the 1500 byte MTU was selected empirically.

Another reason for the short MTU was the accuracy of the crystal oscillator on each Ethernet card. I believe 10-Base Ethernet used bi-phase/Manchester encoding, but instead of recovering the clock from the data and using it to shift the bits in to the receiver, the cheap hardware would just assume that everything was in sync. So if any crystal oscillator was off by more than 0.12%, the final bits of the frame would be corrupted.

I've actually encountered Ethernet cards that had this problem. They would work fine with short frames, but then hang forever once a long one came across the wire. The first one I saw was a pain to troubleshoot. I could telnet into a host without trouble, but as soon as I typed 'ls', the session would hang. The ARP, SYN/ACK and Telnet login exchanges were small frames, but as soon as I requested the directory listing, the remote end sent frames at max MTU and they were never received. They would be perpetually re-tried and perpetually fail because of the frequency error of the oscillator in the (3C509) NIC.

Works fine with JS turned off (via NoScript).

Reminds me of NinjaTel.

https://en.wikipedia.org/wiki/NinjaTel_Van

https://arstechnica.com/information-technology/2012/07/ninja...

One possible way to approach this would be to write a simple function generator (square wave) and sweep it across the audio spectrum, while also recording the speaker output level by way of a connected microphone. The resonant frequency of the speaker (or the microphone) should be observable as the peak amplitude seen by the mic. Once known, just set the generator to that frequency and blast away for a while.

True. They say "SHOULD NOT" vs. "shall not", but since these are "guidelines" and not "requirements" I think they used the strongest language possible. (Note the capitalization in their FAQ. It's all caps!) Later in the same section, they use "SHALL" for requiring a password change after a known compromise.

Perhaps I should have been more clear. It is nonsense to require frequent password changes. NIST explains why in the above citation. It sucks that many USG organizations not only still enforce this, but require their contractors to do so as well.

Perhaps this was the inspiration for Boundary Scan (IEEE-1149.1) also known as JTAG.

The requirement to frequently change a perfectly good password is nonsense.

https://pages.nist.gov/800-63-FAQ/#q-b05

It says: SP 800-63B Section 5.1.1.2 paragraph 9 states: “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.

What about the practice of letting our five eyes partners collect on Americans, and then obtaining the laundered intel products?

"If everything private is fair game, then I expect we should be able to depose all parties involved for any disparaging statements they have ever made. Then we can proceed with either cancelling the large majority of everyone, and prosecuting the rest for perjury."

Worked for O.J. when his attorneys questioned Mark Fuhrman. Probably had a substantial impact on the jury verdict.

https://www.vanityfair.com/hollywood/2016/03/people-v-oj-sim...

I would not categorize the movie as a documentary. There's no narration. The audio is all from the Apollo communications system, except for the music by Brian Eno.

Bought one of these about two years ago. Did some of the assembly, but it's still not done.

Looking forward to playing "Super Star Trek" on it.

The movie was better. https://en.wikipedia.org/wiki/For_All_Mankind_(film)

As a white American in Beijing during the 9/11 attacks, I experienced lots of not-so-surprising behavior from my Chinese hosts. Many Chinese felt that America deserved what they got. Tensions were still high from the "Hainan Island Incident" only a few months earlier. https://en.wikipedia.org/wiki/Hainan_Island_incident

To point number 1: Depending on what sort of work the subject is doing with the clearance, he/she may never get a poly, or he/she may get one every time the clearance is updated (usually 5 years). If the subject happens to be living with a foreign national, and somebody writes a "letter of compelling need" for the subject (meaning the subject will retain the clearance in spite of the risk), then the subject will get a poly every year.

The poly is not limited to one session. The examiner will keep asking the subject to come back until they are satisfied with the results, or until the subject quits their job. Depending on the personality type of the subject, it can be extremely stressful, or just routine. Many engineers are "Type A" and that is the type most susceptible to stress.

During my last polygraph (I've had a lot over the years), I was accused by the FBI examiner of being a terrorist. Although we are not supposed to discuss these things, my boss told me later that they had done the same thing to him. The accusations rose to the level of abuse and the examiner was yelling at me and threatening my livelihood and future for several hours. Apparently, once he was satisfied that I had done nothing wrong, we were done. He offered his handshake to me as I left the room. I shook his hand, but I felt soiled afterward.

One thing that many Linux/Unix users do not know is that all commonly used filesystems have a "reserved" amount of space to which only "root" can write. The typical format (mkfs) default is to leave 5% of the disk reserved. The reserved space can be modified (by root) any time, and it can be specified as a block count or a percentage.

As long as your application does not have root privileges, it will hit the wall when the free+reserved space runs out. Instead of the clumsy "spacer.img" solution, one could simply (temporarily) reduce the reserved space to quickly recover from a disk full condition.

I was hoping that he might realize that more people would embrace his ideas if he shared them freely. I understand and appreciate the need to earn a living, but he's apparently been doing that anyway by writing games.

I read it again last year and picked up on a few things that had slipped past my understanding the first time around. I had originally assumed that the present day Enoch Root was the child of Bobby's Nordic girlfriend, but it was obviously not the case upon my second reading. A few web searches revealed the supernatural nature of Root.

I always wondered if Stephenson chose the name "Enoch Root" on a dare, or maybe he has some other story. It's probably something related to an "Enterprise NOC Root" computer account.

I can see the malware/ransomware business really wanting this. It would make it impossible to circumvent or decrypt their warez.