Hacker Newsnew | past | comments | ask | show | jobs | submit | maxloh's commentslogin

In contrast, the Multi-Account Containers system is the primary reason I avoid Firefox.

While it is meant to be an alternative to Chrome's profile switching, it is more a workaround than a complete replacement. I need entirely different sets of extensions for personal, work, and school environments, something containers can't do.

Firefox's actual profile support is beyond terrible. To launch a separate instance, Firefox requires many more clicks than Chrome, all within a Windows-2000-style UI. Not to mention that there are weird glitches in their implementation.

Firefox is not usable for me until they actually spend time improving their multiple profile support.


I definitely have not had that experience, although use FF for personal, various work, and various educational places.

None of those have required me to install a particular extension..

Of course thats not to deny your experience!

The only time profiles ever come into it, for me, is using web driver, playwright, or whatever.

I guess maybe the usage stats dont support making the profile selector better.

But also, maybe its a thing they would accept a change for?


Myself the profile support is the absolute worst thing about Chrome. I just want to log into some web site, I don't want to fight with the profiles to get things done.

For those few applications where I really would need profiles I will just open a different browser, so I still keep Edge/Chrome/Opera around for that rare situation. I don't need something that complicates my life every single click but it is the whole ideology of the Google Economy that they want you to spend 1% of attention on things that matter to you and 99% on things that don't.


This is not meant to be an alternative for Chrome's profile switching. It's a different use case entirely.

As you yourself mention, Firefox has actual profile support, which may not be as good as Chrome's, but at least compare like for like.


Firefox has a new Chrome-like profiles support as of v149.

https://support.mozilla.org/en-US/kb/profile-management


LMFAO. Containers are not for profiles-purpose. Everyone who needs profiles know this.

And Firefox now needs 2 click to switch profiles.


Mozilla is doing exactly what you’re describing. They need revenue to ditch their direct financial ties to Google (and I wonder if they hire those high-salary executives solely in the hope of generating that revenue).

These AI products, along with all previous failed attempts, are just them trying to gain enough revenue to remove that dependency on Google.


And you your point, AI is probably eating search and with it the prospect of search licensing revenue. Not sure yet what paradigms will be most important to the browser experience but it's critical to get in early and make the inevitable early mistakes and work through them.

Mozilla needs money to support the development of Firefox (and the payroll of its high-salary executives).

For now, they mainly rely on Google for that money. Google pays them to avoid antitrust cases, to show the courts that they are not a monopoly and that "alternatives" exist. For example, the DOJ once proposed that Google be forced to sell off Chrome.

However, if another entity has control over your budget, they also have control over your product. If Firefox becomes "too good" to be a true competitor in the consumer space, the funding might be reduced or even cut off.

Creating a new source of revenue allows Mozilla to improve Firefox even beyond the point Google feels "comfortable" with.


I have the same experience with my RX 5700. The supported ROCm version is too old to get Ollama running.

Vulkan backend of Ollama works fine for me, but it took one year or two for them to officially support it.


Note that this is fundamentally different from the Astral acquisition. At the end of their announcement, they stated:

> Cirrus CI will shut down effective Monday, June 1, 2026.

And earlier in the article:

> Joining OpenAI allows us to extend the mission we started with Cirrus Labs: building new kinds of tooling and environments that make engineers more effective, for both human engineers and agentic engineers.

It isn't a product-led acquisition, but more a talent one.


This is kind-of neat too, at least in the near term:

> In the coming weeks, we will relicense all of our source-available tools, including Tart, Vetu and Orchard under a more permissive license. We have also stopped charging licensing fees for them.


That part is amazing. Back when I first heard of tart I thought it was amazing, with the one downside being the license.

Hopefully development on it continues, or a community maintained version keeps it going.


This is making my current work 100 times easier. Very welcome timing.

This is awesome because I flippin love tart.

This is a huge deal! I secretly hoped for this. :)

Just want to note that we will continue maintaining and improving our virtualization solutions actually with even greater attention. SaaS options like Cirrus CI and Cirrus Runners will eventually wind down so we can focus on incorporating pieces internally.


You’ll be pleasantly surprised. Updates in the coming weeks.

> In the coming weeks, we will relicense all of our source-available tools, including Tart, Vetu and Orchard under a more permissive license. We have also stopped charging licensing fees for them.


MIT or Apache2 or FreeBSD licenses would be preferable in my case, but GPLv2 or even AGPLv3 (if you have to) would work.

If you’re taking requests…


That sounds like a British phrase for pimping.

If your scope includes making the Codex web app environments have additional functionality I look forward to it. More enterprise features and yaml backed pipelines.

If you are interested in yaml backed pipelines check out this open source tool I built for exactly this purpose:

https://github.com/smogili1/circuit


For now.

I mostly clicked the link because I was curious if Cirrus Labs operates Cirrus CI and if so how that would be impacted.

Looks like I’ll need to move the FreeBSD CI jobs for open source projects I maintain to another solution. Anyone have suggestions for alternatives?


I guess qemu over Ubuntu-latest from GitHub Actions running freebsd, but it will be a bit flaky

Same for me. I liked the native BSD runners, qemu on gh is much slower.

It could also be a suite of product acquisition, the CI could be a product OpenAI is interested in having, but not sell.

Yeah. Much like Astral - acquiring both the product (because they need to use it internally, but don't care about trying to resell / market), and they also want the talent to keep maintaining it / add features they want.

>It isn't a product-led acquisition, but more a talent one.

I am pretty sure OAI mostly cares about their virtualization IP for MacOS. They already extensively use WSL2 for sandboxing Codex on Windows, and I imagine they want something similar for Codex on Mac.


Is Sam or family an investor in them anyways?

We were 100% bootstrapped with no outside capital or support/advisory.

Congrats, I am sure you and team made some $$$.

Snap is definitely not abandoned.

Sadly

> Snap is definitely not abandoned.

You seem to be say it like it's a good thing?

Can't wait for that thing to explode and die.


Snap is a terrible. It's the reason why I stopped using Debian based distros after decades for desktop usage.

Lying to users and turning apt install commands into shims for a barely functional replacement was disrespectful. Flatpak was and still is better, but even then if I say I want a system package you give me a system package. If you have infrastructural reasons why you cannot continue to provide that package then remove it, Debian based systems have many ways to provide such things.

Canonical did it because they wanted to boost Snap usage and if failed while sending a clear message they don't respect their user base.


For context, the latest version of extension spec (Manifest V3) is just 1.5 years old. It isn't something old or legacy.

To install a JSON formatter, you need to grant the following access:

1. Access to the page DOM to read the raw JSON content.

2. Permission to modify the DOM to display the formatted results.

Unfortunately, these requirements necessitate broad host permissions, which allow an extension to inject ads or track user behaviors. There is no alternative way to define a strict security boundary that allows these specific permissions while preventing abuses.


I’m pretty sure you can setup without broad host permissions, you just probably wouldn’t like it. You’d have to click a button to trigger the behavior, which I think requires you to click another button to approve access. Or configure the extension to allow access to specific domains after install, which will also have a permission prompt.

> There is no alternative way to define a strict security boundary that allows these specific permissions while preventing abuses.

Maybe you're right, and there isn't. Does it not follow that we should probably require extensive review and open-source reproducible builds before allowing any such extension on the browser extension stores?



This is exactly what I don't want my extension to become. I don't want a new UX, I want the existing UX to be enhanced.

> We plan to discuss and plan the technical direction of Collabora Office, look at our next steps, wrangle any particularly controversial technical topics and ensure that all viewpoints are heard before reaching mature conclusions together.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: