The data exchange between host and guest is still unspecified. You can not access host objects from Wasm. Most do just string serialization, which is not fast. Or they write libraries for some particular languages, which damages the universal idea of Wasm. And WASI seems to be quite controversial: https://www.assemblyscript.org/standards-objections.html
Reading though that link is very confusing as someone who hasn't been actively following all of the various standards and organizations in detail. Quite a lot of the technical claims seem a bit vague and hard to evaluate without being more of an expert (like the repeated complaints about WASI being bad for Java/JavaScript/"the Web"). Pretty much the only concrete technical concern I could glean is that whoever wrote that was extremely unhappy about the use of UTF-8 over UTF-16, which I can understand feeling strongly about, but I also feel like the situation where there's a choice between the way Java/JavaScript/Windows does it and the way a lot of other things do it isn't exactly an original problem to WebAssembly. There's merit in the idea of sticking with what a lot of web stuff already uses, but it's not really that crazy to consider that a new standard would be the place where you might try to design with an eye towards shaping the future rather than always following the past.
Moreso than anything technical though, there sure seems to be a lot of bad blood between the group of people behind AssemblyScript and the people behind WASI. This feels like a classic case of small initial technical disagreements spiraling out of control and turning into a larger conflict fueled by personalities and organizational politics. I agree that overall this doesn't add confidence to the WebAssembly ecosystem as a whole, but it's not clear to me that the obvious conclusion is "WASI is controversial" as "WebAssembly seems like it might have a problem with infighting".
"the group of people behind AssemblyScript" is just one person, as far as I can tell from this doc / the relevant Github threads. I wouldn't necessary call it infighting per se, at least not from this interaction.
Wasm has a fundamental problem: int64 is an insufficient data type for real use cases. If you want to create some kind of plugin system based on Wasm, you need to exchange structured data. But most languages disagree about the memory layout. Dynamic languages do tagging, compiled languages do not. And the UTF issue shows that even with strings, there's still no real agreement.
Furthermore, there are now competing interest groups within the Wasm camp. Wasm originally launched as a web standard: an extension of the JavaScript environment. However, some now want to use Wasm as the basis for replacing containers: an extension of a POSIX environment.
The version using the 4-core CPU Intel N97, which is specified by Intel as an embedded CPU, certainly has in-band ECC, which was tested by some reviewers of this SBC.
I do not know whether the 8-core version (H4 Ultra) also enables in-band ECC, as for that CPU Intel does not specify embedded uses, so they may disable the ECC support in the factory.
I see that someone has enabled successfully in-band ECC on the 8-core ODROID H4 Ultra and has run benchmarks with ECC disabled/enabled. Therefore it appears that in-band ECC support exists on all models.
The results of benchmarks with in-band ECC disabled/enabled may be not representative for real workloads. In-band ECC relies on caching the ECC bits in a dedicated ECC cache, in order to avoid excessive memory accesses. The effectiveness of the ECC cache can be very different for the benchmark and for the real workload, leading to misleading results. Usually for the real workload it is likely that the cache hit-rate will be higher, so the performance drop with in-band ECC enabled will be less conspicuous.
I can confirm that the Odroid H4 Plus also supports in-band ECC. If I remember right, Memtest86 showed different stats when I ran it with in-band ECC enabled/disabled though I didn't have a good way to test that an error was actually corrected.
Some systems allow forcing an ECC error, but assuming that's not available, if you can adjust memory voltages or timings, you can usually encourage errors that way and confirm memtest detects ECC corrections.
All CPUs with ECC support allow the forcing of ECC errors, but unfortunately in recent years the CPU vendors usually do not document how.
Only when they expose this feature in Linux EDAC drivers it becomes possible to do this. In the past Intel had maintained well its Linux EDAC drivers, but AMD had frequently great delays between the launch of a CPU and the update of the drivers. After the many lay-offs at Intel, it is unknown whether in the future their Linux support will remain as good as in the past.
I think the XDG spec is pretty petty. What difference does it make that the files are in ~/.config/mozilla instead of ~/.mozilla? And calling it a bug is presumptuous.
The difference is that I don’t use standard XDG directories because I loathe dot-files, loathe hidden directories, and so I declare my own environment variables to put everything where I want.
Then Firefox (and ansible, and many others) comes barreling in dropping an unconfigurable dot-directory in my fucking home folder ignoring the perfectly good XDG variables I have set.
It is a constant struggle to stop my home folder from not feeling like my home. Developers ought to learn some fucking respect.
This, I set an alias for `adb` to use `"$XDG_DATA_HOME"/android` instead of `~/.android` because it stores the keys there for whatever reason. I would rather not see my home folder being cluttered with hidden files, it makes backing things up unnecessarily complex.
export ANDROID_USER_HOME="$XDG_DATA_HOME"/android
alias adb='HOME="$ANDROID_USER_HOME" adb'
Perhaps you should've started to launch your shell in "~/home" instead of "~". Now your home is 1 level down, and the only downside is typing "/home" after the tilde.
One being that it's _my_ $HOME, not some random developers'. I literally had more than 50 different dotfiles and dotfolders in my $HOME at some point. It was a garbage dump and I couldn't even identify the culprit with some of them. Simply disrespectful.
Then there's the issue of cleaning up leftovers and stale cache files. It shouldn't take a custom script cleaning up after every special snowflake that decided to use some arbitrarily-named directory in $HOME.
Not following the spec also makes backing up vital application state much much harder.
In the end, I made my $HOME not writeable so I could instantly find out if some software wants to take a dump. It turns out it's often simply unnecessary as well, the software doesn't even care, just prints an error and continues.
the main benefit (which even with this change, Firefox won't get) is the separation of configuration, cache files, binaries etc which sysadmins likely want completely different policies for. e.g. cache shouldn't be backed up, config shouldn't be executable etc
By "doing many different things", I meant that everything disagrees on what should be config and what should be data. People will disagree with any division you pick for something with as varied types of data as a web browser. And some of them will be right, and for good reasons, which means you'll have to sign up for repeated migrations across different versions.
I'm not saying it's a bad idea to try to follow xdg, just that it's a complex and ongoing thing. It's a good example of the "Just do X!" fallacy.
Have you ever `ls -al ~/` on a heavily used unix system? Absolute rot and chaos. I have like 100 hidden directories+files in the root of my home directory. Some of them are caches, some are configs.
This was my first dark mode: https://www.dosforum.de/viewtopic.php?t=12253
Been there, done that. A black background is generally more tiring for the eyes. A black background means less light. Less light means the eye's aperture has to open wider. A wider aperture means less depth of field. Less depth of field means the eye has to work harder to focus. There are reasons for using a black background on a mobile phone, as it can save energy. But for any device that has a power adapter, a black background is simply self-flagellation.
It depends on the environment. Of course, reading HN in a dark room will never be pleasant. But looking into a bright white flashlight can really hurt. Good dark modes are not simply black/white but make use of the right font weight and color to reduce glare.
I for example develop my (black and white) films myself and leave them to hang dry uncut, then proceed to store them in a box. When I have the time, I "scan" them using a MILC on a tripod, a 3d printed holder and a LED backlight panel. Afterwards I cut the strips up and file them properly for long term archival. Many of us do it this way.
reply