vikrantrathore

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.

[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...

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

FramePack

    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.

Website link: https://lllyasviel.github.io/frame_pack_gitpage/

Archive link

https://archive.ph/1QXSB

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)

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.

[0] https://github.com/OpenBMB/MiniCPM-V

[1] https://huggingface.co/spaces/openbmb/MiniCPM-Llama3-V-2_5

There are enough papers in the issue check [1] [2]. This is one of the links to the article in volume 7 [3], you can download the article PDF [4].

[1] https://programming-journal.org/2017/1/issue1/

[2] https://programming-journal.org/2023/7/issue1/

[3] https://programming-journal.org/2023/7/1/

[4] https://arxiv.org/pdf/2206.14606v1

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.

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.

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.

marketing is marketing

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.

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.

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.

[1] https://github.com/minio/minio/issues/10160

Might be true, but don’t see any open source work from Amazon in public domain which shows they built their own libraries from scratch to manage Xen and cloud management in early years from 2008.

Indeed it’s 2020 and yet to see any major open source work from Amazon (which has benefited a lot from open source itself using Perl, CPAN, C, Java, Linux etc.). In this respect IBM, google, Microsoft, Facebook and Apple are far better. Here even Oracle fare better due to acuisition of MySQL and sun microsystems.

I believe the major contribution from amazon might be hiring some of the open source developers to build proprietary systems. Those developers in spare time or weekends continue their open source project, but I do not have any study or articles on it.

Based on my information in 2013, amazon built their cloud using Xen hypervisor and related tools and libraries. Libvirt is one of the key libraries providing beautiful abstractions and language bindings to manage xen on Linux node at that time.

It will be nice if you can point to code from Amazon on low level library like Libvirt for cloud computing.

Can anyone explain why emacs and vim are moved to unsupported platforms?

I am not sure why dartlang being an open source language support proprietary editors like vscode, indirectly forcing them to be snooped by Microsoft and others. Hopefully the team will give equal support to open source editors Emacs and Vim for dart language in the name of security and privacy as they were promoting it in google IO 2019.

@viraptor What I mean by using existing tools is based on my experience using it in production. I doubt docker can do similar. In order to create an image of container I just use the same chef, puppet or ansible playbook I will use for a physical server or a google compute instance i.e. launch a base container,run the playbook on container and then save it as a versioned image in a private image repository if it passes all the tests.

LXD makes it such a trivial job to host private image repository and serve it to a large cluster automatically that I don't need to break a sweat.

This way my infrastructure code is uniform be it compute instance, physical servers or containers. This is a beautiful thing in terms of infrastructure management be it micro-services architecture or monolith.

In our case all the code which launches container, create images, or launch physical server is same codebase following a unified pattern of doing things. In our setup we used many playbooks which we can built leveraging the work done by community for physical servers, VM's and containers.

In the docker world I cannot trust an image completely until I go through the code which is a mixture of how an image is built and which layers are used. If the image is built using successive images I need to really go back to each image code which is again a mixture of scripts, Dockerfile. Being a follower of Zen of Python PEP-20, I like explicit and hence like to know the details of images for use in production and generate them myself from base os images.

I was one of the first users of Docker when it was released, but was bit disappointed later when they try to move away from LXC to built their own layer. I wrote a blog post on it at http://www.vyomtech.com/2014/03/04/docker_and_linux_containe...

Also I would like to point out that the lxd community is helpful, engaging and absolutely wonderful. I had an issue with client ip address in haproxy container on Google compute instance you can see on https://discuss.linuxcontainers.org/t/how-to-get-real-client...

An issue was created and to my surprise a fix landed in next release. It helped me to launch haproxy containers binding port 80/443 on compute instance and have correct client ip in haproxy logs. This helped me to have analytics from haproxy logs directly.

@tobbyb Thanks for all the work on flockport your tutorials on LXC helped me to have initial production systems ready. I applied many of those concepts specially for networking using flockport tutorial.

Although today my system with LXD is much easier and getting better with every subsequent release of LXD, I owe you gratitude for helping me to get off the ground.

