[HN Gopher] Opossum: Cross-platform web browser written in Golan...
___________________________________________________________________
Opossum: Cross-platform web browser written in Golang, optimized
for Plan 9
Author : euclaise
Score : 235 points
Date : 2023-02-20 15:15 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| liotier wrote:
| At this point in market concentration, any sufficiently brave or
| delusional soul that ventures into even the most rudimentary web
| browser development is a hero to me !
| 1vuio0pswjnm7 wrote:
| The word "rudimentary" is the important one here, IMHO. If the
| goal of a new browser is to match the "market leaders" feature-
| for-feature, then all bets are off, IMHO.
|
| However, if one changes the starting assumptions, e.g., only
| seek some basic functionality instead of a carbon copy of the
| existing browsers (but controlled by some new entity), then the
| playing field becomes level enough to have meaningful
| competition.
|
| Another assumption is that all browsers must be "all-purpose".
| But some could just as well be limited purpose. Arguably we
| already see an extreme case of this in "mobile apps" which
| target only one site. Alas, these tend to be non-transparent,
| not open-source nor easily modifiable and recompilable.
|
| As a text-only browser user, along with non-browser TCP
| clients, each being vastly simpler than a so-called "modern"
| browser, I am able to consume a large amount of web content
| without ever touching Javascript or graphics. That amount has
| surprisingly increased over time. More and more web content
| today comes as structured plaintext (JSON) which is very easy
| to convert into any format one desires. (Without using remotely
| hosted Javascript.)
|
| IMHO, Javascript is likely a black hole for any "rudimentary"
| browser project. The size of the interpreter and the memory
| demands, entire classes of security issues that are enabled by
| Javascript, the list of "gotchas" is long if not endless. If JS
| is a must-have, I hope it's worth it.
| 0xb0565e487 wrote:
| Beware of assumptions. You arrived at a funny conclusion here.
|
| Did the author express that his intent was to capture browser
| marketshare? If not, he may not be delusional :)
| 2h wrote:
| > At this point in market concentration
|
| as others mentioned, some people don't care about market share.
| the browsers I use day to day (Firefox, Chrome) are honestly
| pretty bloated and terrible, so I think others would agree that
| quality wise, users are starving for something better.
| jchw wrote:
| Even though Go is unlikely to be an ideal choice for a web
| browser, I had definitely wanted to venture into it just as a
| toy project. Unfortunately, it's obviously an enormous project,
| so I am absolutely nowhere on it.
|
| That said, shameless plug: if anyone wants a reasonably
| complete but immature ECMA262 parser in Go, I _did_ do that.
| You can see how (un)finished it is here, with the wasm build:
| https://cleansheets.io/parser/ - source here.
| https://github.com/jchv/cleansheets
|
| The truth is, I'd like to still work on this and even see if
| it's plausible to build a decent JIT without going too far into
| the weeds (I wouldn't tolerate a requirement on Cgo personally)
| but given that I never even pushed up an interpreter (I had an
| AST-based interpreter, but it was so ugly that I scrapped it :)
| I doubt I'll get anywhere near Opossum. Oh well.
|
| It'd still be fun to at least get some pages rendering.
| Probably no chance in hell I'd ever get over to milestones I'd
| actually like to (like booting GMail for example.)
| mtlmtlmtlmtl wrote:
| I would say the browser ecosystem as a whole is thriving,
| there's all sorts of browsers for different needs, but most of
| them are based on the same couple web engines.
|
| This looks like an implementation from scratch which is
| fantastic.
| samwillis wrote:
| I think what's been achieved in a little over a year with the
| Ladybird Browser from the SerenityOS project shows that it's
| quite possible to build a new browser from scratch. And yes,
| they are absolute heroes for doing it!
|
| https://awesomekling.github.io/Ladybird-a-new-cross-platform...
|
| https://linus.dev/posts/ladybird-browser-year-in-review-2022...
| tester756 wrote:
| http client, UI interactions logic, domain models, utilities like
| tree operations, browser domain logic
|
| and all of that inside single go file?
|
| I think you'd make your life 10 times easier by splitting it
| better
| spenczar5 wrote:
| What difference does that really make? In Go, all files in a
| directory share a namespace. I think the only impacts of
| splitting a file are build tags and shortening the import list,
| and neither really applies here.
|
| Those components you listed could be in separate packages, but
| in a program this small that seems merely different, not better
| or worse.
| tester756 wrote:
| >What difference does that really make?
|
| Depends if you want to continue developing this (or any)
| project
|
| If you want, then it makes huge difference, the faster you
| refactor it, then the easier the development will be.
|
| If you want to stop putting effort into it, then there'll be
| no difference.
|
| One file doing everything is almost always more annoying than
| stuff splitted correctly.
| euclaise wrote:
| Not just for continuing development in general, but it
| would be nice for potential contributors too!
| 2h wrote:
| > all of that inside single go file?
|
| no, did you even visit the link?
| tester756 wrote:
| what's inside "browser.go" then?
| 2h wrote:
| did you not see the 20 other go files in that repo?
| spenczar5 wrote:
| I fully acknowledge that Plan9 had a cool vision, maybe a
| superior one to the world we've got. But is it practical as an
| operating system for day to day use, particularly when working
| with other people using conventional Linux/Mac/Windows?
| johnnyjeans wrote:
| As with everything else, it depends on who you are and what you
| do. Email, typesetting, remote shells are all well within the
| bounds of what workflows work great out of the box.
| ghostly_s wrote:
| _Typesetting_? the linux-centric FOSS world has failed to
| produce a serious type-setting application for going on 30
| years now, what 's the offering here?
| euclaise wrote:
| Just troff and TeX
| timcavel wrote:
| [dead]
| rollcat wrote:
| > But is it practical as an operating system for day to day use
| [...]?
|
| It was never meant to be. Just like UNIX initially, it was a
| research operating system. UNIX turned out to be an accidental
| runaway success, and many of Plan9's greatest ideas (like
| synthetic filesystems, bind/union mounts, its threading
| library, the 9p protocol, etc) found their way to more
| "practical" systems.
|
| It also did have a commercial counterpart in Inferno (mostly
| finding use in products like telephone switches). But nowadays
| both remain mostly as toys for enthusiasts. You can get work
| done, if you're patient enough, and have the freedom to ignore
| things like Zoom calls or Excel files.
| forgotpwd16 wrote:
| >It also did have a commercial counterpart in Inferno
|
| Plan 9 was also available commercially for some time.
| pjmlp wrote:
| Not when one cares about graphics programming.
| pram wrote:
| It's trivial to get running in qemu if you're really curious.
| spenczar5 wrote:
| Sure, but that doesn't seem to really be using Plan9, at
| least to me. Networked access seems so fundamental to Plan9
| that running it in a sandbox seems like trying out a car with
| all the tires removed.
|
| I'm interested in hearing what it's like to use it more
| seriously; my biggest doubts are around collaborating with
| people on conventional OSes.
| PaulDavisThe1st wrote:
| Qemu allows full network access. It's a very porous
| "sandbox"
| spenczar5 wrote:
| Maybe I misunderstood Plan9, but I figured that if remote
| services aren't speaking 9P then everything would be a
| bit kludgey. Like, using Acme on local files which you
| push up to Github seems to be somehow against the spirit
| of Plan9. I suppose you could just use it like any other
| Unix-like OS, but what's the point?
|
| I think I'm convincing myself in this thread that it's
| not for me - but of course I think it's great that others
| are using it, I don't want to sound too negative.
| euclaise wrote:
| I think it's more important that services can be exposed
| as filesystems like webfs or gitfs than that they are
| exposed as 9P.
| n4ture wrote:
| I've used it as my "main driver" for around 6 months last
| year and I can assure you it's definitely practical, you
| can also easily interact with the other OSes with ssh and
| vnc, that way I could even do some remote video calls from
| plan9 with the help of another linux computer for instance.
| prmoustache wrote:
| There is an image for raspberry pi. I guess that can be a
| good way to force yourself into it. Just make sure to have
| vnc access to a linux, mac or windows computer if you need
| it for work too.
| exitb wrote:
| That question makes no sense really. It's like asking whether
| camping can be as practical as living in a proper house - maybe
| for some people, but generally, that's just not the point.
| spenczar5 wrote:
| If that's the analogy, then I think the question is certainly
| answered for me! "Practical isn't the point" seems pretty
| similar to "no, it's not _generally_ practical. "
| exitb wrote:
| I think there's an interesting clue in the fact that the
| entire 9front has less lines of code than Go, which this
| browser depends on. And that includes two web browsers
| already shipped with the system! Yes, there are ways to
| force Plan 9 into something it isn't, but fundamentally
| starting from the assumption that you want it replace your
| daily driver is not going to work out.
|
| If you're interested in it, set it up on a Raspberry Pi,
| connect to it with drawterm from your daily driver.
| Experiment with adding a second machine, netbooting it as a
| CPU server etc. That way you'll look at Plan 9 from the
| point of its strengths, not weaknesses.
| spenczar5 wrote:
| Thanks, this is a good suggestion, and it sounds a lot
| more like what I'm looking for - "seeing Plan9 from its
| strengths" is exactly right.
| nurettin wrote:
| I have witnessed dozens of people making vague statements about
| how awestruck they are with plan9's vision, and I've always
| wondered what exactly they mean.
| jacobr1 wrote:
| Maybe try https://9p.io/sys/doc/9.html
|
| My take is that plan 9 is basically a "pure" rewrite of a
| unix/posix OS, that takes many underlying principles of unix
| to their logical conclusions, without the taint of the
| incremental evolution of the existing systems, yet
| nevertheless informed by the lessons learned operating real
| OS systems. The incompatibility is why it hasn't moved
| forward, though many of the good ideas that are compatible
| with systems like bsd/linux have since been ported over.
|
| It is really useful exercise to consider, in hindsight, how
| could we have built a better unix? And a bunch of really
| smart people participated and came up with some great ideas.
| pjmlp wrote:
| Curious to see how they will get WebGL and WebGPU over file
| handles.
| klodolph wrote:
| Does Plan9 even have hardware OpenGL implementations to begin
| with?
| pjmlp wrote:
| No, and having a file based driver for graphics also doesn't
| help that much.
|
| https://marc.info/?l=9fans&m=111558695515839&w=2
| hummus_bae wrote:
| [dead]
| badsectoracula wrote:
| OpenGL already has a client/server model (i remember a friend
| of mine once showing me running some OpenGL stuff from his SGI
| to his Linux machine... or the other way around, it has been
| years :-P) and i can't think of anything in WebGL that couldn't
| work in the same way (though i only used WebGL _very_ little).
| Sending commands and data over a file handle fits this fine.
|
| Note sure about WebGPU though.
| fiber wrote:
| Congrats Philip on hitting #1 on Hacker News! Great piece of
| work!
| 762236 wrote:
| Good luck with garbage collection
| dgb23 wrote:
| I wonder how much ad-hoc GC popular browsers have and what the
| tradeoffs are in comparison to using a runtime with a GC and
| avoiding allocations where necessary.
| pjmlp wrote:
| Indeed, we need more such projects to clean our industry from
| non believers.
|
| Alef for Plan 9 was going to be GC based, and even though it
| went in another way, Inferno and Limbo clearly fix that error.
| bitwize wrote:
| Go itself is pretty much Alef 2.0
| pjmlp wrote:
| It could have kept dynamic loading and pick types from
| Limbo, though.
| butterisgood wrote:
| https://pkg.go.dev/plugin but not for all platforms.
| pjmlp wrote:
| It is not the same.
|
| Not only it doesn't work in all platforms, they already
| planned to drop it once, and uses low level dlopen like
| API.
| mburee wrote:
| What's the problem with GC? Between C and Go (and maybe Scheme)
| there's not much choice of languages on plan 9 today.
|
| So not having to think about memory management in a browser pet
| project is surely the best choice when it comes to a relatively
| ambitious project as this.
|
| Also of note, Limbo (the language the successor was written is)
| is also garbage collected, so it's not like it's against the
| spirit of plan 9. The predecessor language, Alef, supposedly
| was abandoned in part because it didn't have GC.
| calvinmorrison wrote:
| Don't forget Perl
| euclaise wrote:
| There's also Myrddin, Ocaml (port), and Haskell (nhc and
| Hugs), and there was some work on getting Zig working on Plan
| 9
| butterisgood wrote:
| Lua works pretty nicely also.
| euclaise wrote:
| If we're including languages that have no intention of
| being compiled, there's also TCL and Python 2
| olliej wrote:
| Oh nice, and it's an actual browser engine not just another
| chromium wrapper \o/
|
| Good luck to them - we need more actual engines rather than the
| modern "new browser" model where it's just whatever Google want
| in chrome.
| eshack94 wrote:
| Serious question: What is Plan 9? Can someone explain or send me
| some docs to read? Thank you!
| qbasic_forever wrote:
| Bell Labs' planned successor to Unix:
| https://en.m.wikipedia.org/wiki/Plan_9_from_Bell_Labs
| eshack94 wrote:
| Thank you I will do some reading!
| SllX wrote:
| Someone already answered, but as some follow up reading I
| recommend this collection of documents:
| http://doc.cat-v.org/plan_9/
| eshack94 wrote:
| Thank you! I'm going to read up.
| forgotmypw17 wrote:
| Has anyone built this? I'd love some screenshots of my website.
| andrewfromx wrote:
| https://i.imgur.com/GPdnYBa.png
|
| Building on mac was easy. It compiled fine with just go. But
| then to run it I needed:
|
| git clone --depth=1 https://github.com/9fans/plan9port.git cd
| plan9port ./INSTALL
___________________________________________________________________
(page generated 2023-02-20 23:00 UTC)