Hacker News Reader

Comment by syrusakbary | Hacker News Reader

I have mixed feelings about this.

In one side, I'm happy that some of the people affected by the Mozilla layoffs have now secured a job.

On the other side, now almost all the power of the WASI standard is concentrated into the Fastly corporation (with wider penetration thanks to the WASI integration in Rust). The main and only player of the Bytecode Alliance becomes Fastly as well (as Mozilla is out of the server-side Wasm game).

So... how this could be bad? The Bytecode Alliance has been biased since their inception, blocking any attempt of collaboration from Wasmer based on personal bias (I work at Wasmer) and other external entities out of their control [1] [2] [3]. This move is conceding them now a full-control over a standard such as WASI, placing the whole standard at risk [4]

[1] https://twitter.com/syrusakbary/status/1202351432050954240 [2] https://github.com/WebAssembly/WASI/issues/3#issuecomment-71... [3] https://twitter.com/cjihrig/status/1320763509463015425 [4] https://twitter.com/cjihrig/status/1320761713365581824

View on HN

By attempting to trademark WebAssembly you've outed yourself as a hostile actor.

You don't then get to go and complain that the community isn't treating you well. They're right not to trust you.

You use Oracle's JS trademark as precedent, but that's woefully ignorant of how it came about. JavaScript was not a four year old open standard when Oracle came along and scooped it up. JS was a Java branding deal between Sun and Netscape.

If you want to contribute to build something good, because a strong wasm community is in your best interest, drop the attitude and don't make any more moves to sabotage the project.

If you want to lawyer up and try to exploit the fruits of the community, then do that. But you need to pick a lane. I don't see Larry hanging around HN complaining about how people are treating him on GitHub.

I don't have a dog in this fight. Prior to this thread, I didn't know about you, your company, or anyone in all these links you've posted except I remember reading a post by Lin Clark once.

I wrote another post that I deleted pretty quickly when I realized how aggressive it sounded. But it wasn't trying to be aggressive, just convey the hostility of what you did and how you should expect people to react.

The Bytecode Alliance veto of Wasmer happened the same day it was announced, on November 12 2019 (via direct message by one of their well-known members -now working at Fastly- to a Wasmer investor). Back then, the trademark was not even filed by the lawyers (if you look to the USPTO filings), so I'm not sure how the hostile actor argument could apply here (if we really buy into that argument).

As reflected in other comments in this thread, it's not in Wasmer intent to trademark WebAssembly. And we successfully course-corrected any actions way before it was even public.

We have been continuously pushing the limits of WebAssembly since we were founded. The success of Wasmer as a company solely depends on the success of WebAssembly as a technology, and is on our best interest to continue pushing it forward.

In fact, I'd argue that Wasmer has been pioneer in:

    1. Open-sourcing the first working Rust WebAssembly runtime (wasmtime existed when I created Wasmer, but was not able to run anything [1])
    2. Creating a Package Manager for WebAssembly [2]
    3. Creating WebAssembly embeddings for non-js languages (PHP, Ruby, Python, ...)
    4. Running WASI fully in a browser, including an online shell [3]

[1] https://github.com/wasmerio/wasmer/issues/142#issuecomment-4... [2] https://wapm.io [3] https://webassembly.sh

Er... did you reply with your sock puppet by accident [1] [2]? If so that's kind of frowned on here, especially if you were using it to vote.

I'm totally willing to entertain arguments that the Bytecode Alliance are also acting in bad faith. It's a harsh world and open source is not all unicorns and rainbows.

But you can't just brush off the trademark issue by claiming it was unintentional. Especially when what you write here doesn't fit well with what you've written elsewhere [3]. I've gotten trademarks through lawyers before and the level of detail was an intense experience.

You seem to be claiming your lawyers independently decided to trademark WebAssembly and you signed the pages without reading them? At least that's what I can put together from your vague writing about it.