Good work @stgraber and team and congratulations on continuously improving and constantly releasing new version and updates. Indeed being able to do this when majority of the container funding is going to Kubernetes or Docker is a great achievement.

Has been using LXD for last 6 years in production. Its a little gem hiding with all the spotlight on Kubernetes and Docker. Indeed the way LXD works, it naturally provides a path from physical servers and VM instances to containers and back.

The important part is it runs containers in userspace providing a much better security then docker, but seems developers don't care about it.

Also you can use traditional ansible, puppet or chef to create and manage images and containers directly instead of learning shell scripts and Dockerfile way with additional cognitive load.

The only issue I am facing is mounting a shared NFS or CIFS in userspace container using FUSE, since the client drivers for this fs needs to be run through a root process. Hopefully it will be resolved in future. Tried Lizardfs instead of NFS and the system failed in the middle and my issues on the github is there for weeks without any feedback. I will try glusterfs and also looking and beegfs lets see if it can work.

I think the simple answer is philosophy of Kaizen(改善)- continuous improvement. I started working with postgresql when it was just postgres95. Recently found that my earliest question on postgresql-users was 13th October 1998, 20 years ago (https://postgrespro.com/list/id/3.0.2.32.19981013214318.0069...).

I still use PostgreSQL in my startup for almost all critical production workload. This in itself a testament to its improvements. I remember I starting with c libraries of msql and postgres95 and continued to work with them as they evolved into postgreSQL and a new kid on the block mysql. I liked postgreSQL due to its adherence to SQL. Since I like working with relational algebra. So even though MySQL was more popular in later years, I still used PostgreSQL more often, except for building qmail servers with mySQL backend.

Good work been using it as an alternative to Github and Bitbucket for over 3 years now. We have a small team with more then 52 private repository and works good so far. Besides this we replicate all the upstream opensource repository and keep it synchronized in our own instance. This is done very easily as Kallithea supports both git and mercurial. We do pull request review online and merge it offline and then push the changes to main repository. Our costs is $10/month for hosting with unlimited users, unlimited repository and small update maintenance whenever a new release comes in.

Being working mostly in python and mercurial we choose it and are using it in production for 1-1/2 years and it's been very good so far.

Agree with you coming back to the point when 5% Indian owns 80% of wealth why they aren't the target. Only targeting 20% wealth owned by over 80% common Indian won't bring any benefits.

Trix is better as it works with new web components standard, quill does not support shadowDom in chrome and doesn't follow current web components standard, check https://github.com/quilljs/quill/issues/904 for details. It will create issues when used in web components project.

thats the main issue they don't use LXC but want LXC kind of functionality and re-inventing the wheels with libcontainer. Indeed it would have been better to keep the docker core as small as possible and move LXC driver code as module. Indeed instead of using LXC userspace tools they might have focused on rebuilding the driver using lxc-go. This would have helped LXC project as well and docker team then can focus on incorporating production quality changes from LXC into Docker like unpriviledged containers.

This is really an issue abandoning a production quality LXC 1.0 code and re-writing it from scratch. This is NIH syndrome.

Actually I was thinking docker to re-use lxc-go to build the driver for LXC instead of using LXC userspace tools, this would have helped linux containers project as well. But I never intended they should re-write a new library from ground up.

My feeling was since LXC is already 1.0 and almost production ready, it would have been better to integrate its features in docker to make it production ready with one of the major enhancement of unpriviledged containers.

Now libcontainer as it is re-inventing the wheels, what's being done by LXC, will require a long path towards stability similar to LXC 1.0.

Moreover docker team should have spend more time building other drivers similar to LXC for OpenVZ or Solaris and BSD zones. Anyways I am not doing any code contribution so do not know the priority of the docker team. But this seem more sensible to me. Just my two cents.

I am using tinkerer http://www.tinkerer.me/, its very simple to change and manage and uses well known sphinx-doc with jinja templates. I like it a lot you can check my live site at http://www.vyomtech.com/, since it uses boilerplate html 5 template its very easy to customize.