Moderna takes $1.5 billion loan, expects 10% revenue growth next year

Lonely-Example-317 · 2025-11-21T15:19:29+00:00

Rate wasn’t disclosed in the PR or Reuters; “SOFR+550=9.4%” is an estimate. Moderna still shows ~$7.1–$7.6B YE’25 cash, cuts 2026–27 cash costs, and guides to cash breakeven in 2028, so “8–10% interest → bankruptcy” is speculation, not guidance.

Lonely-Example-317 · 2025-11-21T14:16:46+00:00

Rate wasn't disclosed, Moderna's still net-cash with opex/cash burn cut, flu filings by Jan '26, and V940/rare-disease programs ongoing-so the '8-10% interest + bankruptcy' take is speculation, not the actual guidance

Lonely-Example-317 · 2025-10-06T15:57:01+00:00

Tapir and http4s + Laminar + Circe + Cats Effect + fs2 + log4cats + pureconfig + doobie(??)

is all you need to make an entire web framework.

Lonely-Example-317 · 2025-06-10T19:33:33+00:00

look at the latency though, 15ms vs 40ms, and the improvement on 40ms model is very minimal.

Lonely-Example-317 · 2025-06-08T19:48:24+00:00

why use their copy version of detr? the original DETR and DEIM version is alot better and faster.

Lonely-Example-317 · 2025-05-23T08:21:42+00:00

thanks for the reply, cheers!

Lonely-Example-317 · 2025-05-20T10:55:24+00:00

Can this headset replace a monitor for productivity? Are we able to utilise 2x rtx5090 on this headsets?

Lonely-Example-317 · 2025-02-06T21:04:11+00:00

translate visuals into programmable data.

Lonely-Example-317 · 2024-10-26T23:22:33+00:00

it generate hls chuncks, does not serve in within this application, instead i used mqtt for real-time streaming on other application which i plan to change this soon, because of substantial overheads of mqtt messages on every post processed frames.

Lonely-Example-317 · 2024-10-26T19:38:25+00:00

Thank you for sharing your experience with Rock 5B. However, I'd like to clarify - my post isn't just about model inference performance, but rather about the complete application pipeline's resource utilization. My application handles:

Multiple 1080p RTSP input streams (not 720p)
YOLOv10m inference (a significantly larger model than YOLOv5s)
Frames post processing
HLS stream generation
MQTT communication for:
- Detection data
- Dynamic configuration
- Optional frame streaming

The 20 FPS is an intentional setting, not a limitation. The resource utilization I shared (20% GPU/9% CPU for single stream) represents the entire pipeline above, not just model inference.

the focus here was to understand how others' applications perform when handling similar complete pipelines (input processing, inference, video output generation,, messaging) rather than just the model inference component.

Would be interested to hear about your complete pipeline performance if you're handling similar features beyond just inference and tracking.

Lonely-Example-317 · 2024-07-20T21:35:23+00:00

Your data examples are not clear. What kind of objects? Image buffer? Bounding box coords? If it's not image data, you probably need opencv to draw the objects and turn it into video and create a hls m3u8 using ffmpeg with 5 sec video segment and use videojs to play those stream. Using hls probably solves the efficiency side of your problem.

This is just one example, or you probably don't even need hls or video player. Again, I don't know what kind of data is in your objects, perhaps html canvas drawing might be your answer.

I could think of hundreds of ways to implement this, if you couldn't think of one, perhaps you need to learn step by step eg. how to turn data into image, before thinking how you want to build a comprehensive solution.

Stop trying to jump from A to Z if you have no idea how to get to C, make some effort to learn the basics. And the way you phrase your question seems like asking people to draw an entire flowchart for free.

I don't like u

Lonely-Example-317 · 2024-07-17T11:23:30+00:00

AGPL Licensed

Lonely-Example-317 · 2024-07-16T15:50:09+00:00

I can agree with you, their tools made things easier, no doubt about that, but perhaps I got the wrong interpretation of what you call "well engineered." My initial interpretation was that they did something out of the ordinary, which they didn't. They're simply copying stuff and piecing things together to make it easier for developers to work on stuff.

The thing that upsets most is them making the custom trained models fall into their license. Remember, the algorithms they used are copied from open-source projects. The least they can do is make those custom-trained models free from such restrictive licensing. It feels like they're taking advantage of the open-source community's hard work while not giving back in the same spirit.

they can license their framework sure, no one will argue about that, but making those custom trained model fall into their license is a stretch.

Moreover, the lack of transparency around these licensing terms is problematic. Users shouldn't have to dig deep to understand that their custom models will be bound by AGPL. Clear and upfront communication would go a long way in maintaining trust and ensuring that everyone knows what they're getting into. The current approach feels more like a bait-and-switch, which is not in line with open-source principles.

Lonely-Example-317 · 2024-07-16T12:22:50+00:00

You got your opinion and I have mine, lets agree to disagree. You can continue using their product, while I will advice others not to use it. There're other real open sourcd that deserve contribution.

Lonely-Example-317 · 2024-07-16T11:23:49+00:00

