Yes, I'm talking about clause 2 of the original "4-clause" BSD license. Advertising is clause 3 of the original BSD license. The newer "modified"/"3-clause" license deletes the original clause 3, but clause 2 remains unchanged.
Signature wouldn't mean anything if there was no warranty. In which case warranty is what they sell and the signature is just a minor technical detail. And selling warranty on software is already a thing.
Why wouldn't WASM implementations do native compilation? It's the norm for most modern language implementations nowadays, anything else would be silly.
Many languages that compile to native are rolling out WASM support, or have it in their roadmaps, but there are many more architectures and formats that you have to handle in native land.
I guess theoretically, if we agreed to support the main desktop and mobile/tablet OS’s and chip architectures, and then got everyone to use a standard compiler and IL format (LLVM maybe?) then you might get some of the way, but that would be a lot of work (cool if it happened though...)
The IL format is WASM, it's already here. When the browser gets WASM, it's free to interpret it or compile it to native code. AFAIK, it is already getting compiled to native, and I'm sure we'll see some awesome JITs coming to WASM.
The problem right now with warm
WASM is lack of features (e.g. you can't do threading), though those are getting sorted.
Targeting multiple architectures is a solved problem, as you said with LLVM. I don't know if that's how WASM is currently implemented, as a LLVM front-end, but I'm pretty sure most implementations in fact are proper native compiled, or they intend to be. As I said it would be silly to do it any other way.
> At this point such a contraption would be less painful than some of Apple's recent transitions (e.g. from PPC to x86).
I find that hard to believe. Apple only had to build emulators for their ISA changes, just translating instruction set into another. Doesn't sound painful at all. WINE on the other hand has good reasons for pointing out that it's not an emulator.
WINE runs most applications extremely well. With actual backing from a MegaCo, especially the MegaCo that owns all of the IP around Windows, I have no doubt that a year of work would round out the rough edges such that compatibility differences don't exceed what would be expected between major versions of Microsoft Windows.
I can't help but think that browser vendors could have at least made an effort to make client certs and Kerberos authentication more user-friendly on the web. Perhaps not so useful for private consumers, but it would sure come in handy in enterprise.
Is there a good place to go for the current state of client certificates?
I've heard that there was an issue where other websites could see the certificate, so there were privacy problems with having them installed.
It seems like something that would have been fixed, but it's hard to search for. Server certificates are so much more common. They end up taking over all the search results.
The performance tradeoffs are quite different, because this library uses the unmodified Smalltalk virtual machine that underlies Squeak. I would guess spawning is quite fast, because it is more-or-less just a few object allocations (plus a couple of linked list manipulations), but I have not made any serious measurements of performance of the system. Also, the Squeak VM has (IIRC) limited ability to make use of true parallelism.
A second tradeoff is in terms of flexibility: this is an ordinary (and fairly small) Smalltalk library, and so can be quickly sculpted into variations on the theme of Actors. Making similar modifications to Erlang would be very expensive. I aim to use this library as a foundation for experimenting with Syndicate-style ideas (https://syndicate-lang.org/) in a pervasively OO setting.
Syndicate seems very cool! Do you know if it's used by anyone or is it more of a research project at this stage? Am I right that the pattern seems very similar to re-frame [0] in Clojurescript? It seems like it might be an excellent way to develop web apps, especially since I see there's a javascript version as well.
It is still a research project, though I am working on a new implementation that brings it up to production standards.
Re-frame does look similar, but Syndicate is general in the same way that the Actor model is general; DOM support and other "I/O devices" are bolt-on drivers, not built in to the core.
Syndicate does make a nice way to develop web apps; for example, the whatsapp-like chat app here https://github.com/tonyg/syndicate/tree/master/examples/webc... shows a few of the ideas, though it's only prototype/experimental quality. The new implementation ought to be suitable for making such applications "for real". See also the handful of in-browser demos, which naturally focus on web-ish things: http://syndicate-lang.org/examples/.
The Racket implementation has been used to implement not only the server side of the webchat app, but also a TCP/IP stack [1], an IRC server [2], and a side-scrolling platform game [3].
I'm afraid that there's very little documentation available (it is still a research project, after all!). You can read more about the ideas behind it here, though: http://syndicate-lang.org/tonyg-dissertation/.
> Also, the Squeak VM has (IIRC) limited ability to make use of true parallelism.
The Squeak VM is single-threaded, OS-wise, so it's just green threads. I don't even honestly remember to what extent its green threads are preemptive; I do remember that anything hitting C would pause other threads until it concluded, though, which made it really important to make sure that e.g. your database driver was 100% Smalltalk so it wouldn't lock the VM constantly.
Kinda. The VM executes Smalltalk on a single thread (interpreting or running JIT-compiled code). At the Smalltalk level, the unit of concurrency is called a "process". Processes are assigned priorities. Processes with higher priority preempt processes of lower priority, but processes of the same priority are cooperative.
So yes, "green threads". However, the VM does run multiple OS threads. When a Smalltalk process does IO, that gets performed on a different OS thread by the VM and the calling Smalltalk process is blocked, which lets another Smalltalk process get scheduled.
You could do that trick for things like calling ODBC or computationally expensive C code, but if you just call single-threaded C code directly, yeah, it'll block all Smalltalk processes until it returns.
Would you prefer the alternative, "Sorry about the crash. Allow us to run our mouths about things we are not competent to comment on given the presently available information"?
More like “We are available to answer technical questions about this model of aircraft, however specific questions about the crash itself should be directed to the appropriate authority”.
Their sales organisation is always available to answer technical questions about the model of aircraft, but nothing of that is relevant to any of the journalists who might enquire in light of the crash, unless they are trying to play armchair accident investigators.
