noogle

One thing opposition to any chemical electricity storage (hydrogen and other fuels) doesn't answer is: _how to transfer electricity across distances?_

HVDC are typically presented as the solution, but even if technically possible, they do not seem to actually materialize. Constant cooperation and reliance between countries for their energy seems like a bad idea in 2023. There are numerous solar project plans stuck because of lack of such transmission lines.

We did not start our current energy infrastructure with expensive pipelines. We started with batched shipments (tankers), and when supply and demand were stable enough we built a gas pipeline. Not sure why electricity requires the optimal solution or nothing.

Python sometimes feel like being stuck in a local-maximum: the network effect is real, but there are so many downsides to the platform itself, and the "two-languages" paradigm renders the computational code obscure and undebuggable.

But gas is used also in the summer. And energy is not only electricity - heating is currently done mostly by natural gas, and is often absent from those calculations.

Efficiency is irrelevant. The only thing that matter is cost and feasibility. The cost of energy from solar is ~$0.02/kwh and sometimes even $0.00/kwh (when the grid curtails production). Even with 30% efficiency each kwh retrieved from storage will cost a record-low of $0.06/kwh (3-10 times lower than the consumer price).

The biggest factor here is the capex and ease-of-use of the equipment. Not the energy input cost.

This will last less than a day.

What to do in the winter? If the answer is "use the grid", then we just kick the can to someone else, who will probably use fossil fuels to provide the energy. The basic problem remains - solar/wind are intermittent and fluctuating.

That makes sense. I am still trying to understand why does it differ between a monolith and microservices. The app in the monolith can make the call to non-critical functionalities time-limited and fault-tolerant, just like a network call has a time-out and can return nothing (in a simplified manner, it can wrap that call with a timer and an exception handler).

I agree that microservices are suitable for large organization, where the organization practically has multiple products (which could be purchased from a vendor or sold to another company).

How so? If functionality A is critical to functionality B, how will wrapping it in an HTTP call (microservices) reduce the damage from breaking functionality A?

I can see an advantage regarding resource hogging, but the flip side is the extra point of failure of network calls in microservices.

Not saying which is better, but deployment is orthogonal to logical dependence and correctness.

False dichotomy. The alternative to AWS is not building your own data center. It's renting bare-metal servers from Hetzner/DigitalOcean.

Zero hardware headaches with x5-10 lower cost.

AFAIK the Chevy Bolt does not support fast charging (like Tesla or Hyundai Ioniq). This makes it a different product to an ICE with respect to mobility.

My ICE vehicle averages 30 mpg. We drive ~12K miles/year. At $3.5/gallon, fuel will cost 12000/303.5 = $1,400/year.

An EV can average 4 miles/kwh. Let's say I go on 4 road trips each 500 miles (charging at $0.35/kwh), and other times I charge at home where I pay $0.15/kwh. This yields $570/year, so savings of $830/year.

My ICE was purchased new with a 10-year warranty, and so far has been very reliable (fortunately). Maintenance involved oil changes and brakes, averaging $120/year. But EV will have more frequent tire replacements and higher insurance premiums, so let's call it a wash.

My ICE costs now ~$20K new. An EV with the same mobility* (500 miles of range with a reliable refueling network) is either the expensive Teslas or Lucid Air, costing $60-100K more. Even the cheapest Tesla, the Model 3 will cost ~$40K for the long range.

Even if the EV charged for free, it will take decades to recoup the upfront purchase price. Even for the cheapest EV, which does not provide the same mobility, it will take ~10 years.

Depreciation could differ, but since I will always need a car, it doesn't matter - any money I pay for a car will always be locked in it so not usable for other things.

One problem emerging with EV, at least in the US, is that they don't seem to be economically sustainable at a price affordable by the middle-class. Useful vehicles cost >$50K, and a reliable fast-charging network seems to be feasible only as a loss-leader for a high-margin luxury manufacturer (Tesla).

No fuel savings in the world can justify paying extra $20K for a car.

But Google search results ARE not satisfactory. The existence of Q&A forums in the age when information is broadly online (and thus is accessible to Google) indicates a need that is not answered by Google.

