He talks a bit about the difficulties of JavaScript’s object model. If you implement that model according to the JavaScript spec in a simple manner in Golang, the performance will be terrible. There are a lot of JS performance tricks that depend on being able to JIT.
What might be amusing is an extra-fancy-types frontend for Golang, that adds TypeScript features to Golang that the TypeScript developers want to use when writing tsgo.
To be clear, the linux kernel and liburcu don’t use the C11 memory model. They have their own atomics and barriers implemented in assembler that predate C11. liburcu is largely a port of the linux kernel primitives to userland.
Not just according to Rust: POSIX says “The setenv() function need not be thread-safe.” edited to add: There are also several scary caveats in POSIX about environ
POSIX doesn’t say it’s always unsafe because Solaris / Illumos have a thread-safe setenv() — at the cost of leaking memory because old versions of the environment cannot be freed safely. But on every other OS setenv() is unusable in multithreaded code.
C has getenv() but not setenv() so it has nothing to say on this matter.
Rust could maybe have a safe setenv() but it would have to manipulate its own environment, not the libc environ, so getenv() (or direct access to environ) in non-Rust libraries linked into the same program would not be accessing the same environment.
This isn’t a limitation of static types, it’s a limitation of the anaemic C FFI that can’t model any worthwhile static properties of an API.
Oh wow that explains an ancient oddity. When I was learning this stuff in the mid 1990s, the introductory summaries were roughly,
Actors are a model of concurrent objects;
Scheme was an implementation of Actors.
I went and read the Lambda The Ultimate papers to learn about continuation passing style and there’s no sign of concurrent objects. Weird!
I never went digging to find out where or how the divergence happened (though I was interested in how they reconverged in Concurrent ML). Still, this is the first time I remember hearing that there are two different Actor models. Perhaps that’s unsurprising if Hewitt wasn’t clear about the differences.
I think the focus on error reporting makes this article more confusing than it should be for an article that aims to dispel confusion. My mental model is the dual of his so I was discombobulated by his initial summary:
An analysis is sound if it reports all errors, and complete if it only reports errors.
I think it would be more clear to say, “An analysis is sound if it only accepts inputs for which a property is definitely valid; it rejects all erroneous inputs. An analysis is complete if it accepts all valid inputs; it only rejects an input that is definitely erroneous.”
which cannot be right since it implies that all sound methods are complete
It makes sense if the diagram is not a venn diagram of the methods, but instead it’s a venn diagram of inputs labelled by which methods treat them as valid.
Interesting that E is cited under “capabilities”, but not under “loosen up the functions”. E’s eventual-send RPC model is interesting in a number of ways. If the receiver is local then it works a bit like a JavaScript callback in that there’s an event loop driving execution; if it’s remote then E has a clever “promise pipelining” mechanism that can hide latency. However E didn’t do anything memorable (to me at least!) about handling failure, which was the main point of that heading.
For “capabilities” and “A Language To Encourage Modular Monoliths”, I like the idea of a capability-secure module system. Something like ML’s signatures and functors, but modules can’t import, they only get access to the arguments passed into a functor. Everything is dependency injection. The build system determines which modules are compiled with which dependencies (which functors are passed which arguments).
An existing “semi-dynamic language” is CLOS, the Common Lisp object system. Its metaobject protocol is designed so that there are clear points when defining or altering parts of the object system (classes, methods, etc.) at which the result is compiled, so you know when you pay for being dynamic. It’s an interesting pre-Self design that doesn’t rely on JITs.
WRT “value database”, a friend of mine used to work for a company that had a Lisp-ish image-based geospatial language. They were trying to modernise its foundations by porting to the JVM. He had horror stories about their language’s golden image having primitives whose implementation didn’t correspond to the source, because of decades of mutate-in-place development.
The most common example of the “value database” or image-based style of development is in fact your bog standard SQL database: DDL and stored procedures are very much mutate-in-place development. We avoid the downsides by carefully managing migrations, and most people prefer not to put lots of cleverness into the database. The impedance mismatch between database development by mutate-in-place and non-database development by rebuild and restart is a horribly longstanding problem.
As for “a truly relational language”, at least part of what they want is R style data frames.
It amuses me that son-of-son-of-RRP might be called RPP :-) There’s some interesting history behind EPP, which is what RPP might replace…
Back in the mists of time (the 1980s), things like domain names and IP addresses were requested and assigned by exchanging email with IANA, ie, Jon Postel, Jake Feinler, and their team. They had a collection of forms you had to fill in, and anyone could use whois to retrieve a copy of the form for a domain name or IP address block.
As part of commercializing the Internet in the early 1990s, management of the DNS was mostly outsourced to Network Solutions (apart from the ccTLDs). They kept the very manual email-based process and charged a lot of money for it. By the end of the 1990s there was a great deal of dissatisfaction, and through a lot of concerted lobbying and some direct action, the Network Solutions monopoly was broken up:
the .org TLD was taken over by the non-profit Public Interest Registry, which uses the profits to fund ISOC and the IETF
a plan was made to create new gTLDs to provide more alternatives to .com
(relevant to this article) the task of DNS registration was split in two: registries would run the registration databases and DNS servers, and would be forbidden from dealing directly with registrants; registrars would do customer service for registrants, and there would be many registrars to choose from
ICANN was established to take over IANA (after Jon Postel’s death), set up the new TLDs, and regulate the registries and registrars.
(The company currently called Network Solutions is the registrar part of the 1990s Network Solutions; the registry part is now called Verisign.)
A new automatic domain name registration API was created called RRP, the registry-registrar protocol. (Sadly they didn’t design a registrant-registrar protocol, so end-user creation and management of domain names is a mess of manual user interfaces and proprietary APIs.) RRP was a classic ARPANET-style protocol, like SMTP: four-letter commands, three digit response codes, dot-terminated messages that were basically the same format as whois records.
RRP was replaced within a few years. EPP, the extensible provisioning protocol, does the same job as RRP did, but with XML. EPP is a little like Jabber/XMPP in that it uses a long-lived stateful TCP connection, though the XML messages are framed differently.
Personally I don’t think EPP is a great improvement over RRP. XML’s extensibility doesn’t help much with this kind of thing: there’s still a lot of protocol design work required to make the application extensible, for example (like message framing) XMPP and EPP do feature negotiation differently. Also I am not a fan of using such a non-specific name for a protocol with a very specific purpose. And it’s hilarious to me that EPP uses 4 digit response codes, not 3 digit codes, and not an XML-structured code.
Stéphane lists a number of reasons that EPP is disliked. I would add that EPP makes it harder than it should be to build a registrar: you have to have some kind of back-end service that maintains your persistent stateful EPP connections, to deal with the impedance mismatch between EPP and your customer-facing web front-end and HTTP API.
The article mentions EPP-over-HTTPS in footnote 4. I think the description is not quite right (EoH does not depend on a long HTTP connection) but it’s true that EoH is a strange beast:
First make a GET request, which corresponds to an EPP connection’s initial greeting exchange. The HTTP response sets a cookie which is used to associate subsequent HTTP requests to the same EPP session.
Then POST an EPP login command, after which you can do actual useful things with your cookie. This is a freakishly non-HTTPish way to do authentication!
You aren’t allowed to make concurrent requests with the same cookie, which means EoH does not help a registrar to get rid of their stateful EPP client service.
It could be worse, though: EPP has machinery for asynchronous actions and notifications from registries to registrars, but fortunately these are implemented by the client (registrar) sending a poll command to the server to retrieve pending notifications. So apart from the login faff, the protocol is basically request/response RPC. It’s just a shame that (arguably for silly reasons) it maps poorly to HTTP.
Another thing that has been happening in recent years is the rollout of RDAP (registration data access protocol) as a JSON-over-HTTPS replacement for the venerable and unloved whois.
It makes sense to me that a successor to EPP should:
use a common and familiar style of HTTP authentication
use a common and familiar style of HTTP concurrency control and backpressure
re-use the RDAP data model and syntax
Most of this is not directly relevant to domain registrants. But in my experience the details of EPP tend to leak through to the user interfaces and APIs provided by registrars — which is why I needed to learn this stuff for practical reasons, not just general interest. So I kind of hope that an improved back-end protocol will lead to better user-facing protocols. We shall see, I guess!
Are there any other than Scala? enum was new in Scala 3, several years after Rust reached 1.0. Earlier versions of Scala used case classes to model algebraic data types. I think Scala copied Rust rather than the other way round.
Languages in the ML and Haskell families don’t use enum in this way.
I’m finding it hard to find any precedent for Rust’s enum.
If it’s a corporate network with an oldskool security model, hard and crunchy on the outside / soft and chewy on the inside, then internal services are likely to be poorly configured in a way that makes interception attacks easier - leaking authentication cookies, things like that.
WRT “propagation” there are a few TLDs that have infrequent zone updates, but happily they are getting rarer. The reverse DNS is often slow, because there’s an incredibly shonky mechanism for RIRs to copy zone fragments between each other. (eg, 131.111.0.0/16 is registered via RIPE but the reverse DNS parent zone 131.in-addr.arpa is managed by ARIN.)
For split-horizon DNS you can have a domain like private.cam.ac.uk that is both a real subdomain and not published on the public Internet. (You don’t want to publish names with RFC 1918 IP addresses because that can expose your users to interception attacks.) That worked OK with IPv4 and NAT but it was more awkward with IPv6 in the mix, but I think that kind of real-but-private subdomain is a good model for cluster-internal DNS.
Yeah. One of the mildly vexing things is how HTTP altered MIME, eg wrt Content-Transfer-Encoding vs Content-Encoding and Transfer-Encoding, possibly for good reasons, but it meant that right from the start it wasn’t possible to have a shared data model between HTTP / SMTP / NNTP even tho they are >< that close.
In general I think it’s best to record multiple secondary locations alongside the local time at some primary location. This allows the planning software to automatically calculate and display the local time for all the participants, so that the organisers can see if the time they chose makes sense or not. It also allows the software to automatically detect and highlight which events are affected by TZ changes, both annual DST shenanigans (consider europe vs north america vs australia) and things like the 2007 north american DST schedule change and the possible future abolition of DST.
In many cases you’re going to tell it a location anyway (eg a meeting room for an in-person event) so this nuance shouldn’t complicate the user interface. Or, you add a remote participant and they have specified their timezone (for their own convenience) so it can be discovered from the information in the event.
It also needs more subtle locations such as wherever I am right now. Maybe if it knows about my travel plans and my medication it can highlight which drugs need special attention?
The crucial things are the indirection from the details of the event (its location(s), its participants location(s)) to the relevant timezones, and the assumption that the mapping from locations to timezones (and participants to locations) is mutable.
The major problem with this idea is that the iCalendar data model doesn’t support it, and all planning apps use iCalendar for sharing schedules.
A no-op realloc() also updates the compiler’s model of the size of the allocation, which might not match the allocator’s idea of the size of the allocation. malloc_usable_size() gets the allocator’s idea of the size, but that might not actually be usable (despite the name) because the compiler might think it knows better. You have to do something like,
Though it’s probably less horrible to avoid realloc() entirely and use something more like jemalloc’s nallocx() to round up within the size class before allocating, or maybe xallocx() for non-copying resizes.
Holy shit how did NIST (NIST!) manage to publish something so blatantly incorrect when they really ought to know better?!
UTC dates back to 1962. There have been two different definitions of UTC:
1962-1971 was the “rubber seconds” era
UTC was defined by a combination of a frequency correction, so that UTC seconds varied in length to roughly match the rate of UT2 (hence “rubber”) plus occasional phase adjustments on the order of 100ms to cope with mismatches between the UTC frequency and the earth’s wobble.
One thing to keep in mind is how time was distributed in the 1960s: big fuck-off radio transmitters. The time signal was not just modulated onto a carrier wave: the carrier wave itself was a broadcast reference frequency. So when UTC had a rate adjustment, that meant engineers had to go out and retune and recalibrate several very serious high-power broadcast antennas. This was a colossal pain in the arse, which is one of the reasons UTC changed to fixed-length seconds in 1972.
1972 onwards, UTC just uses coarse phase adjustments (known as leap seconds) and the somewhat finer 100ms correction is promulgated out of band as IERS Bulletin D.
The conference was convened by the United States, and Greenwich won mainly because the British Admiralty had the best and most widely-used maritime charts, and they were all based on Greenwich. And the USA wanted Greenwich to win because it was already the basis for the north american railway time zones.
UT is usually used with a suffix,
UT0 = apparent solar time
UT1 = simple mean solar time, UT0 plus the equation of time
UT2 = a more uniform version of mean solar time, what GMT was when the Greenwich Observatory was maintaining a mean solar time scale
UTC = universal time, but atomic, the “C” referring to the co-ordination between the british (first atomic clock and timescale), americans (helped calibrate the first atomic clock to define the atomic SI second; second atomic timescale), and french (bureau international de l’heure; third atomic timescale)
The C is a suffix, following the old established scheme. It was not an ITU compromise, nor a linguistic compromise — and in 1970 the radio broadcast part of the ITU was still called the CCIR – the Comité Consultatif International pour la Radio.
how does a client handle windowing for concurrent requests? that has often been a serious performance problem for similar protocols such as sftp, especially for high latency links
the random access read model requires the server to buffer the whole of a dynamically generated file, it can’t stream to the client like HTTP
A lot of these overviews do not make a clear distinction between operational time scales and paper time scales — I know I found this area confusing when I was learning about time scales! And there’s a further distinction to make between different kinds of paper time scale, atomic or astronomical.
The operational time scales are based fairly directly on observations. These include:
UTC from time labs, e.g. UTC(NPL), UTC(NIST)
the GNSS time scales, GPST, GST
earth orientation time: apparent solar time, sidereal time
Operational time scales are not perfect. That’s kind of obvious for our wobbly planet, but it’s true for atomic time scales too. For example, GNSS signals have parameters that describe how to translate system time to UTC, with both rate and phase adjustments; the fixed integer delta between GPST and TAI is a simplification that’s only true as a low precision approximation.
Atomic paper time scales correlate a load of time measurements and publish retrospective corrections some time after the fact. These include:
global consensus UTC, UTC(BIPM)
TAI, intended to be more stable than UTC(BIPM) and published less frequently
the various TT(year) timescales which are able to fix anomalies in TAI
Astronomical time scales are related to each other via an astronomical ephemeris. These include:
UT1
TCB, TDB, TCG
These time scales are coordinates in systems of equations that describe the motions of the earth, moon, planets, etc. I put UT1 here because mean solar time is related to observations of earth orientation via the equation of time.
I have some corrections to suggest:
The UT1 time scale measures time relative to the stars, reflecting the Earth’s actual rotation.
This should be more careful about the difference between solar time and sidereal time! It’s true that we measure earth rotation by observing the stars (because the sun is too big and hot) but those observations are adjusted to be relative to the sun to produce UT1.
Despite these complexities, UTC simplifies matters by assuming a constant 24-hour day, equivalent to 86,400 seconds.
This sentence is OK in context, but the horrible thing about UTC is it’s the only time scale that doesn’t have a constant 24-hour day! I think it would be better phrased something like “UTC avoids difficulties due to earth’s variable rate of rotation by basing its day on 24 hours of fixed-rate SI seconds, usually 86400 seconds per day.”
Temps Atomique International (TAI) is a time scale based on the average of atomic clocks worldwide, providing a precise standard for the duration of a second. UTC is an offset from TAI designed to keep it within one second of UT1.
OK I’m going to be super pedantic now. Your description is a fine way to model the relationship between the time scales, but it sounds like an operational description — and in reality it works the other way round! The time labs produce their versions of UTC, which are averaged to produce UTC(BIPM). When a leap second is introduced into UTC that changes the offset used to produce TAI from the UTC measurements. This sounds weird and backwards if you don’t have a clear notion of operational vs. paper time scales.
It’s really unfortunate that the C FAQ includes such a misleading section. I put the silly face on the end of my comment because I thought it was well known that the spiral rule is wrong. It’s like saying there’s a spiral rule for parsing C expressions — or Rust expressions, for that matter! It teaches readers a bad intuition, and guides them away from the right way to think about it: which is to understand the precedence rules for expressions, and apply that knowledge to the precedence rules for declarators.
The spiral rule isn’t even a good lie-to-children, because it isn’t an approximation that is still useful once you know the full truth. If someone has learned it then there’s a lot of mental damage that needs to be undone before they can learn the right model.
Yeah, switches can be remarkably smart. Ethernet has a whole stack of protocols: it isn’t two layers, the OSI model is lying to you.
Another way to get location data from Ethernet is configuring your switches to participate as middleboxes in DHCP, by adding physical port information to DHCP requests. I’ve used this to augment the logging on the DHCP server so that when there is trouble the problem device can be physically located. But you could also use it to allocate IP addresses based on the switch port the device is plugged into. There are a bunch of problems with this idea if access to your network is relaxed: your users will plug multiple devices into one port or configure VMs without NAT, etc.
Hejlsberg addresses the question of a native TypeScript runtime towards the end of this interview https://youtu.be/10qowKUW82U?t=3280s
He talks a bit about the difficulties of JavaScript’s object model. If you implement that model according to the JavaScript spec in a simple manner in Golang, the performance will be terrible. There are a lot of JS performance tricks that depend on being able to JIT.
What might be amusing is an extra-fancy-types frontend for Golang, that adds TypeScript features to Golang that the TypeScript developers want to use when writing tsgo.
To be clear, the linux kernel and liburcu don’t use the C11 memory model. They have their own atomics and barriers implemented in assembler that predate C11. liburcu is largely a port of the linux kernel primitives to userland.
I have an old comment regarding mixing and matching layers (or rather, not being able to) … maybe I’ll just link to all my old OSI model rants :-)
https://lobste.rs/search?q=commenter%3Afanf+osi+model
Which model of Raspberry Pi? They vary in performance by maybe 100x https://magpi.raspberrypi.com/articles/raspberry-pi-specs-benchmarks (that article predates the 5)
Not just according to Rust: POSIX says “The setenv() function need not be thread-safe.” edited to add: There are also several scary caveats in POSIX about
environPOSIX doesn’t say it’s always unsafe because Solaris / Illumos have a thread-safe setenv() — at the cost of leaking memory because old versions of the environment cannot be freed safely. But on every other OS setenv() is unusable in multithreaded code.
C has getenv() but not setenv() so it has nothing to say on this matter.
Rust could maybe have a safe setenv() but it would have to manipulate its own environment, not the libc
environ, so getenv() (or direct access toenviron) in non-Rust libraries linked into the same program would not be accessing the same environment.This isn’t a limitation of static types, it’s a limitation of the anaemic C FFI that can’t model any worthwhile static properties of an API.
Oh wow that explains an ancient oddity. When I was learning this stuff in the mid 1990s, the introductory summaries were roughly,
I went and read the Lambda The Ultimate papers to learn about continuation passing style and there’s no sign of concurrent objects. Weird!
I never went digging to find out where or how the divergence happened (though I was interested in how they reconverged in Concurrent ML). Still, this is the first time I remember hearing that there are two different Actor models. Perhaps that’s unsurprising if Hewitt wasn’t clear about the differences.
I think the focus on error reporting makes this article more confusing than it should be for an article that aims to dispel confusion. My mental model is the dual of his so I was discombobulated by his initial summary:
I think it would be more clear to say, “An analysis is sound if it only accepts inputs for which a property is definitely valid; it rejects all erroneous inputs. An analysis is complete if it accepts all valid inputs; it only rejects an input that is definitely erroneous.”
Wrt the first diagram:
He says:
It makes sense if the diagram is not a venn diagram of the methods, but instead it’s a venn diagram of inputs labelled by which methods treat them as valid.
Interesting that E is cited under “capabilities”, but not under “loosen up the functions”. E’s eventual-send RPC model is interesting in a number of ways. If the receiver is local then it works a bit like a JavaScript callback in that there’s an event loop driving execution; if it’s remote then E has a clever “promise pipelining” mechanism that can hide latency. However E didn’t do anything memorable (to me at least!) about handling failure, which was the main point of that heading.
For “capabilities” and “A Language To Encourage Modular Monoliths”, I like the idea of a capability-secure module system. Something like ML’s signatures and functors, but modules can’t import, they only get access to the arguments passed into a functor. Everything is dependency injection. The build system determines which modules are compiled with which dependencies (which functors are passed which arguments).
An existing “semi-dynamic language” is CLOS, the Common Lisp object system. Its metaobject protocol is designed so that there are clear points when defining or altering parts of the object system (classes, methods, etc.) at which the result is compiled, so you know when you pay for being dynamic. It’s an interesting pre-Self design that doesn’t rely on JITs.
WRT “value database”, a friend of mine used to work for a company that had a Lisp-ish image-based geospatial language. They were trying to modernise its foundations by porting to the JVM. He had horror stories about their language’s golden image having primitives whose implementation didn’t correspond to the source, because of decades of mutate-in-place development.
The most common example of the “value database” or image-based style of development is in fact your bog standard SQL database: DDL and stored procedures are very much mutate-in-place development. We avoid the downsides by carefully managing migrations, and most people prefer not to put lots of cleverness into the database. The impedance mismatch between database development by mutate-in-place and non-database development by rebuild and restart is a horribly longstanding problem.
As for “a truly relational language”, at least part of what they want is R style data frames.
It amuses me that son-of-son-of-RRP might be called RPP :-) There’s some interesting history behind EPP, which is what RPP might replace…
Back in the mists of time (the 1980s), things like domain names and IP addresses were requested and assigned by exchanging email with IANA, ie, Jon Postel, Jake Feinler, and their team. They had a collection of forms you had to fill in, and anyone could use whois to retrieve a copy of the form for a domain name or IP address block.
As part of commercializing the Internet in the early 1990s, management of the DNS was mostly outsourced to Network Solutions (apart from the ccTLDs). They kept the very manual email-based process and charged a lot of money for it. By the end of the 1990s there was a great deal of dissatisfaction, and through a lot of concerted lobbying and some direct action, the Network Solutions monopoly was broken up:
the .org TLD was taken over by the non-profit Public Interest Registry, which uses the profits to fund ISOC and the IETF
a plan was made to create new gTLDs to provide more alternatives to .com
(relevant to this article) the task of DNS registration was split in two: registries would run the registration databases and DNS servers, and would be forbidden from dealing directly with registrants; registrars would do customer service for registrants, and there would be many registrars to choose from
ICANN was established to take over IANA (after Jon Postel’s death), set up the new TLDs, and regulate the registries and registrars.
(The company currently called Network Solutions is the registrar part of the 1990s Network Solutions; the registry part is now called Verisign.)
A new automatic domain name registration API was created called RRP, the registry-registrar protocol. (Sadly they didn’t design a registrant-registrar protocol, so end-user creation and management of domain names is a mess of manual user interfaces and proprietary APIs.) RRP was a classic ARPANET-style protocol, like SMTP: four-letter commands, three digit response codes, dot-terminated messages that were basically the same format as whois records.
RRP was replaced within a few years. EPP, the extensible provisioning protocol, does the same job as RRP did, but with XML. EPP is a little like Jabber/XMPP in that it uses a long-lived stateful TCP connection, though the XML messages are framed differently.
Personally I don’t think EPP is a great improvement over RRP. XML’s extensibility doesn’t help much with this kind of thing: there’s still a lot of protocol design work required to make the application extensible, for example (like message framing) XMPP and EPP do feature negotiation differently. Also I am not a fan of using such a non-specific name for a protocol with a very specific purpose. And it’s hilarious to me that EPP uses 4 digit response codes, not 3 digit codes, and not an XML-structured code.
Stéphane lists a number of reasons that EPP is disliked. I would add that EPP makes it harder than it should be to build a registrar: you have to have some kind of back-end service that maintains your persistent stateful EPP connections, to deal with the impedance mismatch between EPP and your customer-facing web front-end and HTTP API.
The article mentions EPP-over-HTTPS in footnote 4. I think the description is not quite right (EoH does not depend on a long HTTP connection) but it’s true that EoH is a strange beast:
First make a GET request, which corresponds to an EPP connection’s initial greeting exchange. The HTTP response sets a cookie which is used to associate subsequent HTTP requests to the same EPP session.
Then POST an EPP login command, after which you can do actual useful things with your cookie. This is a freakishly non-HTTPish way to do authentication!
You aren’t allowed to make concurrent requests with the same cookie, which means EoH does not help a registrar to get rid of their stateful EPP client service.
It could be worse, though: EPP has machinery for asynchronous actions and notifications from registries to registrars, but fortunately these are implemented by the client (registrar) sending a poll command to the server to retrieve pending notifications. So apart from the login faff, the protocol is basically request/response RPC. It’s just a shame that (arguably for silly reasons) it maps poorly to HTTP.
Another thing that has been happening in recent years is the rollout of RDAP (registration data access protocol) as a JSON-over-HTTPS replacement for the venerable and unloved whois.
It makes sense to me that a successor to EPP should:
use a common and familiar style of HTTP authentication
use a common and familiar style of HTTP concurrency control and backpressure
re-use the RDAP data model and syntax
Most of this is not directly relevant to domain registrants. But in my experience the details of EPP tend to leak through to the user interfaces and APIs provided by registrars — which is why I needed to learn this stuff for practical reasons, not just general interest. So I kind of hope that an improved back-end protocol will lead to better user-facing protocols. We shall see, I guess!
Are there any other than Scala?
enumwas new in Scala 3, several years after Rust reached 1.0. Earlier versions of Scala used case classes to model algebraic data types. I think Scala copied Rust rather than the other way round.Languages in the ML and Haskell families don’t use enum in this way.
I’m finding it hard to find any precedent for Rust’s enum.
If it’s a corporate network with an oldskool security model, hard and crunchy on the outside / soft and chewy on the inside, then internal services are likely to be poorly configured in a way that makes interception attacks easier - leaking authentication cookies, things like that.
WRT “propagation” there are a few TLDs that have infrequent zone updates, but happily they are getting rarer. The reverse DNS is often slow, because there’s an incredibly shonky mechanism for RIRs to copy zone fragments between each other. (eg, 131.111.0.0/16 is registered via RIPE but the reverse DNS parent zone 131.in-addr.arpa is managed by ARIN.)
For split-horizon DNS you can have a domain like private.cam.ac.uk that is both a real subdomain and not published on the public Internet. (You don’t want to publish names with RFC 1918 IP addresses because that can expose your users to interception attacks.) That worked OK with IPv4 and NAT but it was more awkward with IPv6 in the mix, but I think that kind of real-but-private subdomain is a good model for cluster-internal DNS.
Yeah. One of the mildly vexing things is how HTTP altered MIME, eg wrt Content-Transfer-Encoding vs Content-Encoding and Transfer-Encoding, possibly for good reasons, but it meant that right from the start it wasn’t possible to have a shared data model between HTTP / SMTP / NNTP even tho they are >< that close.
Re. minor corrections, one of my favourites is https://lists.w3.org/Archives/Public/ietf-http-wg/1999JulSep/0039.html
Yeah.
In general I think it’s best to record multiple secondary locations alongside the local time at some primary location. This allows the planning software to automatically calculate and display the local time for all the participants, so that the organisers can see if the time they chose makes sense or not. It also allows the software to automatically detect and highlight which events are affected by TZ changes, both annual DST shenanigans (consider europe vs north america vs australia) and things like the 2007 north american DST schedule change and the possible future abolition of DST.
In many cases you’re going to tell it a location anyway (eg a meeting room for an in-person event) so this nuance shouldn’t complicate the user interface. Or, you add a remote participant and they have specified their timezone (for their own convenience) so it can be discovered from the information in the event.
It also needs more subtle locations such as wherever I am right now. Maybe if it knows about my travel plans and my medication it can highlight which drugs need special attention?
The crucial things are the indirection from the details of the event (its location(s), its participants location(s)) to the relevant timezones, and the assumption that the mapping from locations to timezones (and participants to locations) is mutable.
The major problem with this idea is that the iCalendar data model doesn’t support it, and all planning apps use iCalendar for sharing schedules.
previously, on my blog 15 years ago
A no-op realloc() also updates the compiler’s model of the size of the allocation, which might not match the allocator’s idea of the size of the allocation. malloc_usable_size() gets the allocator’s idea of the size, but that might not actually be usable (despite the name) because the compiler might think it knows better. You have to do something like,
Though it’s probably less horrible to avoid realloc() entirely and use something more like jemalloc’s nallocx() to round up within the size class before allocating, or maybe xallocx() for non-copying resizes.
Holy shit how did NIST (NIST!) manage to publish something so blatantly incorrect when they really ought to know better?!
UTC dates back to 1962. There have been two different definitions of UTC:
1962-1971 was the “rubber seconds” era
UTC was defined by a combination of a frequency correction, so that UTC seconds varied in length to roughly match the rate of UT2 (hence “rubber”) plus occasional phase adjustments on the order of 100ms to cope with mismatches between the UTC frequency and the earth’s wobble.
One thing to keep in mind is how time was distributed in the 1960s: big fuck-off radio transmitters. The time signal was not just modulated onto a carrier wave: the carrier wave itself was a broadcast reference frequency. So when UTC had a rate adjustment, that meant engineers had to go out and retune and recalibrate several very serious high-power broadcast antennas. This was a colossal pain in the arse, which is one of the reasons UTC changed to fixed-length seconds in 1972.
1972 onwards, UTC just uses coarse phase adjustments (known as leap seconds) and the somewhat finer 100ms correction is promulgated out of band as IERS Bulletin D.
I can’t find a good reference to rubber-second UTC right now, but some time ago I wrote about falsely extending leapseconds back to the 1950s to make a simpler model of the 1958-1972 transition from UT2 to modern UTC. (I no longer think this is a good idea.)
UTC is a two-part abbreviation
UT is short for universal time
Unlike a lot of abbreviations in this area it is not french. It dates back to the international meridian conference in 1884 which
The conference was convened by the United States, and Greenwich won mainly because the British Admiralty had the best and most widely-used maritime charts, and they were all based on Greenwich. And the USA wanted Greenwich to win because it was already the basis for the north american railway time zones.
UT is usually used with a suffix,
UT0 = apparent solar time
UT1 = simple mean solar time, UT0 plus the equation of time
UT2 = a more uniform version of mean solar time, what GMT was when the Greenwich Observatory was maintaining a mean solar time scale
UTC = universal time, but atomic, the “C” referring to the co-ordination between the british (first atomic clock and timescale), americans (helped calibrate the first atomic clock to define the atomic SI second; second atomic timescale), and french (bureau international de l’heure; third atomic timescale)
The C is a suffix, following the old established scheme. It was not an ITU compromise, nor a linguistic compromise — and in 1970 the radio broadcast part of the ITU was still called the CCIR – the Comité Consultatif International pour la Radio.
Some things that immediately occur to me:
no support for MIME types
no support for QUERY or POST
no redirects
the open/read pattern is poor for startup latency
how does a client handle windowing for concurrent requests? that has often been a serious performance problem for similar protocols such as sftp, especially for high latency links
the random access read model requires the server to buffer the whole of a dynamically generated file, it can’t stream to the client like HTTP
This isn’t bad but I have some suggestions.
A lot of these overviews do not make a clear distinction between operational time scales and paper time scales — I know I found this area confusing when I was learning about time scales! And there’s a further distinction to make between different kinds of paper time scale, atomic or astronomical.
The operational time scales are based fairly directly on observations. These include:
Operational time scales are not perfect. That’s kind of obvious for our wobbly planet, but it’s true for atomic time scales too. For example, GNSS signals have parameters that describe how to translate system time to UTC, with both rate and phase adjustments; the fixed integer delta between GPST and TAI is a simplification that’s only true as a low precision approximation.
Atomic paper time scales correlate a load of time measurements and publish retrospective corrections some time after the fact. These include:
Astronomical time scales are related to each other via an astronomical ephemeris. These include:
These time scales are coordinates in systems of equations that describe the motions of the earth, moon, planets, etc. I put UT1 here because mean solar time is related to observations of earth orientation via the equation of time.
I have some corrections to suggest:
This should be more careful about the difference between solar time and sidereal time! It’s true that we measure earth rotation by observing the stars (because the sun is too big and hot) but those observations are adjusted to be relative to the sun to produce UT1.
This sentence is OK in context, but the horrible thing about UTC is it’s the only time scale that doesn’t have a constant 24-hour day! I think it would be better phrased something like “UTC avoids difficulties due to earth’s variable rate of rotation by basing its day on 24 hours of fixed-rate SI seconds, usually 86400 seconds per day.”
OK I’m going to be super pedantic now. Your description is a fine way to model the relationship between the time scales, but it sounds like an operational description — and in reality it works the other way round! The time labs produce their versions of UTC, which are averaged to produce UTC(BIPM). When a leap second is introduced into UTC that changes the offset used to produce TAI from the UTC measurements. This sounds weird and backwards if you don’t have a clear notion of operational vs. paper time scales.
It’s really unfortunate that the C FAQ includes such a misleading section. I put the silly face on the end of my comment because I thought it was well known that the spiral rule is wrong. It’s like saying there’s a spiral rule for parsing C expressions — or Rust expressions, for that matter! It teaches readers a bad intuition, and guides them away from the right way to think about it: which is to understand the precedence rules for expressions, and apply that knowledge to the precedence rules for declarators.
The spiral rule isn’t even a good lie-to-children, because it isn’t an approximation that is still useful once you know the full truth. If someone has learned it then there’s a lot of mental damage that needs to be undone before they can learn the right model.
The top comment on this thread on the orange site nicely illustrates ~lonjil’s great example of why it is nonsense.
Yeah, switches can be remarkably smart. Ethernet has a whole stack of protocols: it isn’t two layers, the OSI model is lying to you.
Another way to get location data from Ethernet is configuring your switches to participate as middleboxes in DHCP, by adding physical port information to DHCP requests. I’ve used this to augment the logging on the DHCP server so that when there is trouble the problem device can be physically located. But you could also use it to allocate IP addresses based on the switch port the device is plugged into. There are a bunch of problems with this idea if access to your network is relaxed: your users will plug multiple devices into one port or configure VMs without NAT, etc.