If you're not willing to give a concrete step by step post mortem of how such a clusterfuck happened, the community should (and I'm sure does) feel at liberty to not believe you in the slightest. You don't owe them an explanation, they don't owe you their trust.

You're clearly good at technology, better than me I'm sure, and I'm no slouch. You're doing impressive work and I have no wish to downplay that. But you appear to be quite bad at getting along with people. Maybe you can make your business work without developing that skill, and if that's your plan then best of luck to you. Sincerely.

[1] https://i.imgur.com/TPBH9EH.png [2] https://news.ycombinator.com/item?id=19515476 [3] https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...

> If you're not willing to give a concrete step by step post mortem of how such a clusterfuck happened, the community should (and I'm sure does) feel at liberty to not believe you in the slightest. You don't owe them an explanation, they don't owe you their trust.

Agreed, perhaps that's the best way.

> Wasmer the company might have been announced November 12 2019, but the open source project was around a year before that. I don't know what happened prior to that date to make the Bytecode Alliance members want to "veto" you as you put it, and maybe you're entirely blameless for that. As you point out, your trademark shenanigans hadn't taken place yet. But saying the "veto of Wasmer happened the same day it was announced" is misleading at best.

I think you misunderstood. I meant that Wasmer itself was vetoed from joining the Bytecode Alliance the same day that the Bytecode Alliance was announced. Wasmer was founded way before (as a company and a open-source project).

> But you appear to be quite bad at getting along with people.

It's curious this is the impression caused. I'm definitely not someone with low social skills.

EDIT: added an extra response

I'm sorry, I did indeed misunderstand that. You were clear, I just parsed it wrong.

So the criticism in that paragraph is undeserved, I've removed it for clarity but will leave it here for posterity.

There are at least two other organizations that contribute to the Bytecode Alliance, so I don't see how Fastly has overtaken the standard. Could you elaborate on that?

As for "personal bias," I think that's fair game considering the personal history between you and one of the members of BA. Wouldn't exactly be psyched to work with you either.

>The Bytecode Alliance has been biased since their inception, blocking any attempt of collaboration from Wasmer based on personal bias (I work at Wasmer) and other external entities out of their control

Their persona bias seems to be summarized as (from the github issue):

>The rejection from the Bytecode Alliance was based on a history of behavior that isn’t compatible with the BA codes of conduct—both the individual CoC and the organizational CoC.

Which seems a lot less like personal bias and a lot more like both you personally and your company have crossed too many lines to be considered good members of the community. Given your response was to lash out everywhere rather than take it as constructive criticism to grow with I suspect your behavior beforehand wasn't much better.

surely you have a better example of your gripe than closing a GH issue on the logo design... the whole conversation on your end seems petty and toxic, at first glance.

Some context from that thread I find important (I’m a bystander not involved in any way):

> We would need to work with a lawyer to determine the IP issues around this. It’s possible that just using the same policy as for the WebAssembly logo works, but I know that various organizations have grown more concerned about IP in this space since then.

> This is in no small part because your company, Wasmer, attempted to register “WebAssembly” and “Wasm” as trademarks. The USPTO rejected the application, but I don’t think we can assume that attempts to register a brandmark for a WASI logo would be similarly rejected.

This doesn’t seem to be a he said she said situation; gp had the chance to defend himself and all he could come up was a very weak “The trademark requests were driven by our lawyers” (and what came after that was even more shameless if you ask me): https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...

Given that context, I’d say the gp comment (especially the “personal bias” part) is likely motivated smearing.

Bottom line: don’t make up your mind just because it’s the top comment of an HN thread, or because the discrimination/racism card is played (racism card isn’t played here, it’s in the linked GH issue). If you want to form an opinion, read the other side first.

There is much more context to the "personal bias" statement than what is provided in the thread.

But 100% agreed, it's essential to stay critical before making your mind on a given thing.

