Managing state is hard and always has been regardless of the underlying technology.
I have been using Kubernetes for a few years now and whenever I see people putting manual steps they should instead be using an operator. What the author is describing as a problem has a solution (they even added it to their own operator).
Kubernetes has a steep learning curve but if you want to do nontrivial thing like have state than you need to learn nontrivial things like operators.
The default controllers that come with Kubernetes do not cover everything under the sun and they do require extensions via the operator pattern for some tasks.
Comparing different metrics is not valid across all use cases. Counting startup time but excluding development time is disingenuous. Having used both Fortan and Julia the difference between development time is staggering.
Different tools for different uses cases is the best way to put it.
The point is when you have a connection with limited bandwidth. In such cases you can host browsh in the cloud and connect to it with ssh/mosh. You get a much better experience than text based browsers at a limited bandwidth.
It's great for such cases - I use it when hiking / working away from good internet.
Thank you, I just learned about Mosh and it's absolutely awesome! I have to switch VPN regularly in my job and it's a real pain in the ass working with multiple ongoing ssh sessions. No more!
I run into this a lot travelling in places with bad internet and hiking. I just want to check a route or some place and travel bloggers and their bloated ad-riddled popup-covered sites take forever to load.
I mentioned in another thread an alternative browser I've been prototyping to solve this problem. I'd love if you could tell me more about what you need from something like this. All my prototyping so far has been on desktop but the idea in my head has always been for a mobile app since that's often all I have when travelling, but there's no reason for it not to work on desktop too.
As this comment in the thread says, it looks like it uses a lot of constant bandwidth as it's consttantly querying for the latest visuals from the headless FF instance[0]
The article misses an often overlook but important point: burning hydrogen in air produces NOX which can be a more potent greenhouse gas than CO2. The solution to reduce the amount of generated NOX exists but the resultant engine is larger and consumes more fuel for the same power output.
Further, as stated hydrogen is typically produced by steam reforming which generates greenhouse gases. The alternative of using electrolysis requires electricity generated from carbon neutral sources.
Taking all this into account:
- making steel requires electricity, the carbon neutral source can be used here directly;
- land vehicles already have a proven alternative with electric engines;
- naval vehicles do not have the luxury of easily recharging electric batteries.
As a summary I think the solution already exists for steel making and land based transport the problem is widespread adoption and politics rather than technology. Naval based transport can benefit from hydrogen as a fuel source but it comes at the engineering challenge of transport/storage and the associated safety concerns.
The subscription model gives you access to the drafts of the chapters and full book access at 8 months. For $9 at the lowest subscription grade this is $9x8 = $72 which seems like a fair deal to me when going through amazon for similar subject titles.
My experience of speaking with authors who have published books is that most of the money stays with the publisher and not the author which is a real pity. The net effect is the discouragement to write books which is counter to progress.
The subscription model is really interesting to me and I hope it makes a difference to the book publishing paradigm.
I would only buy the book if you put the pdf freely downloadable on your website (I systematically do that to support authors, because I love "dead trees").
In general I find that working with mathematics as auxiliary to any field is hard when you do not get to practice it every day. In these cases I have found the matrix cookbook [1] to be very helpful as it serves as a quick reference.
In essence there are cases outside the well developed uses (CNN, LSTM etc.) such as Neural ODEs where you need to mix different tools (ODE solvers and neural networks) and the ability to do Differentiable Programming is helpful otherwise it is harder the get gradients.
The way I can see it being useful is that it helps speed up development work so we can explore more architectures, again Neural ODEs being a great example.
Differential programming is about building software that is differentiable end-to-end, so that optimal solutions can be calculated with gradient descent.
Probabilistic programming (which is a bit more vague) is about specifying probabilistic models in an elegant and consistent way (which than then be used for training and inference.)
So, you can build some kinds of probabilistic programs with differential programming languages, but not vice versa.
One of my lecturers once gave an anecdotal reductio ad absurdum argument of why it is difficult to reduce our carbon footprint: people are not willing to walk from
the UK to France for a piece of cheese when they can just drive a few minutes to the store.
Transportation makes up 10% of the carbon impact of food at most if I remember correctly. The choice of what one eats is a lot more important. Here are articles you might be interested in?
The example is fundamentally different as physics simulations have closed form solutions or can be numerically approximated for various initial and boundary conditions. Therefore, by definition the generation is not synthetic.
Other examples I could think of fall in the category the top comment is referring to.
No affiliation, just a long term fan after years of frustration with Postman and Insomnia.