Carbonyl: a New Graphical Web Browser in Your Linux Terminal

Long-time Slashdot reader destinyland writes: Someone made a Chromium fork... for your terminal. The terminal-based browser Carbonyl "adheres to, and is compatible with modern standards," writes MUO, "meaning that pages behave as they should, and you can even watch streaming video, within the Linux terminal!"

But best of all, "Pages connect and render in an instant—seemingly quicker than a desktop GUI browser, and every page we visited was rendered correctly."
From the article: There are a bunch of good reasons to browse the internet from the comfort of your terminal. It could be that eschewing the bloat of X.org and Wayland, a terminal is all you have. Maybe you like SSHing into remote machines and browsing the internet from there.

Perhaps you, like us, just really, really like terminals.

Whatever the reason, your choices of web browsers have, until recently, been limited, and your experience of the world wide web has been a janky, barely-functional one.... We tested Carbonyl in a range of Linux terminals, including the XFCE terminal. GNOME terminal, kitty, and the glorious Cool Retro Terminal. Carbonyl was smooth, fast, and flawless in all of them.

We even connected to our Raspberry Pi via SSH in CRT, and ran Carbonyl remotely, watching Taylor Swift music videos on YouTube. No problem.
And yes, you can use it to play DOOM.

Links and Lynx

[flyingfsck]

It could be an improvement.

Re:Links and Lynx

[Shades72]

If Docker is involved or a requirement, should it still be considered as a terminal application. Or just what it is, a container with all the needs and wants of a web-browser?

Feel free (or not) to persuade me of the former, but right now I think it is the latter.

Re:

[phantomfive]

I thought it was really dumb to have Docker involved, but then I thought about it, and it's a good idea to have a web browser that runs in a container. Even if containers aren't 100% secure (not even close), it's still an extra layer of security and worth something.

Of course, you can get the security of running a browser in a VM without using Carbonyl, but it's good to make it more accessible for everyone.

Re:

[getuid()]

Feel free (or not) to persuade me of the former, but right now I think it is the latter.

Are you sure you understand what "docker" does? (Quotes because it doesn't have to be Docker, it can be any other container runtime; heck, you could run a container on any up-to-date Linux kernel in 20 or so lines of shell script if you want, without any other subsystem.)

Hint: it's just a wrapper around Linux Namespaces. You can go ahead and install whatever application runs inside a container in your favorite distribution, linking it against all your local libraries. Packing it in a container image is just

Re:

[ArchieBunker]

Containers came about because developers had so many obscure and convoluted libraries that nobody besides the developer can replicate the environment. From the same people who used to talk about “DLL hell” which I have yet to experience.

Re: Links and Lynx - DLL Hell

[Lowell Boggs]

Used to happen to me a lot - install product A and it works, install product B and while it now works, product A is broken. My understanding is that Microsoft solved this problem by approximating containers - they now keep all versions of all libraries needed by an app in the bin directory for the app. Smart move even though it wastes a bit of space. The install phase of the build process creates the list of all versions of the needed libraries so when you install, you get everything you need.

Re:

[getuid()]

Containers go a bit beyond just where you store the DLLs. It's actually the name spacing that does the magic ;-)

A (linux) container has its own filesystem namespace, process namespace, network namespace (i.e. its own network identity) and user ID namespace. May or may not also have restricted access to the /dev tree.

The way it's stored ("overlayfs") to save space is actually just the cherry on top, and the least interesting of its features. Except for the immutability -- that one's actually nice :-)

Re:Links and Lynx

[getuid()]

It's less of a development problem and more of a deployment / operational problem.

Usually it's not a problem to replicate the developer's platform if the developer worked more or less up to standards. The problem is that the developer of a particular product had one particular setup, and the developer of another product had another setup. And now you have a conflict: you have to run one product in an environment it wasn't tested. When you run 50+ production services on your OS this is bound to happen at one point or another.

So containers (which were actually invented when "chroot" was, this is essentially what a filesystem namespace is) solve exactly this problem: separation and encapsulation. They used to have VMs back in the day for this, but they are heavy, inefficient, and generally are meant to solve a different problem actually.

And if you've never experienced this I claim you've never been responsible for a mid-sized productive setup, e.g. for an industrial manufacturing environment or similar. I really don't mean to offend, it's just that these things naturally come with the trade once service complexity increases. ...And yes, "service complexity" ever going up is part of the problem; yet it's a part we more often than not don't have any influence over, unless we have unlimited time on our hands to keep reinventing the wheel and re-developing the entire production stack from scratch.

But then again, this comes with its own stack of problems: release cycles. Every software component you develop will have a different release cycle from another component. E.g. a data storage API will be replaced every 5-6 months, a machine controller maybe once a year, while a user interface or repetitive jobs (think: cron-alike) may be affected weekly. Now you "go with the flow", but once you need to upgrade a specific library for a specific feature set, in any system above a certain size you're served with the dilemma of either (a) upgrading that library for every service that depends on it, and most are untested; or (b) upgrading it for only the specific service that requires it right now, in which case you inevitably enter "DLL hell" territory. And honestly, the latter is actually a sensible decision, if you can ideally make it in a way that leaves the rest of the stack as it was -- tested, working.