If there’s more context you’re certainly not communicating it very well and all we see is some company attempting to trademark something they neither invented nor owned and crying discrimination with little to no supporting evidence.

Also, did you delete your downvoted comment then post the same thing in a new one? I saw your comment posted a while ago, in the gray, then when I refreshed before responding, bam, “0 minutes ago”. That’s not cool.

No doubt. It clearly seems that I'm not communicating well enough. But just to be clear: is not in Wasmer intent to own the Wasm trademarks (as stated in the Github issue).

And to answer your question: yes, I deleted the comment because I thought it was going to start a non-productive discussion (it had 1 point at the moment of deletion). Then I realized deleting could provoke some other issues, and decided to repost again.

Yeah, I know there is a spectrum of people that downvote my comments... and it's ok!

> But just to be clear: is not in Wasmer intent to own the Wasm trademarks (as stated in the Github issue).

Then why register?

"Our lawyers made us".

Lawyers can't make you do anything. They can advise. They can't act without your consent.

And expensive. I've dealt with the USPTO through professionals and the crackling sounds my burning savings made were quite loud.

We registered the trademarks as part of other process that we were not super diligent with.

We also course-corrected as soon as we realized of it, much before it came public a few weeks ago.

> We registered the trademarks as part of other process that we were not super diligent with

You accidentally attempted to register a trademark?

I have never heard of that. Either you are small enough that the non-trivial tediousness and cost of the process catches a lot of attention. Or you are large enough to have a general counsel overseeing a documented chain of approvals.

What other process?

I thought so too until I saw the existing logo... https://github.com/WebAssembly/WASI/blob/master/WASI.png

If you don't see any issue on a corporation having most of the control over a spec, then I guess there isn't anything I can say that will convince you.

> the whole conversation on your end seems petty and toxic, at first glance

That's a first! Can you expand on that? Thanks!

https://github.com/WebAssembly/WASI/issues/3

I didn't say anything like that, I was commenting on your commentary and not Fastly or the BA. That strawman you built up is an example of toxicity.

The pettiness is that this looks like a non-issue blown into a flamewar where the BA has every right not to accept contributions from yourself because of past actions taken by the business you founded. I thought it was fine for them to close the issue was out of scope/focus, it didn't need more attention or for you to project your own gripes onto it.

All told this thread left a very bad taste in my mouth with respect to Wasmer, while I have a lot of respect for the BA and Wasmtime teams and I'm very glad that they found a home at Fastly.

I'm replying here as a total independant, because you asked for a response :)

Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not the many related problems)

Thanks for your response! Agreed that a logo is a not thing that should be taken lightly.

Priorities in open-source communities are weighted differently by different members of it. We do care about accessibility, and the current logo have serious readability issues that affect disproportionally people with low-vision.

IMHO a "welcoming" community should encourage improvements, rather than halting collaboration because it doesn't come from the main members.

They stated that a proper logo process would require too much of their time to devote to right now and they don't want a half-assed process. Also, to your proposal to manage the process, they clearly don't trust you after your company tried that trademark BS. So from their point of view anything you're involved with would actually require even more of their attention due to potential legal liability.

So it's not about not being a main member but rather about being basically seen as a bad actor to the community. Actions have consequences and the consequence for the trademark BS is being seen as an enemy of the community. The way to resolve that is to not annoy them about things while being as helpful as possible. Your comments on Github definitely are not that (they're adversarial, clearly annoy them with something they don't want to deal with, etc.) which simply cements their view of you being a bad actor.

edit: Your attitude is one I've seen before and it works in getting things from people who are forced to deal with you (service workers, employees, government officials, etc.). It does not work for people who can just walk away, block you or blacklist you since they will just do that.

I agree improvements are good in generql, but logos are (in my experience) special. They can be a massive timesink, for big projects you have to get lawyers involved, and the arguments can suck up all the energy for months. Its also not something anyone can ignore, as once a logo is chosen you are stuck with it, generally.