Google's algorithm may be the best out there, but it still falls short of what is needed. Anecdotally, I often find it fails to conduct word-sense disambiguation, handle negation or answer edge case. My general impression is that Google's algorithm focuses on topical similarity (pages that talk about the query's topic) rather than answering the query.

Broadly (and of course there are a lot of nuances), studies do not show substantial effect[0], which is a failure of the software considering the promise and the resources invested in this transition. Tens of billions of dollars invested in the transition, which could be used for other interventions.

The broad economy is different from pure-software companies. Software can eventually only manage information - but many businesses eventually operate on physical things, where people matter much more than software.

0. https://pubmed.ncbi.nlm.nih.gov/33441368/

So it's all about actual numbers (supply and demand curve). The case of energy (and other industries like transportation and construction) shows that this supply-demand curve be weak enough to lower employee salary. Is there any argument that software won't behave similarly?

Speaking about productivity, software is far from a guarantee of increased productivity - see the case of EHR in hospitals.

Are all companies energy companies?

While that statement broadly applies to white-collar and services, what percentage of COGS is software in manufacturing?

Is it 90%? 50%? or maybe only 5%?

Software is useful. That doesn't make it important enough to command high pay in a shrinking economy.

Yet those measures are being circumvented, because physically you can fill the cartridge, and legally, because this physical ability requires the manufacturer to take intrusive measures which are blocked by courts/legislators.

It's hard to force the consumer to not use their product. Conversely, it's hard to force the operator of a fast charger networks to do something. We can see other BEV manufacturer following Tesla's method (e.g. Rivian) setting up their own charger network. It's not a desirable future for such important market like transportation.

Batteries needed electric vehicles are still expensive and seem to essentially be the bottleneck for mass change to EV.

The infrastructure needed to support battery electric vehicles seem to be expensive/complex to run sufficiently well in practice. In the US Tesla's supercharger network is often cited as a moat against other manufacturers. It's not even building the chargers - it's maintenance and compatibility. Charger network are a losing operation, but they are critical for adoption. Tesla affords this via huge margins, but that won't work for the rest of the market outside of the luxury segment.

Could it be that the BEV market (in the US at least) lends itself to monopolization? If so, hydrogen can make sense as a technology that does not rely on losing charger network to operate (just like no car manufacturer needs to subsidize fuel stations).

This has been debated at length at the past, so I'll pass on that discussion.

What about maintenance of the physical structure? PV panels have no moving parts but:

1. The inverter and other electrical systems do fail (surprisingly frequently).

2. Solar is very spread-out: maintaining a geographically large facility is not trivial (vegetation, water drainage, cables etc.)

3. Batteries also require maintenance, and are an inherent part of any independent PV installation (if the site relies on the grid, it is no longer independent).

> It's comparable to notions that fossil-fueled global warming could be fixed by parking a giant sunshade out at Lagrange 1.

Why can't it work? Critics of this idea often cite cost or unintended consequences, but not ineffectiveness at mitigating the temperature rise (ocean acidification etc. are a different issue).

Then the GP suggestion seems to have a role again - if net zero emissions is not enough, carbon capturing is needed to mitigate previous emissions.

The two are not mutually exclusive.

And the biggest push to invest in re-inventing a software stack is a legal ban on access to the existing software.

If previously building a separate CUDA-like framework competed against paying a bit more to Nvidia, now this decision is infinitely simpler, since using Nvidia products is just out of the question.

I actually built a similar solution supporting similar operations (including filtering by meta-data) using open-source libraries. Took me about 2 weeks net.

I can see a clientele for such database (people who want a turnkey solution), but honestly it looks like an attempt to use a dev-ops solution to address deeper issues with problem formulation: e.g.

1. Is there really a need to search all items in the database? can subsampling make simple similarity comparison feasible?

2. Do the embeddings really need to have that many dimensions? Can we reduce their dimensionality and fit them in RAM?

3. Is embedding accurate enough compared to pairwise comparison? Can we formulate the problem to make the latter feasible?

I also could not find any explanation of the underlying algorithms, especially around meta-data filtering, which is not solved by FAISS as well as their accuracy. (happy to hear otherwise)

CPU factories seem to cost hundreds of billions of dollars - beyond the capabilities of most nation-states. I wonder if this will cause a trend towards reducing requirements (e.g. pushing important infrastructure to rely on simpler chips) as keeping up with the technology will drain a country's resources.

Is this about CPUs or all electronics?

Computer chips are in general a reliable hardware, and top-of-the-line CPUs are in general way more powerful than needed, so there is no need for cutting-edge manufacturing and also an embargo won't halt existing activities.

Simpler/embedded processors seem to be a generic product that can be manufactured by many countries, hindering embargo efforts.

Are chips more critical for a country than e.g. food? because many countries are not nutritionally self-sufficient.

Makes sense, though 15 different languages?

I am not privy to the details of the case, but a rule-of-thumb I heard once is that if it's far enough from your core, a SaaS can be used (obviating the whole question), and if it's part of the core, start by developing it as a separate functionality before moving it to another service.

> good and easier way to deploying 10-15 services

Why are so many micro-services needed? Could the software be deployed in a more concise manner?

Not getting into the whole monolith-vs-services arguments. In both cases, complexity of deployment is part of the cost of each option.

You can already do that by using the pl/python or pl/java extensions with the right environment. However, the interface between SQL and model inference is typically narrow enough that IMO it's better to: read from Postgres --> process in an external Python/Java process --> persist to Postgres.

Maybe enhance this with a FDW to an external inference process to allow triggering of inference from Postgresql itself.

Ranking results by author's credibility (site karma) could help, at least for the time being.

It's not that the comments are plain ads (these will be easy for the reader to discern), it's dishonest product reviews. It's an unsolved problem in e-commerce websites and even in real life.

Using Stripe etc. adds another point of failure.

But yes, the fact that essentially all payments are bottlenecked through two vendors with no legal supervision is quite troubling.

Maybe we should form a co-operative of payment recipients? It doesn't need to operate anything, but rather be a "suicide pact" that will extoll a high price from payment processors if they try to unfairly ban a business. Some sort of a smart contract could guarantee fair enforcement.

> in places where the air is wet, it rains, and you don't need it.

- Rain water collected in ponds/rivers may be contaminated/infested.

- Lack of fresh water in the ocean/islands is also an issue.

The two things that are available almost everywhere are air and sun.