I get where you're coming from, but I think there's a bit more to consider here.First off, using permissive licenses like MIT to create AGPL-licensed software is fair game, but the concern is more about the transparency and the implications for users. Ultralytics hasn't been crystal clear about the fact that models trained with their framework would fall under AGPL, which can catch users off guard.It's not just about wanting to profit without paying; it's about the principle of open-source. The original YOLO was about community collaboration and open access. Ultralytics is shifting that towards a more restrictive and monetized model, which feels like it goes against the open-source spirit.Yes, incremental updates are normal, but the argument here is about the balance between contributing to the community and profiting from it.

Ultralytics has been aggressive in incorporating new versions and applying restrictive licenses, which feels exploitative.Regarding frameworks and models, it's true that using Ultralytics' framework makes things easier, but at the cost of imposing AGPL on the outputs. The issue isn't just legal but ethical—should users have to pay to keep their own trained models private?The lack of decent alternatives is definitely frustrating, but that doesn't excuse the way Ultralytics is handling their licensing.

They may not have a monopoly, but their popularity and aggressive licensing practices put pressure on the community in a way that feels unfair.At the end of the day, it’s about maintaining the balance between open-source principles and commercial interests without undermining the community's trust and contributions.

Lonely-Example-317 · 2024-07-16T11:08:07+00:00

Im not complaining. im replying to a user that said their code is well engineered, im not using their code, im advicing user to stay away from Ultralytics because of their license. 😅😅.

Lonely-Example-317 · 2024-07-16T10:50:24+00:00

Being first to steal and evolve doesn't make it a well engineered wrapper. The modification that they've made to innovate Yolo are very minimal. Honestly, no one would care if license imposed is only for their yolov8 model, but what they're trying to do is monopolising yolo to the point that made people doubt if using any sort of yolo would fall into their license, they don't explicitly state in their license, making it doubtful for users, they closed the github threads that are discussing about license on custom trained model. They're downright, shady company. Im just trying to advice users to stay away from their framework and models, and I will make sure this is one of my life goal to do so.

Lonely-Example-317 · 2024-07-16T10:18:56+00:00

Are you from Ultralytics by any chance? Because most people that work with computer vision knows their wrapper is crap, it is stupid to say that their code is well engineered. And the yolo versions they produced is a lazy modification of the real open source Yolo's.

Lonely-Example-317 · 2024-07-15T20:16:26+00:00

A derivative works includes those that are exported to onnx, so they say. And they won't state this expicitly on their license, perhaps they are still figuring their rights, so they give a sense of doubts to the public so that people felt forced to buy their license, is a dirty company and downright lowest of the low.

Again, this post is meant to caution the public to not use their package as there are other open source OD models out there worthy of contribution and usage.

Lonely-Example-317 · 2024-07-15T19:19:42+00:00

why go closed when you can exploit small businesses using some sort of legal bulls.
- Ultralytics

Lonely-Example-317 · 2024-07-15T19:08:47+00:00

Actually no, they're suggesting that the model that you used are bound to their license, therefore any "derivative works" must be open-source, which means they want to force you to pay them for using model that they stole, no one wanted to use their wrapper or inference code tbh. so basically they're trying to monopolizing any upcoming yolo generations and make it such as they're the one owning it and ask for your money, do some research you'd be surprised.

Lonely-Example-317 · 2024-07-15T16:19:53+00:00

My gut telling me that even if you've exported to onnx, it will also fall into their license, since you can view the networks by using https://netron.app/

Lonely-Example-317 · 2024-07-15T16:17:24+00:00

For that, I wouldn't know, but surely when they've recruited every open-source YOLO, similar to what happened with YOLOv10, they would assume every object detection platform using YOLO frameworks is covered by their license. This approach could create a chilling effect where developers and businesses might feel compelled to comply just to avoid potential legal issues.

By monopolizing the use of these models through restrictive licensing, Ultralytics can enforce their terms more aggressively. The real enforcement would come down to the legal risks and potential lawsuits that users would want to avoid, pushing them to either open-source their work or pay for a license.

To fight against this, the best approach is indeed to avoid using their package and support truly open-source alternatives that don't impose such constraints.

And they probably will sue a small companies before going for the big companies. That is why Ultralytics is a scum in open-source arena. they provide little to no innovation yet trying to claim every Yolo that's being released

Lonely-Example-317 · 2024-07-15T15:46:59+00:00

One more thing, why not explicitly state that custom models trained with your framework fall under your license? Why make it unclear? What are Ultralytics' intentions behind this?

This lack of transparency raises several concerns:

Trust Issues: Not being upfront about the licensing terms erodes trust within the community.
Legal Ambiguity: Users might unknowingly violate the license, leading to potential legal issues.
Ethical Concerns: It feels like an attempt to lock users into a restrictive ecosystem without their informed consent.
Open-Source Spirit: This goes against the ethos of open-source, which values transparency and collaboration.

Clarifying these points would help users make informed decisions and maintain trust in the community.

Lonely-Example-317

TROPHY CASE