IMO this analysis is best done with three groups, not two. People who do well in sports, do well in academics, and third group who does neither. Any analysis that put the middle group to the other will not give right output.
If you are going to blindly follow HN or other site's comments, then it will not help. But as far as giving different perspectives HN and reddit/programming etc are good
That is true, but carrying people around requires a lot of power, nothing that panels put that way can offer. He probably can gain a few minutes of driving by recharging his batteries in several hours of sun on one side (unfortunately making all panels pointed to other directions useless) but I am 100% sure that thing cannot carry people around just with solar power, especially with panels mounted that way. There's not enough data to call it a fake, but surely there's enough data to tell it's not optimal.
As i wrote in another reply: had this kid been a western youtuber, those who are downvoting me would be in line to write my exact words.
To make it even more clear: correcting a technical error does not mean I'm bashing the kid who committed it, and correcting a kid of a certain country doesn't mean I'm bashing that country.
I think the issue is that the vehicle has no more surface area for panels. It couldn't extend them out further as that would make the vehicle more likely to collide with others.
It looks like the roof and sides are covered. I'm building a four wheel drive solar powered farming robot. We use four 800w panels, but on level ground it draws 40 watts at walking speed. I've heard there can be issues if one solar panel is in the shade and others are in the sun, but maybe that can be fixed with proper wiring. Anyway a few panels around the vehicle if properly wired could provide a real boost to the vehicle, even if its not gonna power it up hills for long. The really cool thing about solar vehicles is that in the daytime they are always ready to go. At least that's how our farm robot works. (link in my profile)
Please do your research before you criticize. If you have ever seen a tuk tuk, you would know that the top is a curved artificial leather covering stretched on a iron frame ( https://sc01.alicdn.com/kf/HTB1ChvBPXXXXXbaXVXXq6xXFXXXo.jpg) . If you look at this tuk tuk, you can see the steel mounting frame for the solar panels instead of the usual artificial leather covering. So I am pretty sure that the did install the panels there as well. Also it seems quite simple to induce that being knowledgeable enough to operate a welding plant and hook up solar panels, he would know that the best place for the panels would be at the top. The only problem is that a tuk tuk has around 1.3mx1.7m space at the top. So obviously he needs another place to mount some more panels and the sides would be the next logical choice.
I think low code can really help while doing broader level coding, e.g. service, API, component definitions, and also mapping out communications/ service calls. When doing detailed data manipulations, data mapping can help, but when digging deep, the code is easier. If we can switch and use mixed approches between code and low code, it can improve the productivity in my opinion.
With Choreo, you can write integrations, write and manage APIs, facilitate reuse via a marketplace, and much more.
Three things that sets Choreo apart:
1. Simultaneous low-code and code: Choreo enables you to go from low-code to source code, easily switching back and forth with zero boundaries.
2. Integration and collaboration of effort: Developers simply write code; we’ll do the rest to give you a production-grade deployment including sophisticated build pipelines, autoscaling, high availability, deep observability, performance forecasts, API management, and marketplaces.
3. Lock-in free low-code: It's all available in GitHub because your low-code is actually just code. As a result, you can clone and edit the code anytime. Please note, some of this feature is not available in the first public beta launch.
We are a team known for many open source projects (Apache Axis2, Apache Synapse, WSO2 API Manager, WSO2 ESB, Ballerina) that powers thousands of real-world systems.
We all used to build software by composing libraries and running programs on top of middleware platforms. The world, however, has changed; now we build most software apps by composing APIs together and running them in a container.
Choreo is the result of over five years of work towards building a better software development experience for cloud-focused developers. With Choreo, you can write integrations, write and manage APIs, facilitate reuse via a marketplace, and much more.
We see three things that sets Choreo apart:
1. Simultaneous low-code and code:Choreo enables you to go from low-code to source code, easily switching back and forth with zero boundaries. This is powered by Ballerina - a programming language we have been working on for 5+ years (see https://ballerina.io).
2. Lock-in free low-code: Because your low-code is actually just code, it's all available in GitHub. As a result, you can clone and edit the code anytime. (Some aspects of this feature are not in the first public beta but will be available soon.)
3. Focus on creative development, not building platforms: Developers simply write code; we’ll do the rest to give you a production-grade deployment including sophisticated build pipelines, autoscaling, high availability, deep observability, performance forecasts, API management, and marketplaces.
1) It is mentioned that KNative "deliver a serverless experience to developers on any cloud". How does it work with any cloud? Are you referring to fact that all clouds has k8s? Is it already supported in any cloud or will be supported?
2) If any cloud is supported, does it virtualize services such as storage, queues, API management and Identity
3) Does Knative can seamlessly switch monitoring to what is provided by each cloud.
Above observations are true when the conditions you match are simple. I have observed the same several times that when queries are rather simple you are better off with a single node. What happening is that cost of IO dominates.
There is a clear value in making Stream processors work closer to hardware. That does not mean single node can handle does better under all use cases. When the complexity of queries increases and when queries can be portioned, there are use cases where still distributed setup can do better.
I work on WSO2 Stream Processor, https://wso2.com/analytics ( Opensource, Apache Licensed). We have chosen to support both worlds where SP has an HA mode that can two servers in a Hot-warm mode that do 100K event per the second and give you a two-node deployment. If you want more, SP runs on top of Kafka, scales, and support multi-data center deployments as well. If the user is in doubt, he can start small and later switch to Kafka without changing any code.
