I think it's a littly funny he characterizes "Had the right flavor for every different context" as an advantage. It drives me crazy that Markdown is not the same everywhere and I'm still regularly getting confused about *bold* or **bold** or *italics*. (Curse you, Slack's weirdo version.)
I respect Anil's argument that the extensibility has helped it be adapted to different contexts, and in practice the looseness of it doesn't cause a problem. I do wish CommonMark had more traction (and acceptance and use of the name Markdown). It'd be nice to have a standard, at least for the basic stuff.
That's exactly what we used in on usenet (except,without rendering unless you were using a nice GUI reader, not just tin/rtin)
The problem is that that's too many characters to reserve (they all have to be escaped when you want the actual character) making the resulting text look awful in plain text mode.
They are not reserved characters. They only express a special format when used in that way : a space on its left, and a character stuck to its right AND somewhere down the road : its twin with a character stuck to its left and a space on its right. I built an editor doing just that more than two decades ago, and it works fine.
So *this* and /that/ express formatting, but not 4 * 5 nor 4*5 nor 4/5 nor m/s.
In the contexts where Markdown is most often used, the distinction between bold and italics isn't really important. So long as *this* or **this** gets rendered in a way that conveys emphasis, the meaning is preserved.
Single-asterisk for bold is not Markdown. I believe Slack calls their thing "markup". I also find it annoying. So annoying that I just learned Slack's keyboard shortcuts instead.
Slack messages are formatted in mrkdwn <https://docs.slack.dev/messaging/formatting-message-text/#ba...>. Completely unrelated to Markdown, superficial resemblance only. If there were trademarks in play you’d absolutely attack them for trademark infringement.
But what you type isn’t even mrkdwn, but rather an input mode that supports most of the same syntax.
It took me a long time to see the variations as a plus and not a minus; as a veteran of the RSS-vs-Atom wars, I was long an advocate of Technical Correctness(tm) like any good coder. But the years since then have made me a lot more amenable to what I think of as a sort of Practical Postelism, which I guess is like applied worse-is-better, where we realize the reality is that we'll _always_ have forks and multiplicities, so we should see it as a feature instead of a bug. It's like accepting that hardware will fail, and building it into the system.
I mean, HTML itself is well specified in the streets, and infinitely different flavors in the sheets. I don't _like_ that, the part of me that writes code _hates_ that. But the part of me that wants systems to succeed just had to sort of respect it.
Ah, Anil, but have you fought the plaintext syntax wars yet?
Jokes apart, regular, standardised, visually-suggestive syntax is a key reason I've stuck with org-mode despite its limited acceptance in the world at large.
The many flavours of markdown make it /less/ portable than org syntax, in my experience. As the post below says, "Pandoc lists six different Markdown flavors as output formats." This is not great for collaboration --- now we need some sort of middleware or advanced editor to help people work with more than one syntax format. Besides, mixing syntax in the same document is a boo-boo, because parsers only work at file-level, not semantic token level.
Owing to this, at times, I go as far as to /author in orgmode, but share in markdown/ (org-export), and slurp back and forth (tangle / detangle).
I had no idea any of this stuff worked well enough to actually run modern games. The FEX emulation layer. The eGPU. It's not how fast this stuff runs that impresses me, it's that it runs at all.
On Android vs iOS, it's worth noting Android apps are smaller than iOS apps. The details are complicated but this report says after installation Android apps take up about half the space as iOS. https://www.safetydetectives.com/blog/app-storage-usage-rese...
The fascist website Stormfront lost their .org in 2017 with some very unclear procedural action, but I don't think it was a ServerHold. It was offline for quite awhile and I think genuinely hurt the site. Although it looks like it's back now?
I think this was genuinely due to the Norwegian Massacre. The guy who did it had an account on stormfront. The whole thing exploded and the owner had to explain that he was not in contact with the mass murderer.
On the flipside, clock sync for civilians has never been easier. Thanks to NTP any device with an Internet connection can pretty easily get time accurate to 1 second, often as little as 10 ms. All major consumer computers are preconfigured to sync time to one of several reliable NTP pools.
This post is about more complicated synchronization for more demanding applications. And it's very good. I'm just marveling at how in my lifetime I from "no clock is ever set right" to assuming most anything was within a second of true time.
I was doing something at work that involved calculating round trip times from/to Android devices, and learned that although it should be possible for NTP to sync clocks with below-second precision, in practice many of the Android devices I was working with (mostly Pixels 2-7) were off from my server and each other by up to 5 seconds, which blew my mind.
It's hard to keep a phone's clock closely synchronized because they experience a lot of temperature swings, going between pockets and hands and open air and sometimes in direct sun, and the processor goes between idle and 100% as well.
Once you get to internationa phones, you'll have places where the phone does not include all timezones and specifically is missing the actual local timezone, so automatic sync is typically disabled so that the time can be set so that the displayed time matches local time... even if that means the system time is not correct.
It’s not that hard. You would not expect 5 sec drift on phones that can sync time on the web at least once a day or once a week. A basic quartz crystal can keep time to within seconds per month of drift. High quality phones can do the same or better. Also the phone should keep track of system time as epoch time, and convert to local.
> Also the phone should keep track of system time as epoch time, and convert to local.
Yes, but imagine your local time is US Pacific time, but you have a phone intended to be sold in Mexico, so your phone only has Mexico time zones and MX Pacific Time has no DST. During part of the year, you can use automatic time sync, but during the summer, you disable automatic sync and set the clock so that the time displayed matches local time. Your epoch time is now an hour ahead of properly synched devices, but whatevs, your phone shows the right time and that's what counts.
Don't a lot of cellular networks rely on highly synchronized clocks to properly handle TDMA-style transmissions? Shouldn't they be very in sync with the towers' times?
I do believe there are (fairly) tight tolerances for clock synchronization between the network and the user equipment/handsets, but I don't know that it necessarily involves communicating the wallclock time. And the oscillators for signal timing aren't necessarily used for timekeeping.
I get that, but often the towers use GPS disciplined oscillators from what I understand (and have seen in limited circumstances), they inherently know exactly what time it is. Seems trivial to sync that as well, just kind of assumed they did that.
Depending on carrier-specific configuration and firmware phones may be configured to prefer NITZ (time transmitted by the cellular network) instead of NTP. That time is probably what’s off and would explain your observation.
I don't think civilian clock synchronization was an issue since a long time ago.
DCF77 and WWVB has been around for more than 50 years. You could use some cheap electronics and get well below millisecond accuracy. GPS has been fully operational for 30 years, but it needs more expensive device.
I suspect you could even get below 1 sec accuracy using a watch with a hacking movement and listening to radio broadcast of time beeps / pips.
Both of the WWVB clocks I've owned have been very fickle about how they're placed because RF be that way sometimes, and Colorado isn't exactly nearby to my location in Ohio.
The first manufactured GPS clock I owned (as in: switch it on and time is shown on a dedicated display) was in a 2007 Honda.
And even after it began displaying the right time again, it had the wrong date. It was offset by years and years, which was OK-ish, but also by several months.
Having the date offset by months caused the HVAC to behave in strange incurable ways because it expected the sun to be in positions where it was not.
But NTP? NTP has never been fickle for me, even in the intermittently-connected dialup days I experienced ~30 years ago: If I can get to the network occasionally, then I can connect to a few NTP servers and keep a local clock reasonably-accurate.
The WWVB clocks are around the AM band, which means they carry a great distance despite their lower transmission power, but only at nighttime. Ohio is nothing; the signal needs to make it to the southern reaches of Florida.
Yeah, I "know" how it is supposed to work. I "knew" that back then when I bought my first WWVB-receiving clock, too.
And the placement was still fickle.
It's simple to observe:
A) Purchase and install clock. Wait (days). Observe failure to chooch.
B) Move clock. Wait (hours). Observe correct operation.
My world is ultimately bounded by reality, not theory: When it works in one position but not another, then that's the only reality I have to work with.
On the one hand, some sloppy GPS units fail on a 20 year schedule. On the other hand, a bunch of things using NTP are going to fail in about ten years. (2036 rather than 2038 because reasons)
If I ever get the chance, I'll try to remember to tell the 1995 version of me to watch out for that pesky overflow bug that they might experience with NTP -- two score and 1 year in their future.
At this point the only clock in my life that doesn't auto set is the one on my stove, and that's because I abhor internet connected kitchen appliances.
In the 80s my uncle had digital clocks that used an antenna to tune into the atomic clock time signal that (was/is?) broadcast nationwide. I've long wished that it was incorporated into stoves, microwaves, essentially everything that isn't an internet device (yet... sigh)
Sadly I think the actual antenna and hardware were relatively large since it's a long wave signal, but maybe with SDR it'll all fit on the head of a pin these days.
I believe it was a longwave broadcast so probably WWVB which would apparently imply a 60mm antenna, but it was a standard old school "GE digital clock radio" form factor so size wasn't at a premium.
> Sadly I think the actual antenna and hardware were relatively large since it's a long wave signal, but maybe with SDR it'll all fit on the head of a pin these days.
Unfortunately there's no real way to cheat physics as far as shrinking a wavelength goes. With RF antennas about the best you can do is a major dimension 1/10th the frequency of interest.
There are many DCF77 receivers in Germany that are contained in a square box that's barely large enough for a AA battery; the rest of the square contains the motor/gears and the electronics/receiver (incl. a ferrite loopstick antenna).
Yeah, that's because it's receiving an extremely narrowband signal accumulated over a long window so it can suffer the trash efficiency I'm talking about.
"This particular [80B] model is what I’m using with 128GB of RAM". The author then goes on to breezily suggest you try the 4B model instead of you only have 8GB of RAM. With no discussion of exactly what a hit in quality you'll be taking doing that.
This is like if an article titled "A guide to growing your own food instead of buying produce" explained that the author was using a four-acre plot of farmland but suggested that that reader could also use a potted plant instead. Absolutely baffling.
Syncthing is such a reliable workhorse. I hope the Android situation gets sorted out. It's been tricky over the years as Android makes it harder and harder to work with simple files.
Nowadays there are people out there, who use computing devices (can we still call Android phones that?), who don't even know what a "file" is. Mind-boggling, or maybe not so much, considering the constant pushes by big tech.
I respect Anil's argument that the extensibility has helped it be adapted to different contexts, and in practice the looseness of it doesn't cause a problem. I do wish CommonMark had more traction (and acceptance and use of the name Markdown). It'd be nice to have a standard, at least for the basic stuff.
reply