Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curious case of the missing period

tjaart.substack.com

Post reply on HN
Print view View original

131–140 of 201 posts

Re: The curious case of the missing period

#131

Post by kruador »

ryandrake wrote: post #62
rrr_oh_man wrote: post #52

Earlier quoted context omitted.

Can you share a story?

As the sibling comment already mentioned, file format reading is a big one. Oh, a customer needs us to ingest CSV data. Let's just roll our own CSV parser, the file format is simple, right? What could go wrong? Same for graphics formats. We need to read PNG files, so let's just figure out the format and implement just enough to read the handful of files we have on hand. Even though libpng exists. Another, more domain…

That reminds me of the Windows Mobile 6.5 device with built-in GPS receiver, where on the 31st day of the month, the API would actually output the date as the 0th day of the following month. This wouldn't have been a problem, except that we were using that to set the system clock. The devices would reset their clock if allowed to go completely flat, but they didn't have reliable NTP support either. I believe the OS would just ignore our attempt to set the date to an invalid value, leaving it at the system default date.

It was a struggle to get the vendor to even acknowledge the problem, since it would only happen on 7 days out of the year, and usually 60 days apart. (There are only two consecutive months with 31 days, July and August.) It did eventually get fixed.

I seem to recall writing a workaround, but then it being stalled by our customer's Change Control Board.

Re: The curious case of the missing period

#132

Post by Gigachad »

blueflow wrote: post #11
quotemstr wrote: post #7

Earlier quoted context omitted.

> Implementing protocols correctly is hard That's why it's a best practice to specify protocols at a very high level (e.g. using cap'n'proto) instead of expecting every random sleep-deprived SDE2 to correctly implement a network exchange in terms of read() and write().

That why you have to read the specs of the protocol you want to implement. Its a matter of engineering rigorousness. Brute-forcing until "it works" doesn't cut it.

You don’t need to understand SMTP to send email. You just use a library that implements it and lets you just pass in a html doc.

Re: The curious case of the missing period

#133

Post by jcpham2 »

As soon as I started reading one of the first things that came to mind was the termination period in the smtp server spec. If you’ve ever had to troubleshoot an SMTP transport issue typing SMTP con Ds by hand is a familiar thing. Cool read.

Re: The curious case of the missing period

#134

Post by throw10920 »

pja wrote: post #128
throw10920 wrote: post #103

Earlier quoted context omitted.

The real problem is that SMTP is a "plain-text" protocol that includes in-band signaling. It literally happened because SMTP defined "a line that only contains a single period in it" as a control sequence and not a literal line that only contains a single period in it. SMTP is an example of an unnecessarily complex design, and the implementation bugs reflect it. SMTP shouldn't be hard for someone to correctly impleme…

At some point, all protocols include in-band signalling somewhere: You have to put packets on the line, and those packets are ultimately just a stream of anonymous bytes. If it wasn’t a period, it would be something else & you’d have to handle that instead.

> all protocols include in-band signalling somewhere

That's an incredibly reductionistic view of the world that's utterly useless for anything (including actually engineering systems) except pedantry. It's obvious that the level at which you include control information is meaningful and significantly affects the design of the protocol, as we see in the submission. Directly embedding the control information into the message body does not lead to a design that is easy to implement.

> If it wasn’t a period, it would be something else & you’d have to handle that instead.

Yes, and there are many other design choices that'd be significantly easier to handle.

Re: The curious case of the missing period

#135

Post by meisenhus »

davedx wrote: post #127
throw10920 wrote: post #103

Earlier quoted context omitted.

The real problem is that SMTP is a "plain-text" protocol that includes in-band signaling. It literally happened because SMTP defined "a line that only contains a single period in it" as a control sequence and not a literal line that only contains a single period in it. SMTP is an example of an unnecessarily complex design, and the implementation bugs reflect it. SMTP shouldn't be hard for someone to correctly impleme…

Honestly this part with the periods, while unusual, isn’t really complex. The two rules regarding the periods were like a small paragraph of text. I agree with sibling comment from Temporal, this is purely a “skill issue”, not a protocol issue

[dead]

Re: The curious case of the missing period

#136

Post by meisenhus »

aftoprokrustes wrote: post #60

I will not comment on the technical part, as others already did it better than I could, but it just reminded me of an anecdote that reminds of the importance of such trivial things as a period at the end of a sentence: In Germany, where I work, it is usual at the end of employement to ask for a letter of recommendation ("Zeugnis") that lists the tasks performed, and how good the employee was. It is an important docum…

[dead]

Re: The curious case of the missing period

#137

Post by Maxion »

edanm wrote: post #121
userbinator wrote: post #109

I suspect a lot of people are no longer being taught these fundamental protocols by manual interaction with a terminal, since that's what SMTP seems to have been originally intended for; and as someone who actually made use of that for a nontrivial amount of time, the "single dot on a line" to end a message has been permanently etched into my memory. Relatedly, escaping somehow seems to be a foreign concept for a lot…

> I suspect a lot of people are no longer being taught these fundamental protocols by manual interaction with a terminal, I'd be surprised if any significant portion of software developers learned anything like that in the last 30 years, at least.

I mean, if we did that for everything in webdev, It'd take 30 years of training before you'd get to do your first PR!

Re: The curious case of the missing period

#138

Post by markisus »

Gigachad wrote: post #130
xg15 wrote: post #116

Earlier quoted context omitted.

Sounds like a great idea, until you find that your SMTP library pulls in 5 other libraries as its own dependencies and those each pull in 3 transitive dependencies of their own, one being some kitchen sink/toolbox project where only 1% of its code is actually relevant to the dependant and the rest is dead weight - but which pulls in 20 more dependencies for functions that are literally never called in your project -…

This doesn’t seem like a real issue. Servers can handle a several megabyte executable, and CVE warnings for libraries you aren’t using can be ignored.

In the hypothetical above, you won’t have any way to know which libraries are actually being used unless you read through the source code. Many libraries will transitively include protobuf, but most functions will not call protobuf.

Re: The curious case of the missing period

#140

Post by TeMPOraL »

throw10920 wrote: post #134
pja wrote: post #128

Earlier quoted context omitted.

At some point, all protocols include in-band signalling somewhere: You have to put packets on the line, and those packets are ultimately just a stream of anonymous bytes. If it wasn’t a period, it would be something else & you’d have to handle that instead.

> all protocols include in-band signalling somewhere That's an incredibly reductionistic view of the world that's utterly useless for anything (including actually engineering systems) except pedantry. It's obvious that the level at which you include control information is meaningful and significantly affects the design of the protocol, as we see in the submission. Directly embedding the control information into the m…

No, it's not reductionist and pedantic. It's a reminder that there is no magic. Building an abstraction layer that separates control and data doesn't win you anything if, like the people in the article, you then forget it's a thing and write directly to the level below it.
Post reply on HN