Hmm. The tweet, and thread on Twitter, has more actual information on the vulnerability than the page you linked to. You have to click through to the actual paper to get the additional information. I feel like the Twitter link gives a better quick summary information.
I personally like the summaries. Papers are typically written to sound smart, not to read nicely. HTML scales, users can configure the font, you can click pictures to enlarge... but instead we choose to use PDFs. Why? I speculate it is because everyone else who sounds smart does it. This particular paper is not as bad as most (no serif font, 8pt text, small and unreadable diagrams, references instead of practical links) so it's definitely not all directed at this particular paper, but I do question the usefulness of linking to a longer text instead of to a useful summary that has a link to the longer text.
GP is right in that the first 15 words of the tweet told me more than the whole 269 word blog post. I also recognized the author on Twitter but not on the blog. I'm happy the tweet is still linked in the comments.
Yes, my point is, either leave the link to the Twitter thread (which also contains a link to the paper), or link directly to the paper. Linking to this summary page, which contains a brief abstract that contains more words but less information than the Twitter post, seems to be worse than any of the other options.
From what I have gathered, much of the reason behind the licensing process for barbers is for shaving, with a straight razor, which does have considerably greater risks of cuts and infection.
However, very few people go to a barber for a shave anymore. It used to be that most people would go to a barber for a shave, and shaving yourself was unusual. Since the advent of the safety razor, cartridge razor, and electric razor, it's the other way around, where it is unusual to go to a barber for a shave. But in many states, training on shaving is a large part of the training for barbers.
In fact, it also used to be the case that barbers were the surgeons as well, though I don't know how much of that time overlapped with the licensing era.
I don't know how much of the remaining licensing process for modern barbers has to do with actual safety concerns, or is just inherited from the times of barbers being surgeons or doing the majority of shaving with straight razors.
The documentation on the BOOM processor mentioned in this article seems to be a good source of information: https://docs.boom-core.org/en/latest/sections/RobDispatch/ro.... Link goes specifically to one component, the reorder buffer, the rest of the docs discuss more of the components that are necessary to make it work.
Also range, especially in winter. I have to drive about 180 miles every couple of weeks, and have another trip for a vacation that is about 580 miles (and no, flying would be impractical), which I usually do in one shot or with a single overnight.
There are very few electric cars on the market that make the 180 mile trip without a long charging stop on the way in good weather, the Tesla and the Bolt are the only that I know of (though it has been a while since I've checked), and I'm not sure how I'd trust them for that rage in sub-zero temperatures.
And the longer trip would probably require at least two or three charges. While it requires stopping for gas in a gasoline car, that's a 5 minute stop, not the 30 minutes to an hour for even a fast-charge to 80% you get on an EV.
I always have a hard time using some services when in incognito mode; I get the captchas, and either they are wrong or are really hard, and it can take several tries to get through them.
> Beyond that, it's 0.8-1.2g of protein are recommended MINIMUM daily intake to avoid diseases originating from protein deficiencies.
Eating below the minimum RDA of 0.8 g/kg is unlikely to cause diseases of protein deficiency. The RDA minimum is fairly generous to allow for a certain margin of error. Most of the studies cited by https://www.ncbi.nlm.nih.gov/books/NBK234922/ indicate that 0.6 g/kg is likely a sufficient reference, and that a recommendation of 0.75 g/kg allows for enough confidence to cover individual variation. There was one study cited which found a 0.8 g/kg minimum, but most of the rest found that lower values should be sufficient; it sounds like 0.8 was picked just to be on the safe side.
> At 220# that means 80-120g protein as a minimum. That's a fair amount, and far more than you're likely to get from vegetarian sources at the time alone.
I doubt that most Roman soldiers were 220#. The minimum height requirement was 5'5", and estimates are that the average height was 5'7".
> There's also a minimum amount of essential fatty acids to consider... at the time it's not like they had canola oil.
There's a certain vegetable oil that Rome and Italy are quite well known for.
I'm with you on being skeptical that they were vegetarian, but I think you're overstating the requirements a little bit. I think it's fairly likely that they ate a fairly low meat diet just due to the logistical difficulties of obtaining fresh meat or carrying preserved meat.
The word "linoleic" derived from the Greek word linon (flax). Oleic means "of, relating to, or derived from oil of olive" or "of or relating to oleic acid" because saturating the omega-6 double bond produces oleic acid.
It's not even really a replacement for NetworkManager; it's designed to be used to provide basic networking within containers, for systemd-nspawn. It can be used on host systems, but it's deliberately fairly lightweight and designed for fairly simple configurations in containers, rather than as a full fledged replacement for other networking management daemons.
> On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough?
Docker has won to a degree, though it still requires complex orchestration technologies like Kubernetes built on top of it, which are rapidly developing and not a particularly stable target.
> Although serverless and edge computing often use JavaScript.
Yes, this is where I see WASM really hold its own. Serverless and edge environments want to be able to have code running in a persistent process that is completely managed by the environment. Right now, they frequently offer just JS, or a couple of language runtime environments like Python as well; for serverless environments, you can generally load native modules if you want to, but its awkward, while edge environments will only run JS, though now they're starting to offer WASM.
It's the places where being able to run multiple tenants within a single process, without paying IPC and process isolation overheads, that make the overhead of WASM more likely to be worth it.
> On mobile this seems to depend on Apple and/or Google deciding to support WebAssembly for native apps, which seems unlikely.
I don't think it would be too unlikely for Google to support WASM for native apps. For one, it would allow them to do architecture independent apps without ART, on Fuchsia, for example. Right now, I think Dart + Flutter compiles to ARM code, but if they want to target a wider range of devices then platform independence could be important.
Hardware capabilities seem like they could be an interesting alternative to traditional separate address space memory management; they could allow you to have fine grained access control to individual objects in memory without having to have separate address spaces via a TLB.
However, they seem to be trying to stuff so much into the capability; there's a base, a length, and offset, permissions, sealing bits, extra bits reserved for user permissions, and so on. They're 256 bytes, 4 times the size of a normal pointer, plus an extra tag bit for validity.
They do have a compressed 128 bit version, with various alignment constraints, but it seems like they are trying to stuff too much functionality into these capabilities.
I feel like it might be more instructive to start from a much simpler capability design, with just simple fat pointers with a few bits used for tagging (due to alignment, or not needing to use the full 64 bit address space), and see how far you can get with that, without adding in all of the extra features and needing huge pointers or funky compression that imposes much stricter alignment constraints.
I recall skimming one of their papers, where they argued that they need base/length/offset in order to efficiently support existing C semantics. If you drop C compatibility you can get by with less.
