Science? Maybe in an ideal world. However, how science actually gets done has always been at the mercy of social, cultural, institutional, and/or economic pressures.
Congress neutered itself, largely because it has been politically less risky to let the Executive branch do whatever they want, then either cheer it on or rage against it depending on party and what drives donations so congress members can get reelected.
I agree that it's fundamentally broken but I've been around to see it work and watch it fail.
The executive branch obviously is going to wield as much power as it can, but only one party is actually advocating for the executive as king.
So yes, both parties are the same when it comes to the corruption of the party leadership, but there are distinctly different platforms and ideals espoused -- and that difference matters.
"The length limit of a DNS TXT record is 255 characters."
Nope. That's the maximum length of a TXT record string. TXT record strings with the same owner name get concatenated together. The maximum for a TXT record is 65,280 octets (which may or may not translate into characters depending on encoding).
Also, you probably want to think about the implications of caching and TTL.
When you say "get concatenated together" are you perhaps thinking of how multiple SPF records get concatenated by MTA's? Because in ISC dig they are multiple distinct records, which is fine too.
finger nochan.net
"bing bing bong."
"Catching up on HN"
No. It's been a while, but I believe if you use multiple TXTs, resolvers can reorder them as they see fit. For example,
label IN TXT "foo "
IN TXT "bar "
IN TXT "baz"
You can have any number of TXT RRs with a label, allowing up to 65,280 bytes. However, resolvers can reorder those 3 TXT RRs.
If you put the text strings in quotes in a single TXT RR, e.g.:
label IN TXT "foo "
"bar "
"baz"
You'll get "foo bar baz" and each of the strings can be up to 255 bytes. I think (but I'm too lazy to verify) that the maximum length of a concatenated string is implementation dependent.
for i in $(seq 100);do echo -en '0';done
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
test 69s in txt "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
nsd-checkzone nochan.net ./nochan.net.zone
zone nochan.net is ok
nsd-control reload nochan.net
ok
# from my laptop
dig -t txt +short test.nochan.net
"0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
Still shows up as three quoted strings 100 characters long each but not 300 0's meaning no concatenation at least not when using dig which is what this thread is about.
As someone on the tail end of that birth cohort (and to quote Monty Python), "I'm not dead yet!".
According to BLS (as pointed to by https://usafacts.org/answers/what-is-the-labor-force-partici...), the 55-and-older stat is 37.1%. I don't think 7 years would reduce that to between 5-10%. Also, it's worth noting that projections from BLS showed labor‑force participation for ages 75+ rising to about 10.8% by 2026, up from 4.7% in 1996.
My understanding is that this NDA is far broader in scope than CUI. CUI restrictions only apply to information explicitly marked or identified as CUI.
The draft NDA would apply to “confidential government information,” defined much more broadly than CUI to include non‑public internal operations, personnel matters, deliberative or pre‑decisional materials, and other information an agency deems sensitive, whether or not it falls under existing CUI categories -- it's an open-ended personnel instrument defined by the administration rather than an information handling regime tightly anchored to statutory/regulatory bases than span administrations.
In other words, it's a tool to allow the administration to go after someone who leaks anything the administration doesn't want leaked for open ended reasons.
[oops. That was intended as a response to Jtsummers]
If DJB is "hated", it isn't because he's a lone author (Linus Torvalds was once a lone author and I don't think he was hated). It's because he can be an asshole. To quote George Bernard Shaw, “The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
DJB is a lot of things, and I have great respect for him, even though I feel he didn’t responsibly maintain Qmail/DJBdns/Publicfile. He made MaraDNS more secure because I carefully read his documentation—I got the idea to have a random source port to give MaraDNS more security from him, which means MaraDNS was unscathed when DNS spoofing was independently discovered in 2007.
The point DJB made was this: It was possible for a skilled C programmer to make a server with few security holes. Even though that’s not as relevant now, with Rust having most of the speed of C and security built in, it did make the Internet a safer place for many years. I remember using Qmail and DJBdns to make the servers at the small company I worked for at the time more secure.
Oh joy. Now the volunteers maintaining the IETF RFC tools get to waste their time trying to prevent folks who think it's cute to litter all over the IETF drafts.
I suppose it was inevitable. Another reason why we can't have nice things...
reply