math

https://github.com/infumap/imwebsearch . web-search routes each query to the free quota of one of a number of providers. enough for causal chatting. also has a chunking web-fetch tool that can use a browser relay extension to allow manual handling of captchas.

Saw this last year and liked it so much I added something very similar to it to Infumap (https://github.com/infumap/infumap). You can drag items of arbitrary type onto dates. When more than one item is associated with a date, a numbered button appears; clicking it lets you cycle through them. Items can be pages or links to pages, which when clicked show the page as a popup. Calendar pages in the parent page display as a list of all items scheduled for the next seven days.

I'm not a hearing aid wearer, but I came across https://www.envoymedical.com/ during investment research activities. They seem to have the leading candidate for a fully implantable device. FDA Breakthrough Device designation. I'm interested in the reaction of any hearing aid wearers to what they are developing.

I was not expecting to loose karma for this comment!

I have a couple of years familiarity with SolidJS and thought the two key insights that came to mind from building a large project in it would have positive value.

Apparently not!

I'm using SolidJS for Infumap (https://github.com/infumap/infumap), which is getting pretty big.

Two main comments that come to mind:

Because the state -> DOM mapping is non-trivial for my application, I ended up writing my own virtual DOM diffing code, a primary facet of React. I appreciate the ease of being able to circumvent this where it's not necessary and performance considerations dominate, though I admit i've not felt the need to do it anywhere yet.

The AI training data set for React is much larger. The models seem to do fine with SolidJS, though I suspect there is meaningful benefit to using React from this point of view.

Overall, I'm happy with where I'm at and I prefer the SolidJS way of thinking, though if I were to do it all over again, I'd probably just go with React for the above two reasons.

No, they pass it through successively intensive process conditions, each of which selects for a different plastic type. No need to wash, their process is water based and some contamination from organic material actually helps in saturating the output product.

Results will vary a lot with all the parameters (of which there are many). They don’t disclose all the detail but I know they have done thousands of tests across the parameters space. I know they believe they can process sludge produced from other processes.. The industry generally is very opaque, I think for competitive reasons and also because it’s so complex/nuanced.

Aduro’s tech works with hard to recycle, dirty, mixed plastic. Search for Eric Appelman interview on YouTube for more info. Some of the retail investor coverage is cringeworthy, but my take is the tech is likely as good as described (disclosure: I’m an investor).

Worth noting that Kafka is getting queues: https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A...

Michael Pettis did a great interview recently that covers why growth in China is likely to stall: https://www.youtube.com/watch?v=WE5VczIFGZA

Disturbing observation: 5 years ago, the trends that seemed most important to me were all technical - I really paid no attention to politics. Today, they are mostly geo-political.

it is the WebGPU API (targeting both the web and native)

In the context of a company, the higher up you get (on a technical track), the more you need to operate across different projects, technologies etc. - being able to jump into new things is mandatory/expected. But having deep knowledge in something important to the org gives you a foundation on which to succeed. I would say that specialising perhaps allows you to stand out more efficiently as a lower level IC.

You can tune Kafka down fairly well if you know what you're doing, but it's not optimised for that OOTB. Or just use Confluent Cloud, which is fully managed and scales down as low as you want (costs cents per Gb). Disclosure: work for Confluent.

FWIW, I didn't mean to suggest this was coordinated.

I take the point that my comment here is of low value. I do believe related issues will perhaps turn out to be the most important of my lifetime though, and it's unusually tricky to know how they should be tackled in the public arena. Apologies for me failing to do so appropriately here.

I was affiliated with a company in Singapore which had it's bank account closed, I believe due to FACTA, even though at the time no one involved with the company had ever been to the US and didn't have any ties to the US. It was simply that the size of the account was too small to justify the associated administrative burden. FACTA has impact beyond US citizens - pretty annoying.

best trick i know for this is to have another source of noise that you can tolerate (e.g. a fan). noise cancelling headphones are useful if you sleep on your back...

Would the proposed upcoming changes to the H1-B visa also apply to the E-3 visa (which is closely related) https://www.federalregister.gov/documents/2020/10/08/2020-22...

Kafka also has less moving parts even today before zookeeper removal is complete (2 vs pulsar 3).

At the moment you more or less need to write a DBMS in your app code, but I don't think that's the end state. I think what we're seeing the beginnings of something big - it just might not seem like it yet because it's the v1 / no where near complete version. I think having all your data in a single system (Kafka, KsqlDb, ..) that allows you to work with it in cross paradigm ways will turn out to be very compelling.

even those who aren't..

rust. the ownership system it embodies seems important and I want to understand it deeply. also, the language has momentum.

Australia are introducing very harsh laws targeting climate / environmental activists. He could start by reversing those. E.g. Tasmania, up to 21 year jail term for trespass.

nice! related, we just added similar capability to librdkafka (the C client) to facilitate better integration testing. hopefully we will expose it in the bindings as well at some point.

there are pros and cons to having a C dependency. the main benefit is reliability (get it right once, leverage that across languages). Another benefit is usually performance. The main practical gotcha is that security dependencies are incompatible across platforms, and the best you can do is distribute a number of builds of the C dependency compatible with common platforms (but that is workable).

the go story isn't as bad as you might think. there is a performance hit with the interop, which is of the order of 20% iirc - but throughput still massive, and this is not of practical significance. The Confluent go client (a binding to librdkafka), is used to push much of the volume through two of the largest Kafka installations in existence.

there is a PR open on the confluent go client that will include builds of librdkafka in the github repo, meaning this will 'just work', without the need to install librdkafka separately in most common scenarios.

note: i work on kafka clients (including minor contributions to the confluent go client).

There is currently (much anticipated!) work underway to remove Kafka's Zookeeper dependency: : https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A...

As of v0.9 (about 4 years ago), clients have no use for a direct connection to Zookeeper, and don't maintain one.

Fat clients are more effort to make, which is a significant downside, but this is abstracted from the user and Kafka has critical mass - the client story outside Java is improving dramatically. A fat client allows for optimal availability, throughput, latency.

i think that's the whole point :-)

reminded me of this: https://sivers.org/horses

I've been building something very similar to this ...but also quite different. The details (around usability) have proven very difficult to get right, but I'm really excited by how it's turning out. If you like the core idea as well and would be interested in taking part in a private beta, please send me an email (contact details in my profile). I expect it to be ready for others to try in maybe a few months.

In Blazor, what is sent to the browser is a .NET runtime, then the .net assemblies (which are .NET CIL, not wasm) which the runtime executes. They seem to have this working well, but it's less efficient than, for example, Rust which has no runtime and compiles directly to wasm. C# is very much my goto language, but my eye is currently on Rust in this space because the scenarios where I feel the need for something other than Javascript in the browser are all performance related - i.e. I find React / JSX great for working with the DOM.