One reason the quality of service at UPS has traditionally been stronger than at FedEx is that most UPS drivers are full-time employees rather than contractors or temporary staff. Many UPS drivers are able to earn a good living, often better than their peers at other companies including FedEx [0][1]. By contrast, some logistics companies pursue cost savings by classifying drivers as self-employed contractors, thereby avoiding social security contributions and other employee benefits. UPS’s approach reflects the vision of its founders, who believed a company cannot thrive unless it takes care of its employees.
However, the financial markets, which tend to reward short-term returns and a “winner-takes-all” mindset, have often penalized UPS for this philosophy. In recent years, to satisfy investor demands, UPS management has also turned toward cost-cutting measures. This shift coincided with leadership changes, as the current CEO came from outside the company. External leaders often emphasize sales and marketing over operations, and UPS has followed this trend. As a result, UPS, FedEx, and Amazon are now competing in a cost-reduction race, prioritizing sales growth while reducing operational staff—changes that inevitably affect service quality.
One critical element still missing from the broader logistics landscape is a truly integrated, multi-modal framework that seamlessly combines air, road, rail, and water transport to meet diverse customer needs. While rail may be less applicable in the U.S., it plays a vital role in Europe, China, Japan, and India and could be leveraged more effectively. Perhaps modern logistics theory should evolve to reflect this more holistic, global perspective.
Rail is more applicable in the U.S. than in any of those other countries. We are the world leader in freight rail volume. Obviously it's not generally used for overnight delivery.
As for financial markets, your blame is misplaced. This industry is tremendously price sensitive and it seems many customers are willing to accept somewhat worse reliability and service quality in exchange for lower prices. It's similar to passenger airlines in that regard.
Our UPS driver lives in our neighborhood. It’s a middle class suburban neighborhood, a nice, quiet place to live. That he can afford to live here is great. Needless to say, we get excellent UPS service. Very nice guy, too.
UPS is pretty close to this. UPS Ground will usually load stuff onto multi-modal containers and ship via rail where practical. Fedex does for east->west coast, but they seem to do alot of relayed truck shipping.
Rail is almost always cheaper, and has mostly displaced long haul trucking.
The missing link is water, and the Jones Act, which was specifically intended to destroy intra-US shipping in favor of trucking, has been incredibly successful in doing just that.
I have used clap to build perspt (https://github.com/eonseed/perspt). The project has extensive documentation on how it was built, as we did it as a learning exercise.
Aspirationally, Ember aims to be for Networks of Networks (NONs) and Compound AI Systems what PyTorch and XLA are for Neural Networks (NNs). It is a compositional framework that offers both eager execution and graph-based optimization. Ember empowers users to build complex NONs while supporting automatic parallelization and system-level optimizations.
The long-term vision for Ember is to enable the development of compound AI systems composed of millions—or even billions—of inference calls. Surprisingly simple patterns, such as best-of-N graphs, verifier-prover architectures, and ensemble models with voting-based aggregation, perform remarkably well across a wide range of scenarios.
Design Philosophy
Ember is built on these foundational principles:
Composability First: The ability to combine, chain, and nest components (e.g. Operator components) is central to Ember's design
Type Safety: Comprehensive type annotations ensure robustness and IDE support
Testability: Components are designed with SOLID principles in mind, for easy isolation and testing
Scalability: support for Parallel execution is built-in at the framework's core. This is more Tensorflow/JAX, than classic Torch spiritually
Extensibility: Registry-based design makes it simple to add new components
Skeurmophism: APIs follow familiar patterns from PyTorch/JAX, to somewhat control the learning curve
Simple-over-easy: Minimal "magic" and a focus on explicitness
Diffuse thousands of frames at full fps-30 with 13B models using 6GB laptop GPU memory.
Finetune 13B video model at batch size 64 on a single 8xA100/H100 node for personal/lab experiments.
Personal RTX 4090 generates at speed 2.5 seconds/frame (unoptimized) or 1.5 seconds/frame (teacache).
No timestep distillation.
Video diffusion, but feels like image diffusion.
For me this predictions are kind of being aware of how progress can happen based on history, but this will not lead to any breakthrough. I am not in the camp of being skeptic so I still like the hype cycle, they create an environment for people to break the boundaries and sometimes help untested ideas and things to be explored. This might not have happen if there is no hype cycle. I am in the camp of people who are positive as George Bernard Shaw in his 2 quotes:
1. A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing.
2. The reasonable person adapts themselves to the world: the unreasonable one persists in trying to adapt the world to themself. Therefore all progress depends on the unreasonable person. (Changed man to person as I feel it should be gender neutral)
In hindsight when we look back, everything looks like we anticipated, so predictions are no different some pans out some doesn't. My feeling after reading prediction scorecard is that you need a right balance between risk averse (who are either doubtful or do not have faith things will happen quickly enough) and risk takers (one who is extremely positive) for anything good to happen. Both help humanity to move forward and are necessary part of nature.
It is possible AGI might replace humans in a short term and then new kind of work emerges and humans again find something different. There is always a disruption with new changes and some survive and some can't, even if nothing much happens its worth trying as said in quote 1.
How does it compare with MiniCPM-Llama3-V 2.5 [0]? Based on what I see it seems much better than Llama 3-V on the benchmarks. Also it can directly be tried on Huggingface Spaces to check the performance [1]. It has the dataset, code and fine-tuning details with screenshots of it running on Xiaomi 14 pro. It has strong OCR performance and supports 30+ languages.
Woah, this actually did quite well on table data extraction. I wonder how this could be used for long documents. Maybe paired with some kind of hybrid rag approach.
This is good as a learning exercise and may be result in something useful in future. So for sake of learning and advancement good. As far as claims to replace coconut harvesters, a bit of a stretch to probably attract funding with marketing.
Why not built a mechanical crane with a platform to help the worker to do better job with safety at heights to harvest a coconut and than apply the same for multiple tasks like repairing street lights. Cleaning the building facades and homes, cleaning and arranging work at heights. I believe existing technology can do it.
There wouldn't be much space for a crane to move around the trees which would be spaced around 20 feet each I guess. Even a small crane takes up lot of real estate and also crush everything under its weight.
You could probably use a scissor lift; but it's pretty expensive; someone said the trees are 15m, a new scissor lift that goes that high is in the neighborhood of $40k USD, in the US. Most likely more expensive in India.
That’s where the innovation comes up, use materials and structure to bring down the costs. Even if initially it costs higher, it can pay back by it’s multi-use, maintenance, energy efficiency by using mechanical energy applied by human muscle with creative use of hydraulics and mechanical designs.
Usually multi-purpose robots cost way higher and requires more maintenance and costs. Given the average labour costs in India with over 10% unemployment in urban areas and much higher in rural areas created by economic mismanagement for second term by the current government. I believe human labour is more versatile and cheaper, if supported by right amount of technology in India. It’s crucial for its development.
Along those lines, seems you could design a far simpler, non-electric frame that could be rolled up a trunk with a mechanical cable/waldo cutter for the coconuts.
Yes agree with you there are more than one solution, crane was just one thought. This is thinking out of the box and a cornerstone of innovation. My concern with robotics is sometimes it's much easier to use humans and with application of sufficient amount of technology can be much better. In some cases robots are essential where humans are too difficult to operate. So we need both, but in this specific article they mentioned coconut harvester in India and here there isn't a need for this robot except as learning exercise.
You would do better to come up with innovative new jobs for humans to do. It's easier to come up with a new service jobs than it is new materials to build cranes with
Humans can always invent new forms of labor. Limited only by imagination and opportunity. We should be automating everything we can while actively creating new categories of employment for every person
Just be careful when you use minIO, as it does not support all of the S3 API's. The maintainer of the project will close the tickets for errors when using S3 libraries and ask to write custom code specific for minIO which works well in amazon S3 [1].
So if your company is ready to invest in MinIO without S3 compatibility it's a nice software, and my kudos to the team who took the efforts to build it. It's just that it's not fully S3 compatible and MinIO buckets do not behave the same as S3 buckets.
I have not yet seen a storage system that is actually 100% S3 compatible. Either functionality is missing, and/or there are corner cases where the behavior is just slightly different. It is also a complicated API, that often looks like it is a reflection of some internal engineering choices that were made (e.g. the object metadata structure AWS uses probably is the reason why the list call you mentioned behaves the way it does on AWS S3)
However, in this case, MinIO makes the deliberate choice to deviate from AWS S3 behavior, on a very common call (listing objects). I do agree that this has the risk to break applications in non-obvious ways, e.g. the call succeeds, bu t your application behavior differs, compared to running against AWS S3, due to the missing directory entry.
I also find their argumentation in the ticket a bit worrisome, calling the AWS S3 behavior a "blunder". I saw the same hubris when looking at their data path, where they choose to ignore battle-tested approaches like Paxos / Raft for distributed coordination, and instead build their own distributed lock algorithm and implementation: it does not seem to persist state, so resilience to power failure and server/process crashes might not be what you expect.
That's really bad. Their marketing says upfront that they are designed for S3 API. If they don't strive for maximum compatibility, then their value prop goes out of the window. I was wondering if I should use minio as a compat layer to be able to use other tools that integrate with S3, what you pointed out probably saved me lots of problem investigation time on the future.
We’re using minio using Amazon’s own S3 SDK, and while they don’t support the latest S3 protocol version, it’s definitely not as bad as you say it is. We had more problems with Google Cloud Storage’s S3 API than with Minio’s (I believe there was something related to listing directories with their API as well, but it’s returning a flat out error instead).
The key thing to note is that it’s probably not fully compatible, but it’s definitely compatible enough for many use cases.
I can also see in the issue you reported that you changed the title of the issue from "Minio is not fully S3 compatible" to "Minio is not S3 compatible", which strikes me as you having some personal beef with them.
There isn't any personal beef, I just take objections to the marekting line The defacto standard for Amazon S3 compatibility.
In my view it's misleading as minIO is not a drop-in replacement for S3 API based applications. My team spend significant efforts to diagnose and find the error, as I believed in this line and asked them to retry different ways by changing code again and again, even though code was working fine with Amazon S3.
I changed the title so that it can warn others, to not go through the same shooting the foot believing MinIO is a drop in replacement for Amazon S3 based applications. If you read the thread you can notice there isn't any plan to support posix like folder API in minIO which is supported in Amazon S3.
Of course, but marketing is marketing; if you blindly believe marketing headlines before doing your due diligence, I'm sorry to say, but it's a bit naive. If you look at pretty much any protocol out there that's implemented by multiple vendors, there are all small nuances and incompatibilities. Even extremely detailed specified protocols have incompatibilities; S3 not having a formal specification should make you expect even worse.
If you look at S3 implementations from the various clouds and NAS appliances and whatnot, you'll see that none of them is a 1:1 compatibilite with each other.
If you wanted to warn others that, instead of Minio not providing "full" S3 compatibility, but Minio does not provide S3 compatibility at all (which is what the title edit suggests), then I believe you are mistaken. Minio definitely provides S3 compatibility, all the main tools and SDKs can talk perfectly with Minio, it's just that there are different implementation details around the edges.
I didn't believe it blindly and that's the reason there is a ticket, after thorough investigation of the error in code as well as self-hosted instance configuration and log file analysis.
Also to make sure others do not need to go through the same long process of debugging, try to request the project maintainers to change this marketing claim as evident in the ticket. Please check the ticket and see for yourself. I did it to make sure others facing the same problem can see it before spending too much efforts to debug.
I can see the amount of work minIO team has put in this project and again kudos to the team. Open source is hard and requires a lot of commitment.
This is how open source works, you give back to community in the form of feedback, documentation, issues and if capable in code.
However, the financial markets, which tend to reward short-term returns and a “winner-takes-all” mindset, have often penalized UPS for this philosophy. In recent years, to satisfy investor demands, UPS management has also turned toward cost-cutting measures. This shift coincided with leadership changes, as the current CEO came from outside the company. External leaders often emphasize sales and marketing over operations, and UPS has followed this trend. As a result, UPS, FedEx, and Amazon are now competing in a cost-reduction race, prioritizing sales growth while reducing operational staff—changes that inevitably affect service quality.
One critical element still missing from the broader logistics landscape is a truly integrated, multi-modal framework that seamlessly combines air, road, rail, and water transport to meet diverse customer needs. While rail may be less applicable in the U.S., it plays a vital role in Europe, China, Japan, and India and could be leveraged more effectively. Perhaps modern logistics theory should evolve to reflect this more holistic, global perspective.
[0] https://www.cnbc.com/2023/08/18/ups-drivers-can-earn-as-much...
[1] https://www.cbsnews.com/news/ups-drivers-170000-pay-benefits...