Is everyone here too old to remember MapQuest or CD based car navigation systems? Apparently. We had decent turn by turn in the 90s. In the US mapping data was heavily derived mostly from public Census TIGER data, which had flaws but was good enough.
Just recently I had to explain how that thing works on an old car. In the end, my advice was to just slap an Android phone/tablet on the dashboard and forget the stupid CD satnav :D
They also had a backseat DVD player with (shudder) analog video input. The quality was atrocious!
Yes my intention was that it's more or less the reference version of that model, certainly databases like System R existed many years before Volcano :) I appreciate the correction.
It continually disappoints me in IT how the same things are rediscovered over and over again. I suppose its because you can get an IT job without much IT education, just make some web sites and you're an expert.
Unfortunately this is always an unrealistic request for anyone with a public profile. Those that have no desire to speculate won’t, and it’s not going to stop the curious. Frankly I tend to agree it is moreover an unreasonable request as long as no one is actively invading the privacy of the family.
Maybe that is what the issue is? Some, well many, DNS providers provide value add transparent additional features like redirect and email. If their web infrastructure is down then that might not work even though the core DNS shit does.
> (A harder problem is Japanese — Japan really got screwed over with Han unification, so choosing Shift-JIS over any Unicode encoding is often best.)
This statement needs more support. I think “screwed over” is a bit harsh, since I’m not aware the impact on Japanese was anymore than the rest of CJK. Despite the Han unification controversy, Unicode has been heavily adopted in Japan. The space requirements are basically the same as all CJK. Half-width kana is heavier since they are one byte in shift jis but they’re relatively uncommon.
As far as I'm aware one problem is displaying text. Japanese readers generally need a Japanese font to correctly display Japanese text if it's Unicode. This becomes a problem when you potentially have text that can come from different languages. E.g. a Japanese font will display Chinese incorrectly.
On the web you can work around this using the lang attribute to tell the browser how text should be interpreted.
It's notable that, for example, traditional and simplified Chinese does not have this problem because they are encoded separately.
Another problem is missing characters. Some people have complained of not being able to write their own name. I'm not sure to what extent this has been solved through Unicode updates.
I have been learning Japanese for about a year now, so I don't have that much experience reading Japanese text yet [1]. I'm aware of some of the visual differences between Chinese and Japanese fonts, but I have not yet had trouble reading Japanese text set in a Chinese font. If you have any specific examples for Kanji that are difficult to recognize in a Chinese font, I'd be interested.
[1] Although on the other hand you could argue that I'm spending more conscious effort reading Japanese text than a native speaker would.
Sorry, I can't speak confidently on this because I can't read Japanese (or Chinese or Korean). I can only report what I've been told by users.
Including language metadata with text was felt to be especially important for Japanese and Korean users. I was told the difference was like having "595 kg" displayed as "5P5 kg". That is, it's possible to decipher the intended meaning but it looks wrong and it takes a moment to work out what was meant. Depending on the language some glyphs can be mirror images, have extra strokes, strokes missing or in different places or at different angles.
How does that make it an RS-232 with channels? You’re confused. RS-485 just like RS-232 is an electrical specification for serial signaling (with multiple access), nothing more nor less. There are USB to 485 converters that basically operate exactly the same as their serial port counterparts and will show up as a tty device in Linux/Unix flavor or a COM port in Windows.
It's a bus, rather than point-to-point. Schemes to address devices on the bus separately exist. You could call them "channels" even. RS-232 can't do that, as it isn't an electrical bus. Respectfully, you're confused.
Since tty's are fairly well married to a serial port, adding an ioctl() (or similar) that would switch channels would seem likely. RS-485 would provide a way for that to work not just with ptys, but with real physical devices as well. With reasonable backward compatibility.
RS-485 is an electrical signaling standard, for carrying arbitrary bytes between a transmitter and a receiver. There isn't even any built-in concept of a packet, let alone an addressing scheme. It's no different than RS-232 at all, in that respect.
When compared against RS-232, only the signaling voltage and impedance requirements are different. That, and also RS-485 has no standardized connectors or side-band signals (like CTS/RTS).
Sometimes RS-485 is used half-duplex over a shared differential pair. In situations like that, slave devices are often designed to keep their transmitters disabled unless responding. Sometimes, these setups will have a couple of devices listening for data.
Lots of people implement custom bus protocols _over_ RS-485. But RS-485 by itself has no concept of buses, packets, addressing, channels, slave devices, or master devices. It's just an electrical signaling standard. Nothing more, nothing less.
It's kind of like saying "AM radio-waves are a format for carrying music". Sure, some people transmit music over AM radio. But that doesn't mean that the actual radio waves have any knowledge or accommodation for what they're carrying.
The way 485 addresses devices is... just to prepend an address byte. Or bytes. Whatever you want, really. The link layer, which RS-485 is, doesn't care.
As others have said, RS-485 isn't really the way to do this. It looks like RS-232, but it's just close enough to mislead you while being far enough away to be a total nightmare. For example, any bus collisions have to be handled in software. A driver that has to recognize and deal with bus collisions looks very different from one for a dedicated line.
This rabbit hole is probably not worth going down.
This is really reaching. Channelization as being referred to upthread in reference to SSH or RDP is a protocol level abstraction, rs485 bussing is at the electrical level for multiple physical devices and also doesn’t specify any addressing scheme, that would be specified as a higher level protocol (that could be done just as well over rs-232). Device addressing and channelization are not even logically the same thing.
Ethernet as it is typically deployed is not a bus either but it is used in channelized communication (packet switched no less) just fine.
Edit: responding to your edit. The point still stands this is orthogonal to the physical or electrical layer. The vast vast majority of the internet including Ethernet and fiber links are point to point and clearly they carry a tremendous number of separate streams, and a small amount of broadcast. You can run layer 2 over an RS-232C serial port, whether its Ethernet, PPP, SLIP or ATM. In Linux PPP is in fact implemented as a tty line discipline.
As for RS-485, there are widely used standards such as DMX512. It is not a strongly supported idea to put this stuff in the kernel, when performance in user space is sufficient.
Finally, RS-232 can do the same thing (multidrop) with electrical repeaters. See MAX3322 eg.
It has some features that zfs lacks such as a dedup story that is actually usable, plus more flexibility in reshaping. Other than its native raid 5/6 story what major features is it lacking in comparison to zfs? I agree the tooling is trash compared to zfs (zfs command line is a delight by comparison). Also stability wise i haven’t noted problems in years. Not to take anything away from zfs which has proven itself in its particular use cases, but btrfs is alright.
> Also stability wise i haven’t noted problems in years.
Counter anecdote: I have a laptop (single disk) running opensuse tumbleweed with root on btrfs, and it's managed to completely break its root filesystem twice. One of those times I tried to recover it, but in the end I just reinstalled.
Not that I know the exact hardware and circumstances, but in my experience that sounds like a hardware issue, either a buggy controller or a failing disk.
Zfs -with it's similar checksumming and integrity features- would likely have faced similar issues.
It happened months apart and I never saw it report data errors. It could still be hardware, of course (I haven't tried to run ZFS on the same hardware), but even if it was a hardware fault this isn't an impressive failure mode. Like... what are the odds that a random hardware bug breaks BTRFS metadata in such a way that I can't even mount the filesystem, and never just breaks random files such that I get an isolated read error?
Agreed, btrfs has been stable for a long time, aside from RAID5/6, which are going to be uncommon on a laptop or desktop computer. Unfortunately, 10 years ago this was definitely not the case, and btrfs hasnt been able to shake off that reputation among some people since then.
> Other than its native raid 5/6 story what major features is it lacking in comparison to zfs?
For example, native at-rest encryption. dm-crypt/luks is adequate, but has significant performance problems[0] on many-core hardware with highly concurrent storage (NVMe) due to excessive queuing and serialization. You can work around these things by editing /etc/crypttab and maybe sysctls.conf, but the default is pretty broken.
Per-dataset properties, including different compression policies, exec/noexec, setuid/nosetuid, case-sensitivity, volumes, and snapshots that actually make sense.