If they are also rejecting good quality code, that's a whole other issue.

>people with low-vision.

What does this mean? How does this relate to current logo? Is this a color blindness issue?

There is a color accessibility issue with the current logo.

I've explained it here: https://speakerdeck.com/syrusakbary/wasi-logo-proposal

It's a logo not a paragraph of text. The overall image is supposed to convey the brand and not just a piece of it. Even W3/WCAG agrees and logos are exempt from the contrast requirement. So your whole argument of citing WCAG is irrelevant as it explicitly doesn't apply to logos.

It really depends if you consider "WASI" as essential to the information conveyed in the logo. Or said in other way: if the logo intent is to be readable.

https://www.w3.org/WAI/WCAG21/Understanding/images-of-text.h...

I don't see how that link is relevant. Essential in that link simply indicates, as I read it, that the specific way the text of an image logo is rendered is essential to it's function. In other words that you can't simply replace the WASI in the image with the text "WASI." Essential does not mean that is must meet some requirements or be readable. In fact the contrast requirement your presentation cites is explicit in that it doesn't:

https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...

>Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

There's always RISC-V :) Nothing wrong with it, or anything preventing it to be just as fast. The only thing it doesn't have yet is a standardized vector-extension, but it's probably pretty close.

We just need JIT support for an embeddable RISC-V emulator, and we're golden. Does it matter what the host language is these days server-side? I suppose there's a higher chance that the WebAssembly standard will adopt some instructions that favor cloud computation now, with these news.

I think WebAssembly still has a bright future, regardless of a corporation practically gaining control over a standard (there's always opportunity for more standards).

Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic:

https://medium.com/@losfair/a-comparison-between-webassembly...

It's good, but a few issues:

- RISC-V is a large family of ISAs, though Unix platform targets a much narrower definition, the RV64GC. The "Feature table" lists FP and SIMD as "in extension" but doesn't do the same for Memory layout and protection. It's seems inconceivable to me that you would use paging in a WASM-replacement context. Same for instruction length, two-byte instruction depends on the "C" extension.

- There is nothing that prevents RISC-V in the browser from denying the ability to generate code on the fly. Just like, say iOS, it could run in a "W^X" model, that is, writable memory cannot be executed from.

- atomics, again, are part of an extension, the "A" extension. They do not have to be included, and do not make sense IMO in a single-threaded WASM replacement context.

All that said, WASM is well designed. The structured control flow is a bit painful for some producers and the lack of tail recursion elimination is criminal, but running running/JITting RISC-V in the browser would almost certainly add more overhead.

Very interesting, and thanks.

> the running code is not even provided with a way to access itself.

You can do the same thing with some ELF post-processing. I have done this, and used it over several months now. It works just fine, even though there is nothing in the RISC-V standard that explicitly says this must be true.

I asked the GCC people and they consider it a bug if there's any data in the text-segment. So, at leas there is that. Maybe we can call it optional support? :)

I wonder which leads to a faster emulated machine?

Assuming the same implementation effort & skill: WASM, hands down (disclaimer: I have significant RISC-V experience and am an stout advocate, but RISC-V is a poor replacement for WASM).

ADD: a few of the reasons:

- When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary.

- WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.

Your comment made me idly wonder if there's a way to make an ISA which lends itself both to fast (even for low-gate implementations) hardware, and to fast JIT-ing.

I suspect these are conflicting goals but an interesting question. My idle pondering are on ISAs that minimize the challenges in wide superscalar OoOE.

Hm interesting idea... but

- wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem.

- wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that.

So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!

I don't completely understand your second point there, because I'm not necessarily talking about full-system emulation. Just userspace emulation. So, why can't RISC-V be a sandbox? It's just loading a normal ELF into a virtual memory.

The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.

Had an idea of trying to "script" things for games, the idea was to use a the WASM backend of a regular C/C++ compiler to generate code that could be loaded dynamically and share structures (ignoring sandbox for this) so that testing could be done seamlessly, sadly WASM seems to be 32bit for the time being (atleast for Clang, dunno about GCC but that has other issues), also looked at Risc-V and missing export/import tables looks like it could make things far more complicated (might still try using Risc-V though since i'm thinking of generating syscall tables automatically along with Elf-loading)

Sounds awesome. I have some abstractions for making interfacing easier, but I don't have any auto-generated structures.

https://github.com/fwsGonzo/rvscript

I have done that here. Example:

    APICALL(api_math_smoothstep)
    {
        auto [edge0, edge1, x] = machine.sysargs <float, float, float> ();
        x = std::clamp((x - edge0) / (edge1 - edge0), 0.0f, 1.0f);
        machine.cpu.registers().getfl(10).set_float(x * x * (3 - 2 * x));
        return 0;
    }

"machine" is an argument to each system call handler, so you can have multiple machines for many purposes. For example, I suspect you can use a machine as a savegame - because they are serializable.

Oh! So the emulator i was looking at was yours, it looked damn nice for just this task and i guess i know why now :D

Good choice on using var-arg-templates for passing arguments between env and host, i think moving over all scripting bindings to va-templatized bindings is the only sane option for the future (boy have i spent time fighting binding bugs in my days)

The wasm paper covers these issues, and is short and pretty readable:

https://scholar.google.com/scholar?cluster=14979605902538775...

tl;dr security introduces a lot of design constraints that RISC V doesn't have.

section 2.3 on structured control flow:

WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass.

Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons:

section 2.2:

Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory.

However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits.

https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v...

If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement.

Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.

I think if you did RISC-V you would have to convert asm -> wasm so that you could recover the CFI information.

You can send anything down the wire to the wasm env provided

1. It can instantiate wasm itself

2. Your (whatever) to wasm compiler is small enough and outweighs the downsides of on device compilation (to wasm)

You don't have to have the executable code in-memory for RISC-V emulation.

RISC-V is from a significantly differing category. A category for WASM doesn't really exist yet, there is nothing else like this -- a relatively low level bytecode language with high-level features such as nominal types, garbage collection, modules.

IMO such a category existed for quite a long time, JVM and .NET all falls into this category. Yes WASM has its fame for becoming a browser standard, but fundamentally, there is very little difference between WASM and JVM.

JVM has objects as the basic building block. For WASM it's linear memory(ies), so it's lower level, and was created from the start to support languages like C/C++. .NET indeed looks quite similar, given that it supports C++ compilation, tough I'm not familiar enough with the compilation model to draw comparisons.

It has always felt like wasmer was trying to be the NPM of the Wasm world and stake out a defacto monopoly position.

I don't have much data around that, happy to be proven wrong. But we don't need more corporate control over package managers and code-reuse ecosystems.

Wasm offers a unique opportunity to invent and define a new ABI standard, one with (at least minimal) support for the concept of classes. How to make it popular is another question.

Just curious, why do you have such a strong interest in the WASI logo? That seems tangential to wasmer’s concerns.

We use the logo in the wapm website [1].

Using a non-accessible logo that is hard to read provides a non-ideal experience for our visitors, so we can't really use it unless it becomes more polished.

This forced wapm to use a different WASI logo than the "official" one, which is also a non-ideal experience (it adds fragmentation). That's why we believe is just better to push all along a bit more polished logo.

Is such a simple thing to fix, that I'm surprised of the amount of flamewar that it generated.

[1] https://wapm.io/interface/wasi

I don't think anyone believes you "peter"

You are free to believe in what you want, of course

Who is “peter”?

The sockpuppet account this guy uses to astroturf his own projects. Documented elsewhere in this thread.

Oh I just saw it. Wow that’s... strange https://news.ycombinator.com/item?id=12584886

Reply on news.ycombinator.com