Thunderbird 140 Mail Client Debuts As Newest ESR Release lxer.com/module/newswire/ext_l…
Thunderbird 140 Mail Client Debuts As Newest ESR Release
The Thunderbird mail client developers today formally announced Thunderbird 140 as the newest Extended Support Release (ESR) for this cross-platform alternative to Microsoft Outlook.lxer.com
Adrian Tombu
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Adrian Tombu • • •5225225
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •0b01010101would transfer the fastest of them all)Asahi Lina (朝日リナ) // nullptr::live
in reply to 5225225 • • •Wilfried Klaebe
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •The USB 3 high-speed pairs use something better, nor?
@5225225 @to
Samantaz Fox
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Oh, so kinda like bit stuffing in CANbus where an extra bit of the opposite level is added after 5 consecutive bits of the same value.
However I don't understand why in USB it only applies to ones and not zeroes.
EDIT: Just reat the other post about NRZI coding, it now makes perfect sense! But that remains cursed nonetheless x)
PortabelloBelle 🇪🇺 🏳️⚧️
in reply to Adrian Tombu • • •1s are heavier 😁
PortabelloBelle 🇪🇺 🏳️⚧️
in reply to PortabelloBelle 🇪🇺 🏳️⚧️ • • •Speaking of weight, does physical memory get heavier the more data you add to it?
Asahi Lina (朝日リナ) // nullptr::live
in reply to PortabelloBelle 🇪🇺 🏳️⚧️ • • •Take this with a grain of salt, but I get that a modern SSD using 3D NAND gains around 0.05 picograms per terabyte of data stored. 0s are heavier and an empty SSD is all 1s.
Roughly going by the cell geometry and electron density mentioned in this paper, which works out to around 300 electrons per programmed cell, taking 150 as an average (whitening) and assuming TLC flash: jstage.jst.go.jp/article/elex/…
This does not apply to RAM since that uses capacitors, so you take electrons from one side and move them to the other, so no net weight change.
Räucherkäse
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Räucherkäse • • •PortabelloBelle 🇪🇺 🏳️⚧️
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •@smochi @to
When I posed this question, I was expecting to get a chuckle, or perhaps a bit of philosophy, I'm astonished that I got this wonderful information in response to what I thought was a bit of whimsy.
Räucherkäse
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Eragon
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Is it still true in USB 3.0 (or 3.1 or any other newer revisions with their cursed naming scheme)
Asahi Lina (朝日リナ) // nullptr::live
in reply to Eragon • • •Ember
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Ember • • •Gerard Braad
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •letterbeen
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •mmu_man
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to mmu_man • • •Z̈oé ⛵
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Few people know it but the reason for this is very simple. While zeroes are round, a 1 has a sharp corner and a hook that could get stuck and damage the insulation around the copper if you would completely fill the line with ones. Instead, sending some zeroes every now and then to flush any stuck „1“ before a clog can develop.
A 0 can be neatly pushed through the copper at high pressure without damaging the cable.
Now you know!
Jean-Baptiste Quéru
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Aatch
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Marc
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Janek @ IndieDev.site
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •the USBus is coming
#memes #programmer_humor #funny
Jan
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Since USB 3.0 it uses an 8b/10b scheme, 3.1 Gen 2 moved to 128/132b.
Do you know what kind of hardware improvements made this possible? Better clock stability of the transmitters?
Greg Brooks
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •MacBalance
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •A theory: I vaguely remember reading about signal formatting for telecom (probably elderly T1 signaling or similar) where a specific pattern of bits was used for control signals. If the data had this pattern, there was a workaround to allow it.
Perhaps the USB standard has some similar aspect, so the transfer has more overhead as the host has to constantly say “you’re not going to believe this, but there’s some more empty bytes coming.”
recursive 🏳️🌈
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •✧✦Catherine✦✧
in reply to recursive 🏳️🌈 • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •Are there even any other half duplex cabling standards of that speed? Everything else I can think of moved to dedicated tx/rx lanes and better encoding long before (physical or logical like the 1GbE stuff).
Edit: Oh, right, FireWire 400...
✧✦Catherine✦✧
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •Piggo
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to Piggo • • •Wolf480pl
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •also, wouldn't having a separate differential pair for clock make it even more of a mess, since over a long cable it'd be hard to match the delays?
✧✦Catherine✦✧
in reply to Wolf480pl • • •@wolf480pl @piggo @recursive you would have two pairs, one in each direction, with clock embedded in each
(this is how USB 3 works already, like PCIe and SATA and SGMII and basically every other high speed protocol since 2005 or so)
Wolf480pl
in reply to ✧✦Catherine✦✧ • • •@whitequark @recursive
I was referring to @piggo 's
> because the clock sync is in-band, right?
having the clock embedded, as you're describing, is easier to deal with than having a clock separately, right?
(although PCIe and HDMI do have a separate refclock... but they still do clock-and-data recovery on the data pairs too, right? Is the refclock only to get their PPLs in the right ballpark, to make the CDR lock quicker?)
✧✦Catherine✦✧
in reply to Wolf480pl • • •@wolf480pl @recursive @piggo yes, it's mostly useful for power management (lets you disable the PLLs without worrying it'd take the CDR too long to lock)
it's also used for EMI (refclock is often spread spectrum modulated)
Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Asahi Lina (朝日リナ) // nullptr::live
in reply to ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •@wolf480pl @recursive @piggo my understanding is that the tolerances on the clocks work out regardless of whether one side does spread spectrum or both
i'm not even sure it could be defined any other way, your elasticity buffer and skip insertion needs to be spec'd for the worst case (and it is, quite tightly in case of PCIe)
artemist
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Az
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Markus Osterhoff
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •Kees N ✅
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •(yes, I'm getting old).
Ingrid
in reply to Asahi Lina (朝日リナ) // nullptr::live • • •