Fastly hires entire Wasmtime team from Mozilla(bytecodealliance.org)
bytecodealliance.org
Fastly hires entire Wasmtime team from Mozilla
https://bytecodealliance.org/articles/1-year-update#the-lucet-and-wasmtime-teams-join-forces
152 comments
In my experience, acqui-hires benefit the company far more than the employees who get moved to a different company. The first time I was acquihired, my compensation actually decreased because they kept my base salary and rewrote the bonus structure such that it was impossible to hit previous payouts. Meanwhile, my prior company received a large payment for the transfer of our team.
Ironically, the new company was paying new hires much more. I would have been better off quitting and getting re-hired.
It's better if the employees can negotiate their own way into a different company or companies. No sense in letting the previous company try to cash in on the team on their way out.
Ironically, the new company was paying new hires much more. I would have been better off quitting and getting re-hired.
It's better if the employees can negotiate their own way into a different company or companies. No sense in letting the previous company try to cash in on the team on their way out.
As I see it, there's no requirement for you to take the aqui-hire and it's on you to ensure you are fairly compensated (no one else). So take it, interview, get an outside offer and then quit. Or don't take it, get fired, interview and get an outside offer. An aqui-hire is an option and more options are always good as long as you remember that which option you take it solely up to you.
In practice though if the benefiting company doesn't get their way there are plenty of social and financial penalties they can levy: you won't get any severance, unemployment, or possibly even a referral. You may be ostracized by your former team, mentors, and management. You may find your access rights and equipment revoked before you can collect/remove any personal artifacts from them. You may have less productive conversations with HR/legal afterwards.
Is this a post from the 90s ?
Who is working in a team worth acquihiring and then plans on being on unemployment benefits or has trouble finding a new job ? And I can't remember the last time someone asked about referrals ...
Who is working in a team worth acquihiring and then plans on being on unemployment benefits or has trouble finding a new job ? And I can't remember the last time someone asked about referrals ...
Anecdotally I have 5 years professional experience and every time I'm looking for work people have always asked for at least 1 referral
Same but they didn't care if it was my last job or previous jobs. So as long as you don't burn bridges at every job it doesn't much matter.
I've always been asked, too. And I'll ask as well.
[deleted]
This does seem pretty stupid for a company aqui-hiring a team: hey this is a great team! you know how difficult it is to find great people and then integrate them into a team, let's hire this team en masse! oh and let's treat them like shit when we do so they know who's the boss yeah!
hmm, I guess it's like the last season of Mad Men when McCann consumes SC&P.
hmm, I guess it's like the last season of Mad Men when McCann consumes SC&P.
In my opinion, the acquihire you went through was poorly implemented, and the pay reduction disrespectful.
I think their more general point still stands, though; why would you expect a company trying to "sell" their employees to negotiate in the employees' best interests rather than that of the company itself?
That’s why in football there are 3 parties to a transfer deal: the two clubs and the player’s agent.
In a regular company trying to sell a whole chunk of workers, that should probably be a union. Which is indeed what happens in many European countries when this sort of thing happens.
In a regular company trying to sell a whole chunk of workers, that should probably be a union. Which is indeed what happens in many European countries when this sort of thing happens.
I wouldn't... but I would expect the company trying to "buy" the employees to act at least partly in their interests - otherwise the new employees will soon become ex-employees!
The even more general point is, why would the owners even care about the company rather than themselves?
That's somewhat irrelevant without data on what percentage of acquihires are poorly implemented.
Most aquihires are "take it" or "you're all unemployed." Since some money > no money the aquihire is inherently a benefit to the employee. You still have the option of not taking it and being unemployed. Or taking it and then looking for a new job. But you have more options and more income than if it didn't happen.
An acquihire is also a solid opportunity to end your participation on the team. It's perfectly acceptable to stop working somewhere after only a month because the company got acquired. For similar reasons if the acquiring company presents you with a contract (I think there was an article about this, a noncompete?) they want you to sign as a condition of continued employment, it's very different than if they presented you with that contract as a condition of hiring you normally.
It's nearly always a bad thing for the employees involved. The company that sold you will receive a payment of about half a year of your salary conditional on you staying on for some time post transfer. They will contractually be covered against you quitting and being hired by the company to which you were sold for some period as wel. This puts you at a disadvantage in renegotiation since you already are on contract as far as they are concerned. and asking for a raise, not a fresh recruit negotiating for a starting salary, and your recruiting costs through one of the more expensive channels are not renegotiable. Furthermore. what could have been an obvious great match new employer for you as a free agent has been taken off the table.
If you are ever in a position where you find out your current employer is looking to sell your team, and assuming you have an easy marketable skillet. it might be best to quit ASAP.
If you are ever in a position where you find out your current employer is looking to sell your team, and assuming you have an easy marketable skillet. it might be best to quit ASAP.
Most aquisition I have seen have not been aqui-hire but aqui-fire. A company spins off or sells a chunk to another company that they no longer want but can't afford to lay off. Often to large consultancies etc whom then offer a worse deal or a year later offer a worse deal, and most people leave. Problem solved as no long term union negotiation and long severance pay needed as they left on their own accord... And the consultancy gains some IP and maintenance contracts it can ship off elsewhere.
I've played this game as a curiosity to see how far I could push my luck by offering myself + a relevant and talented friend that I trust. HR was completely unequipped to handle a packaged hire.
In this case the project the devs were previously working on had public visibility, so perhaps they may have been able to negotiate at a higher level.
In this case the project the devs were previously working on had public visibility, so perhaps they may have been able to negotiate at a higher level.
I just did the same thing, and same story played out. HR had no idea what to do.
This actually happened to me and 11 other colleagues back in 2002. I was working for a mid-tier IT consultancy and a bunch of us were working at a utility on a long-term program. Having delivered the initial version of this core system, and still hanging around doing a lot more dev work (many more features and fixes), the utility turned around and did a deal with the consultancy for a dozen of us to "go native", presumably with a suitable financial compensation as well as the promise of a level of continued engagement beyond our transfer.
The surreal part came when the CEO of the consultancy and the CIO and CFO of the utility took the dozen of us out to dinner at a very upmarket restaurant. There were multiple times that night when a few of us felt like chattel. I almost felt like I should be baring my teeth so the new owner could check me out. Very weird, but it was a win-win and I stayed at the utility 7 years doing some really interesting work.
EDITED TO ADD: I should point out that our salaries went up, but for the utility that was still cheaper than the T&M rates they were paying.
The surreal part came when the CEO of the consultancy and the CIO and CFO of the utility took the dozen of us out to dinner at a very upmarket restaurant. There were multiple times that night when a few of us felt like chattel. I almost felt like I should be baring my teeth so the new owner could check me out. Very weird, but it was a win-win and I stayed at the utility 7 years doing some really interesting work.
EDITED TO ADD: I should point out that our salaries went up, but for the utility that was still cheaper than the T&M rates they were paying.
With the sports example... the company "laying off a team" may actually be able to expect a payment in exchange for facilitating the transfer of their well-assembled, functional team to another company. It's entirely possible that wouldn't actually be a bad outcome for everyone involved:
- Source company which is financially strained gets some income in addition to reduced salary expenses.
- Destination company saves on paying other recruiting costs and acquires a pre-assembled team. They're essentially buying a working unit instead of having to build their own.
- Employees avoid the uncertainty of being dropped in the middle of the process (or summarily laid off), assuming the right protections were in place in the agreement.
- Source company which is financially strained gets some income in addition to reduced salary expenses.
- Destination company saves on paying other recruiting costs and acquires a pre-assembled team. They're essentially buying a working unit instead of having to build their own.
- Employees avoid the uncertainty of being dropped in the middle of the process (or summarily laid off), assuming the right protections were in place in the agreement.
- IP disputes are settled in advance; workers can take conpany IP with them
Well that sort of happens in organisations large enough to have 'reorganisations' - which is effectively 'selling' teams (or parts of them) to internal 'buyers', or not finding a 'buyer' and letting them go.
This is the acquihire model. You don't actually have to do the acquihire.
A company could just offer folks jobs directly (CA frowns on companies working to block employee mobility given employers can also fire folks with basically no notice). But it smooths things to wrap it up in an acquihire.
Startups often get offers like this.
Wasn't there a recent case on HN where google or apple after the company rejected the aquihire just offered the positions to staff directly? I think they got sued?
A company could just offer folks jobs directly (CA frowns on companies working to block employee mobility given employers can also fire folks with basically no notice). But it smooths things to wrap it up in an acquihire.
Startups often get offers like this.
Wasn't there a recent case on HN where google or apple after the company rejected the aquihire just offered the positions to staff directly? I think they got sued?
Acquihire was not quite what I was getting at...but more along the lines of companies cooperating to facilitate quasi-free movement of their employees under appropriate conditions especially when it benefits all or the majority of the stakeholders involved, even when it is a single lone employee.
> One might argue there's no advantage to the company laying-off people, but they could save on the severance package, and frankly, two companies entering an understanding like this bodes well on other levels where someone could probably explore a "cross-company" job change with blessings of the employers on both sides of the table.
I really like your idea. It should be one of management ethics: caring for staffs even if you have to say goodbye.
I really like your idea. It should be one of management ethics: caring for staffs even if you have to say goodbye.
There's a lot of various anti-compete reasons why this doesn't happen. In most cases, the people most interested in hiring these people are competitors. I love the idea in theory, but in practice it's way too easy for companies to abuse in ways that are anti-employee.
> This deal has got me thinking... whether a right way to "lay-off" a supremely talented bunch is to actually see if other companies are willing to offer them jobs? Kind of how player transfers happen in Football (soccer).
That's how Gitlab sold Gitter recently.
That's how Gitlab sold Gitter recently.
I don't think cloudflare does WASM @ edge no?
They do. Their Workers product supports JS and WASM (but they seem to be less active when it comes to spec development around it etc)
Haha. If employment was operated like transfers it would be quite interesting.
Same.
I'm out of the loop, I knew they were in trouble but Mozilla is carving up the talent pool?
I really wish we could come up with sustainable models for not for (much) profit tech companies that was beyond our current systems of volunteer and "strategic partnerships" (as in, it's a side effect of a larger business strategy).
Basically in this model, engineers would make maybe 80-160k. No options, no equity, no "going public". No fancy offices or amenities. Just a reasonable pay, a mission for the public good, and sincere dedicated people.
I've looked hard and searched for jobs like that. Maybe wikimedia and internet archive. But yeah, can't get my emails returned so maybe that's not who they are.
I really wish we could come up with sustainable models for not for (much) profit tech companies that was beyond our current systems of volunteer and "strategic partnerships" (as in, it's a side effect of a larger business strategy).
Basically in this model, engineers would make maybe 80-160k. No options, no equity, no "going public". No fancy offices or amenities. Just a reasonable pay, a mission for the public good, and sincere dedicated people.
I've looked hard and searched for jobs like that. Maybe wikimedia and internet archive. But yeah, can't get my emails returned so maybe that's not who they are.
I suspect the few companies like what you describe have a list of applicants longer than the golden gate bridge. So unless you're well known or well connected enough to get their attention they're not interested. Why settle for a random engineer when they can get a world renowned expert with two PhDs and four 5000+ star git repos?
For $160k?
More for the helping the world part of things. Many people will give their all to causes they consider worthy for minimal personal gain. Not like they can't move to a regular corporate job after 10 years when they need to support a family.
such companies with salaries under average market level wont work well due to
1. corporate bureacracy - managers usually are undercompetent and tend to ignore personal matters so team members might bully eachother
2. idealistic people usually have a couple of nuts loose in their heads, combine two or more such persons and you get problem for entire team - linux's coc is one example.
so nearly every org without really focused goal and means of it's following will go the mozilla way, the marissa meyer and such...
it will happen every time if managerial part ignore specifics of programmer work.
[deleted]
Sounds like government work
I have friends at JPL and NASA. You're not that far off.
I want a more general version
I want a more general version
Mozilla already announced their new strategy, they are shifting into a "Product" focused company. Which why is they laid off all these teams. The browser is no longer the focus. Indeed they laid off the Servo team.
The browser is absolutely their focus which is why they laid off the Servo team. Servo is a research project, Gecko/Firefox is their browser. It's also a massive money sink. Firefox itself has zero income and yet keeping up with Google is fantastically expensive (even Microsoft decided to throw in the towel).
So they cut teams that a) weren't directly working on their core browser and b) doesn't make money for spending on their browser.
So they cut teams that a) weren't directly working on their core browser and b) doesn't make money for spending on their browser.
As a Mozilla employee, I can say that this is a fairly accurate assessment.
Except for the part about Firefox not making any money. Firefox is making most of the money.
It gets a fixed amount of money from Google for using them as the default search engine. But what I meant was Firefox has no means to actual generate an income in its own right. Mozilla have tried. The reactions have not been good.
The money from Google is practically a donation at this point. It's not exactly an altruistic one but it's not exactly a pure business transaction either given Firefox's current market share.
The money from Google is practically a donation at this point. It's not exactly an altruistic one but it's not exactly a pure business transaction either given Firefox's current market share.
What will happen to this donation if the outcome of the anti-trust is against Google ?
Is it even possible to donate money to Firefox development and not to greedy CEOs?
You can't donate to Mozilla Corp full stop. Besides which Firefox users are strongly opposed to "nags" in the browser as Mozilla have found. Even wikipedia, with it's massive reach and yearly nags, "only" makes ~$120 million. Firefox could never hope to reach anything like that from donations alone and it needs many times that number to keep pace with Google Chrome's practically unlimited funds.
Send money to employees
> It gets a fixed amount of money from Google for using them as the default search engine
Your first bad assumption is that the amount of money is fixed.
Your first bad assumption is that the amount of money is fixed.
Contradicts their announcement on new product focus https://blog.mozilla.org/blog/2020/08/11/changing-world-chan...
And here is a 2013 post about the "next generation" engine (Servo) https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung...
> So they cut teams that a) weren't directly working on their core browser and b) doesn't make money for spending on their browser.
Exactly, that means they do not see any value in closing the gap with Chrome. Servo was this plan that launched years ago. See this paragraph from the above post from 2013
> Servo is an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web.
Not to mention their threat response team got laid off
https://www.securityweek.com/mozilla-cybersecurity-staff-hit...
And here is a 2013 post about the "next generation" engine (Servo) https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung...
> So they cut teams that a) weren't directly working on their core browser and b) doesn't make money for spending on their browser.
Exactly, that means they do not see any value in closing the gap with Chrome. Servo was this plan that launched years ago. See this paragraph from the above post from 2013
> Servo is an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web.
Not to mention their threat response team got laid off
https://www.securityweek.com/mozilla-cybersecurity-staff-hit...
Several parts of Servo have been incorporated into Firefox (Stylo, Webrender, Pathfinder and more).
I think Servo was branded as a research project pretty early on. That it would replace Firefox wasn't very realistic.
I think Servo was branded as a research project pretty early on. That it would replace Firefox wasn't very realistic.
Yes, however if Servo was stopped early on due to no "ROI" (like it is the case today). Then those very good improvements would have not been made.
Firefox is the reason why Google pours so many millions in Mozilla. Hardly a money sink.
and the Product is whatever they sell Google every couple of years.
Contrary to most comments so far apparently, I'm just happy to see any WASM projects secure corporate backing. I think Ferrous System wrote about it nicely[0], but having people full-time on projects like this has a tremendous positive impact.
Congratulations to the whole Wasmtime team! :)
[0]: https://ferrous-systems.com/blog/knurling-one-month/
Congratulations to the whole Wasmtime team! :)
[0]: https://ferrous-systems.com/blog/knurling-one-month/
Fastly have a great product. I've always liked their support too: when you need to have access to low level APIs like pure VCL you juste have to ask and they provide it, it is deeply powerful.
I think they can make a great impact with these hires.
I think they can make a great impact with these hires.
What is “pure VCL”?
Varnish Configuration Language. Fast.ly’s UI gives direct access to the full (I think?) configuration file to edit in plain text (in addition to its UI tools for doing so).
You don't configure the proxy's middleware, you code and modify their proxy's middleware in Varnish, the language they are written in.
Holy moly! This is pretty amazing. I was playing with terrarium the other day and it looks pretty cool https://wasm.fastlylabs.com/
> Serverless on Fastly’s Edge, powered by Lucet
Looks like that product is in private beta. It'll be interesting to compare and contrast it with Cloudflare Workers. In any case, I'm glad there's going to be some competition in that space.
Looks like that product is in private beta. It'll be interesting to compare and contrast it with Cloudflare Workers. In any case, I'm glad there's going to be some competition in that space.
Cranelift coming along is exciting!
It's good to see Wasm development continuing outside of Mozilla, but it's a shame that Mozilla seems to be going under.
Yeah, it's now clear that Mozilla focus on Wasm is only on the client-side for the browser.
It seems most of the Mozilla people working on Cranelift are no longer employed to work on it.
It seems most of the Mozilla people working on Cranelift are no longer employed to work on it.
[deleted]
[deleted]
[deleted]
wow, that is truly amazing!
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
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
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.
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.
[deleted]
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:
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]
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...
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
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.
> 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.
So the criticism in that paragraph is undeserved, I've removed it for clarity but will leave it here for posterity.
> 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.
>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.
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.
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.
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.
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
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
[deleted]
[deleted]
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.
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.
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.
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!
- 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.
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:
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;
}
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)
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.
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 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.
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...
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.
- 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? :)
> 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.
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.
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.
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.
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.
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.
> 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.
[deleted]
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.
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.
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!
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?
Then why register?
"Our lawyers made us".
Lawyers can't make you do anything. They can advise. They can't act without your consent.
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 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.
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
[deleted]
[deleted]
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
> 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.
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)
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)
[deleted]
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.
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.
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.
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?
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
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...
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.
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.
[deleted]
I will stay pessimistic here.
Wiring VCLs is painful and very limited.
But writing Rust takes CDN support to completely different level. Even if they will introduce other languages i don't understand why anyone would rely on Fastly to run their software. Especially once you realize you need some storage and it will Fastly again.
What I'm taking away from this, and the apparent infighting and legal/cred battles in the WASM scene it had surfaced, is to stay far, far away from WASM. Also, today I learned that staged discussions on HN are a thing, and even a practice so common it's got a nick name of "sock puppet". As if there weren't enough reasons to not follow the path of ever-increasing browser complexity, and fight to keep the web open. Though WASM, for once, wasn't a Google bomb but very much a Mozilla thing, wasn't it? Good riddance!
Sock puppets have been around as long as web forums. The term and practice predates Hacker News.
To clarify one point, "sock puppet" accounts are an internet thing, they're not specific to HN. Usually a sock puppet discussion is one person controlling multiple accounts to make it look like there are people backing up and agreeing with their point.
Yeah, Wikipedia had a page about Wikipedia sockpuppets since 2004[1], 3 years before HN existed. Although I am quite partial to the MC Frontalot lyric about HN sockpuppets[2].
[1] https://en.wikipedia.org/w/index.php?title=Wikipedia:Sockpup...
[2] https://youtu.be/Op1i0B8-dJA?t=57
[1] https://en.wikipedia.org/w/index.php?title=Wikipedia:Sockpup...
[2] https://youtu.be/Op1i0B8-dJA?t=57
I guess what irritates me is not their mere existence, but their acceptance in passing among folks wanting to promote their stuff.
WASM is still catching up with Flash CrossBridge from 2011.
"Unreal Engine 3 Support for Adobe Flash Player - Unreal Tournament 3"
https://www.youtube.com/watch?v=UQiUP2Hd60Y
https://adobe-flash.github.io/crossbridge/
Luckily we are getting our plugins back, even in its present state.
https://platform.uno/
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
And naturally Flash and Java applets,
https://www.leaningtech.com/pages/cheerpxflash.html
https://www.leaningtech.com/pages/cheerpj.html
"Unreal Engine 3 Support for Adobe Flash Player - Unreal Tournament 3"
https://www.youtube.com/watch?v=UQiUP2Hd60Y
https://adobe-flash.github.io/crossbridge/
Luckily we are getting our plugins back, even in its present state.
https://platform.uno/
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
And naturally Flash and Java applets,
https://www.leaningtech.com/pages/cheerpxflash.html
https://www.leaningtech.com/pages/cheerpj.html
This deal has got me thinking... whether a right way to "lay-off" a supremely talented bunch is to actually see if other companies are willing to offer them jobs? Kind of how player transfers happen in Football (soccer).
Either the team goes to the newer company wholesale or you help find your engineers suitable roles elsewhere.
One might argue there's no advantage to the company laying-off people, but they could save on the severance package, and frankly, two companies entering an understanding like this bodes well on other levels where someone could probably explore a "cross-company" job change with blessings of the employers on both sides of the table.
Of course, things like salary negotiations take a hit for the candidate especially, but internal transfers to different teams / location in bigger companies already work this way. May be year-end reviews and code can be shared on a need-to-know basis between the companies with employee consent.
In particular, such arrangements between smaller / crash-strapped companies and bigger / well-funded companies might work out for the good. Then again, you never want the bigger company to start poaching wholesale from the smaller one. May be there's a balance in here somewhere that can be worked out given enough time and data.