And now you've come full circle to containers. They really, truly, solve a very relevant real-world problem exactly the way it's supposed to be solved.

Re:

[markdavis]

>"If Docker is involved or a requirement,"

Then yuck. Especially for something that kinda wants to be "light weight".

But also further yuck because it is based on Chromium. For me, that throws it right out the window.

Up until a few years ago, Firefox ran remotely through X remarkably fast. Then it suddenly got MUCH slower for remote use. It is still a fantastic browser for local or high-bandwidth network thin-client use, though.

I would much prefer an overhaul of Dillo for something remote, functional,

Re:

[i.r.id10t]

Discovered when building Gentoo when it first came out that links2 has a "with graphics" support option/compile flag, made decent browsing really possible in a terminal. Of course, this is prior to streaming video etc (2000ish? 2001?)

Re:

[dbialac]

But the question is when will it be ported to run on Mac?

Here is the proper link

[guruevi]

https://github.com/fathyb/carb... [github.com]

Has the project and videos so you can see it in operation.

I couldnâ(TM)t find out from any of the ad-laden links what the browser was or did. I donâ(TM)t need a 10 page, 20-full-page ad history on links and curl, just give me the project.

Graphical

[Grady Martin]

Yes, this is a web browser that runs in a terminal. No, it does not seem to be keyboard-driven (nor even text-based for the most part). For the latter, I recommend w3m:

https://salsa.debian.org/debia... [debian.org]

For the former, I recommend just running Firefox, Chromium, etc. That said, Carbonyl might be useful in at least one, specific scenario: executing on a remote machine web downloads that are too large for local machines and trapped behind JavaScript barriers (e.g. CAPTCHA) but aren't supported by a plugin of yt-dlp (or youtube-dl, headless JDownloader, etc).

Finally, from Carbonyl's README (regarding the build process):

It requires around 100 GB of disk space.

Re:

[peterww]

Version 2.0 will require a quantum computer the size of Lawrence Livermore National Laboratory's and will enable the browser to emulate photo-realistic images by resizing the terminal to 3000x3000 with a custom "pixel font"

Interesting

[nhtshot]

Downloaded and gave it a shot. Yes, I wish it had a more keyboard centric interface. But, it's open source, so there's no reason somebody can't add that.

Overall, it runs great. It is a fully functioning browser running in text mode. Things render as correctly as they can without graphics and it's only sending (colored) text through an SSH session.

I'm tempted to contribute the keyboard control bits myself, but even without them, it's quite usable. I can see this being hugely useful, situationally. As others said, downloading files onto a remote box when you have to click through things is a great use-case. It's not always easy to get a real download link and even harder when they're customized per client.

Will it be my daily driving browser? Of course not. Is it a neat thing to have in the tool-bag for an odd scenario? Absolutely.

Brow.sh

[Tybor]

Some other people already did it using Firefox... see https://www.brow.sh/

Re:

[tilk]

Not really. If you read the fine project README, you would know that:

[Brow.sh] runs slower and requires more resources than Carbonyl. 50x more CPU power is needed for the same content in average, that's because Carbonyl does not downscale or copy the window framebuffer, it natively renders to the terminal resolution.

Re:

[fahrbot-bot]

Some other people already did it using Firefox... see https://www.brow.sh/ [www.brow.sh]

Not really. If you read the fine project README, you would know that:

[Brow.sh] runs slower and requires more resources than Carbonyl. 50x more CPU power is needed for the same content in average, that's because Carbonyl does not downscale or copy the window framebuffer, it natively renders to the terminal resolution.

To be fair, poster said "already did it", not did it better -- the quote you offered from the Brow.sh "Cons" sub-section is about the latter. In fact, the first line of the Brow.sh section specifically states:

Browsh is the original "normal browser into a terminal" project. It starts Firefox in headless mode and connects to it through an automation protocol.

Unfortunate name?

[bn-7bc]

Is it just me or us this name to easy to misread as Chernobyl? Maybe the project should have picked another name. Let me suggest Zaporizhzhia, at least that Ukrainian power plant is not associated with a major nuclear disaster ( at least not yet). At least Zaporizhzhia has no chance to be misread as Chernobyl. Back on topic, this seams like an interesting concept. Being a terminal app, would this be abke to be tun in an ssh session?

Re:

[bn-7bc]

Sigh i never notice my typos before it's to late. I wish Dice would get of their high horse(es) and give us a edit button, come one other places have them. They might be tricky to find, but mist places do have'em

Jesus

[peterww]

If these nerds put 1/20th the amount of effort into curing cancer that they currently spend making a fucking graphical browser in a Linux terminal, we would have a life expectancy of 325 years by now

"Hey you know what I just made?"
"What?"
"Something nobody has ever needed but my geeky friends will just fucking FREAK over"
"What is it?"
((shitting noises))

Re:Jesus

[serviscope_minor]

Why are you putting effort into shitting on others on slashdot rather working on a cancer cure right now?
Hypocrite.

Wow! Doom...

[TheZeal0t]

In that MP4, Doom almost looks as good as the original resolution I played it at on my 486-SX in 1992!

Terminal based browsers

[e1z0]

There are a little more terminal based browsers like this https://github.com/e1z0/Frameb... [github.com] it works quite well even on old systems...