Reminds me of a time when i created a library to work with iterators in lisp, inadvertently naming it cl-iterators[0], as far as the naming convention of common lisp libraries went at that time. Some folks(including me!) on reddit had lots of fun with the unfortunate name.
Ephemerality sounds like JIT but for apps. Seems the necessary stuff to run the app will be downloaded dynamically and cached locally to run later. Though, why cant be this done in the current setup? What are the limitations that fuschia overcomes in this regards?
Shameless plug: I had created a similar library[0] for common lisp, though it didn't use conditions and restarts, also lacked a definitive yield construct. It still is profound how a major feature for other programming language is trivial to add to common lisp.
Hmmm, frankly its just a CLOS object, with the defmethods controlling the iteration. I tried to model the object like Python iterators, however the API ended up a bit more like Haskell.
Halt production? It seems these soylent formulations are versioned. So can't they revert back to an older version till they fix the issue? Or its not as simple as this?
Is it the version or the process? This isn't software, you have a lot of mechanisms & parties in play.
The biggest thing at risk here is reputation. Let me draw a comparison: how much worse would it have been for Samsung to just halt production of the Galaxy S7 then to race forward and produce a new, still-exploding version?
>how much worse would it have been for Samsung to just halt production of the Galaxy S7 then to race forward and produce a new, still-exploding version?
Isn't that exactly what happened and it was a huge disaster.
Could be; in both situations there's enough external impact on the entire production process that reverting everything back to normal* still means people get sick.
* even normal could be in doubt. it's entirely possible this happened before and there weren't enough reports to warrant any concern.
they don't know what's causing it. If you just revert the formula, that doesn't mean the ingredient causing the problem has been removed. Contaminated soy protein is contaminated soy protein (for ex). Changing the amount of contaminated soy protein in your drink isn't going to fix anything.
The solution is obviously to create $n$ groups for each newly added ingredient in the previous version, randomly assign customers to a group and ship them a version with one ingredient added, then use R's prop.test to analyze the failure rate of the formulations. /s
I wonder if the HURD guys will finish and when. Can somebody comment on the continued existence of this project even though the ideas propogated by it(microkernels) have been well adopted into the mainstream?
Trying to emulate Mach, which was a dud as a microkernel, didn't help.
QNX is one of the few microkernels to get it right. L4 got stripped down so far that it's just a hypervisor, on which people usually load Linux. L4 took out arbitrary-length message passing in favor of interrupt-like events and shared memory between sender and receiver. This simplifies the kernel, but now it's easier for one side of a sender/receiver to mess up the other, since they share a communications area. The QNX primitive set (MsgSend, MsgReceive, and MsgReply) work well enough in practice to allow full POSIX functionality. Applications can talk to file system servers, network servers, etc. through those primitives. All QNX I/O works that way. You take maybe a 20% performance hit for the extra copying, but you get robustness in exchange.
Most important thing for performance in a microkernel: the CPU dispatcher and the message passing have to be tightly coordinated. You must be able to call another process and get a reply back without trips through the scheduler or a switch to a different CPU. QNX gets this right, because MsgSend is blocking. The sender blocks and the receiver starts without having to schedule. The data being sent is right there in the cache of the CPU, ready for use by the receiver. Good test for a microkernel - put some CPU-intensive jobs in a loop, while also running something that makes short request/reply calls to another process. If the request/reply process stalls out, the microkernel is doing it wrong. If the CPU-bound processes stall out, the microkernel is doing it wrong. Message passing should schedule as smoothly as a subroutine call. If it doesn't, performance under load will suck.
QNX was cautiously courting the open source concept and venturing in the direction of shared source (with some code already available), when BlackBerry bought them and threw all of that out the window.
Biggest yanked opportunity. D:
Now QNX is all-commercial again, with source only available under a license. And Photon is gone, too: no more self-hosting.
I wish BB would(/could?) do the webOS thing with QNX. That would be amazing. The community would absolutely get Photon up and running again, it would be an alternative to Linux and BSD.
I know. QNX the OS was great. QNX the company has been a huge pain to deal with for more than a decade. They had a tough problem, though. Who else sold a desktop OS for real money any more? Unlike Microsoft and Apple, they had no other revenue stream. Still, until about 2005, QNX was considered a target which UNIX-like software should support. There was an early version of Firefox (called Firebird) for it, all the command-line GNU tools were available, and the Eclipse IDE worked fine. For three years, while I was working on a DARPA Grand Challenge vehicle, I ran QNX on the desktop.
Photon, the GUI, probably had the sanest internals of any major GUI system.
Dan Dodge, who designed much of QNX, was CEO of QNX, and he retired from QNX/Blackberry to go work for Apple. Apple might end up doing something in this direction. But if they do, they'll never let the internals out.
I'm curious what was wrong with QNX the company, in terms of the practical ramifications of what you're describing.
I assume you were using QNX for the GC vehicle compo because of its RTOS qualities? In any case, that's awesome.
I thought Photon was pretty cool too, at least from a "oh hey these screenshots look awesome" perspective. I vaguely recall running it in a VM, once, so long ago I only hazily remember poking around the sidebar. Sadly it'll be somewhat challenging to do further academic research on that subject now, I wish the educational/noncommercial free options still existed there.
If anyone's looking for a student friendly version on microkernels and specifically Send/Receive/Reply, take a look at the resources for UWaterloo's CS452 here. [1]
That course features implementation of microkernels based on QNX from scratch to drive trains around a track, should be straightforward to implement on a Raspberri Pi or a Pandaboard/Beagleboard. The course uses a TS7200 which is an older ARM chip.
Back in the mid-90s I had some friends who worked at a company that sold commercial X-Window servers. Their fastest X server ran under QNX. That either says something about how fast QNX was, or just how bad Unix was at the time.
Your response sounds more like the religious groups howling "world will end" whenever a new scientific progress is made. Internet survived because of its obvious commercial value. Google and Facebook are doing nothing new but making their ends meet.
Neither of those points are much of a defense. By that same token, one could defend e.g. Microsoft's aggressive misuse of their market dominance in the 90's: 'Windows survived because of its obvious value; MS is just making ends meet.'
It can still be a good or a bad thing for the web as a platform.
Hopefully adoption is slow enough that the default behavior of any "blessed" libraries like this WP plugin can be encouraged to be less ... well, not evil, of course ... but really, why does that toolbar and 'X' need to be there? Browsers have a back button.
My take is simply that this is not a good look for Google, and hopefully they realize that. The article featuring the WP plugin, and these discussions on HN that give a lot of attention to the carousel, and how it competes with non-AMP results, don't build goodwill for the project.
[0] https://github.com/ykm/critter