SerenityOS Browser now passes the Acid3 test(twitter.com)
twitter.com
SerenityOS Browser now passes the Acid3 test
https://twitter.com/awesomekling/status/1508953394836353024
176 comments
The old version (http://acid3.acidtests.org/) will reach 97/100 on modern compliant browsers. There is a newer version (https://wpt.live/acid/acid3/test.html) which incorporates the changes made to the specs in the meantime, so modern browsers will reach 100/100 on this one again. The test was carried out against this version, as you can see in the address bar in the screenshot.
Your link also only gets 99/100 on modern browsers.
Why? Well...
Why? Well...
// test 64: more attribute tests
// attributes of the <object> element
var obj1 = document.createElement('object');
obj1.setAttribute('data', 'test.html');
// ...
assert(obj1.data.match(/^http:/), "object.data isn't absolute");
Interesting, by forcing http I get 100/100 with chrome on windows but the animation is not smooth (there is a pause at 69/100) and it definitely does not match the reference image (there are no colored boxes at all).
Hmm, I'm seeing 99/100 in Chromium (mobile and desktop). I wonder what test is failing.
Passing the individual tests is only part of passing the complete test. Animations must be smooth and everything must be rendered pixel perfect to the sample image. All Chromium based browsers, I tried Chrome Chromium, Edge and Vivaldi appear to fail the test even if they get a 100/100 score. They all display a thin red line near the upper right of the white box. This line doesn't appear on the sample image.
Do your displays have non-integer scaling enabled?
It says "test 64 is failing: object.data isn't absolute"
Chrome is just abiding by the much more important industry standard of "it has to work in chrome, period"
I got either 68, 97 or 99 on Safari iOS. Disabled content blockers and Darker Reader.
I was seeing the same untill I changed the urls to http rather than https as per another comment, then it gets 100.
The animation is far from being fluid too.
There's an up to date version following modern specs linked in the twitter thread:
https://twitter.com/OrphisFlo/status/1508954585993461763 http://wpt.live/acid/acid3/test.html
https://twitter.com/OrphisFlo/status/1508954585993461763 http://wpt.live/acid/acid3/test.html
That's correct. Tests 23 & 25 require a specific error type that has since been changed in that circumstance: https://github.com/whatwg/dom/issues/319#ref-commit-94dd371
Test 35 requires root elements to not match :first-child, and the spec was changed to specify that they should match: https://bugzilla.mozilla.org/show_bug.cgi?id=1300374
Test 35 requires root elements to not match :first-child, and the spec was changed to specify that they should match: https://bugzilla.mozilla.org/show_bug.cgi?id=1300374
[deleted]
That's pretty dumb grading. Why not flip the sense of the assert for those three tests?
It's useful for statements like "Firefox 2.0 got 82/100 on the Acid3 test" to have truth-values that don't change over time. The Acid3 test is an important part of the history of the Web, and rewriting history is repugnant.
I meant why was it ever like that?
Its author, Hixie, was only one of the people who decided on web standards, and he didn't win every argument, so some of the behavior that eventually got standardized wasn't the behavior Hixie thought was best at the time he wrote Acid3. He did win most of the arguments by virtue of writing the HTML5 spec, but without the buy-in of browser implementors HTML5 would have been irrelevant. Also sometimes he was wrong about things.
Hmm. The LibWeb source is here: https://github.com/SerenityOS/serenity/tree/master/Userland/...
I wonder if it could be pulled out as a portable library. Having another competitive browser engine would be a good thing.
I wonder if it could be pulled out as a portable library. Having another competitive browser engine would be a good thing.
This, absolutely. Especially if it comes with a GUI in the same aesthetics as SerenityOS itself. The world needs less Chrome-clones and Google-backed browsers (which to a certain extent includes Firefox), and more independent ones.
As someone who has also been attempting to write a browser (engine) in my spare time --- but these guys are far ahead of me --- this is great to see.
As someone who has also been attempting to write a browser (engine) in my spare time --- but these guys are far ahead of me --- this is great to see.
The problem is: who's gonna use it?
Sure, it's good to have more options but, the deploy base of browsers like Chrome are massive and IE6 only lost its position by being careless and stop evolving (and lets not forget it took years), which is something that is not happening with Chrome.
Just to make clear, this is not specifically directed to you or your project, which is a great thing to do independently of the outcome. I'm saying this more as in a general perspective as we are pretty much sitted on the state-of-the-art of browser engines and its hard to see something else taking over except for a "game reset" scenario (outside of the web).
Sure, it's good to have more options but, the deploy base of browsers like Chrome are massive and IE6 only lost its position by being careless and stop evolving (and lets not forget it took years), which is something that is not happening with Chrome.
Just to make clear, this is not specifically directed to you or your project, which is a great thing to do independently of the outcome. I'm saying this more as in a general perspective as we are pretty much sitted on the state-of-the-art of browser engines and its hard to see something else taking over except for a "game reset" scenario (outside of the web).
The point is that a lot of sites out there don't need anything more than the web tech of 2 decades ago. With more people being aware of that and using browsers like this, the Google monopoly may weaken. I make it a point to complain whenever some site I need to use changes in the direction of Google's desires and becomes less browser-agnostic. It has had mixed results, but I suspect if a company is losing customers because its web devs are Google-loving trendchasers, they'll take notice.
> The point is that a lot of sites out there don't need anything more than the web tech of 2 decades ago. With more people being aware of that and using browsers like this, the Google monopoly may weaken.
I always thought this was a way to get out of this, that agrees with your vision. First you'll need a powerful force to take back control on defining web standards.
This new web standard would be a very simplistic one, making possible for two or three (or even one) people to create new browsers on top of it.
But this movement would need to be so strong, that it would be possible to make a dent and start to lead a new way. And this is the one of the most hardest part. People on this movement would need to be prepared to fight for at least 10 years without loosing its faith until the killer app of this movement should be able to be at a market share bigger than Safari and taking over the Firefox position.
This movement could use the hype akin to Rust folks to navigate the harder first years. Its a possibility but it's hard to become possible. Another thing to notice is that the Firefox position is getting weaker, but the most probable candidate to take over is the chrome-based Brave.
So unless a "black-swan" event happen it's hard to see a big change into this in the coming years. BTW it's even more likely that the browser standards get stronger by completely taking over the mobile applications..
I always thought this was a way to get out of this, that agrees with your vision. First you'll need a powerful force to take back control on defining web standards.
This new web standard would be a very simplistic one, making possible for two or three (or even one) people to create new browsers on top of it.
But this movement would need to be so strong, that it would be possible to make a dent and start to lead a new way. And this is the one of the most hardest part. People on this movement would need to be prepared to fight for at least 10 years without loosing its faith until the killer app of this movement should be able to be at a market share bigger than Safari and taking over the Firefox position.
This movement could use the hype akin to Rust folks to navigate the harder first years. Its a possibility but it's hard to become possible. Another thing to notice is that the Firefox position is getting weaker, but the most probable candidate to take over is the chrome-based Brave.
So unless a "black-swan" event happen it's hard to see a big change into this in the coming years. BTW it's even more likely that the browser standards get stronger by completely taking over the mobile applications..
Gemini is one of such simplistic standards.
I think Gemini will have people following it and developing for it, but i think it could have been a little more ambitious and also took tech history a little bit more serious as to not take too much out of what is actually a improvement done on the web that could be a soft fork of the current web with a lot less things, but not as simplistic as Gemini is.
So i don't think Gemini is "it" yet, but at least i liked the audacity and the way of thinking, its on the right direction and actually it should be people like Tim-berners-lee that should actually be leading this, but unfortunately they are lost..
So i don't think Gemini is "it" yet, but at least i liked the audacity and the way of thinking, its on the right direction and actually it should be people like Tim-berners-lee that should actually be leading this, but unfortunately they are lost..
I think browsers are comparable to operating systems, and if we look at the richness of the Linux ecosystem, I'd say it can't hurt to have a few more browsers and browser engines. For example, most users wouldn't see the utility of Arch linux. And yet Arch linux is the backbone of Docker. Perhaps a new browser engine can fill a similar niche, targeting low resource usage and light browsing
There already are Ultralig.ht, Netsurf, Goanna - all lightweight web engines.
It should already run on Linux using Lagom, at least I have seen the tests for LibJS run on Linux.
https://github.com/SerenityOS/serenity/blob/master/Meta/Lago...
https://github.com/SerenityOS/serenity/blob/master/Meta/Lago...
Lagom covers many libraries, including various ones used in the Browser/LibWeb (e.g. LibJS, LibWasm), but LibWeb itself is not part of Lagom and doesn't currently build or run on Linux. It's absolutely possible, but no one is working towards it specifically at the moment.
There's a list of things needed to make that happen here: https://github.com/SerenityOS/serenity/issues/10968
It seems that Lagom ports AK and LibCore, the core C++ library components that Serenity is using instead of the STL, to other platforms like Linux.
This may be useful for devs who want to entirely ditch the STL in favor of a much cleaner and ergonomic library.
This may be useful for devs who want to entirely ditch the STL in favor of a much cleaner and ergonomic library.
Yeah, a lot of game engines use some sort of HTML-based UI system. Having this thing as an easily includable library would be amazing.
Andreas Kling is a legend. He and his team really bring back the hacker ethos. Grind on hard problems people, instead of grinding on leetcode.
Aren't there some hard problems on leetcode?
I can see this analogy as:
"Don't do your math homework. Instead, find hard math problems in real life to solve."
I can see this analogy as:
"Don't do your math homework. Instead, find hard math problems in real life to solve."
This does not make sense in terms of expected utility.
maybe for your utility function
It makes sense in terms of having fun.
It's a great achievement!
But note that it doesn't mean that the browser interprets modern CSS correctly.
Wikipedia's Acid3 page says:
> By April 2017, the updated specifications had diverged from the test such that the latest versions of Google Chrome, Safari and Mozilla Firefox no longer pass the test as written. Hickson acknowledges that some aspects of the test were controversial and has written that the test "no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers".
Strangly, my Safari on iPad just achieved 100/100. a minute ago it achieved 97/100.
Does anyone know what's up with it? Are there timing dependencies? What are the divergences in modern specifications?
But note that it doesn't mean that the browser interprets modern CSS correctly.
Wikipedia's Acid3 page says:
> By April 2017, the updated specifications had diverged from the test such that the latest versions of Google Chrome, Safari and Mozilla Firefox no longer pass the test as written. Hickson acknowledges that some aspects of the test were controversial and has written that the test "no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers".
Strangly, my Safari on iPad just achieved 100/100. a minute ago it achieved 97/100.
Does anyone know what's up with it? Are there timing dependencies? What are the divergences in modern specifications?
That's how fast web standards change. Try again it'll probably be 95.
I'm joking of course. The things /I/ want [1] seem to take forever to get proper support.
https://www.w3.org/TR/webgpu/
I'm joking of course. The things /I/ want [1] seem to take forever to get proper support.
https://www.w3.org/TR/webgpu/
Have you tried being a multi billion dollar company? The things Google wants seem to be added pretty quickly.
I don't know what the divergences are specifically, but there's an up to date version following modern specs that's linked in the twitter thread, that's what the screenshot is of:
https://twitter.com/OrphisFlo/status/1508954585993461763 http://wpt.live/acid/acid3/test.html
This test, as per the address bar in the screenshot, uses the newer Acid3 test that is 100/100 (provided you access the http not https version) in modern browsers, though, not the older one.
IIRC it's something about timings that makes it fluctuate. At 97+ or so a browser can in fact be compliant insofar as the test goes.
"I think its really awesome to see just how fast you can move on these things, if um... you just get a bunch of people who really want to do it"
-- Andreas Kling on this progress: (https://www.youtube.com/watch?v=Xa5_tW_eovM)
-- Andreas Kling on this progress: (https://www.youtube.com/watch?v=Xa5_tW_eovM)
I've watched a few of this guy's videos, and it's deeply impressive. He reminds me of the grizzled old guys from the 1980's that actually know the deep internals of an OS. They didn't just take it in school, they lived and breathed it. He's the guy that made the 'myth' of a 10x coder a reality for me.
I get this is his passion project, but part of me wonders what he could accomplish working on the rough edges of linux.
I get this is his passion project, but part of me wonders what he could accomplish working on the rough edges of linux.
> I get this is his passion project, but part of me wonders what he could accomplish working on the rough edges of linux.
I've watched/listened to more than a few of his videos. Something that he has expressed on more than one occasion is an appreciation for the kind of deep vertical integration that he saw at Apple because they control the entire stack. He's going for something in that direction in Serenity and it, for example, means that they're not taking on low-level dependencies on other projects.
Anyway, this is perhaps a roundabout way of saying that I don't think he'd be all that interested in hacking on Linux - a project that very much goes against that kind of integration.
I've watched/listened to more than a few of his videos. Something that he has expressed on more than one occasion is an appreciation for the kind of deep vertical integration that he saw at Apple because they control the entire stack. He's going for something in that direction in Serenity and it, for example, means that they're not taking on low-level dependencies on other projects.
Anyway, this is perhaps a roundabout way of saying that I don't think he'd be all that interested in hacking on Linux - a project that very much goes against that kind of integration.
He's also talked about this on the CoRecursive Podcast:
Andreas: Well, I don’t know that I ever had a real direction with it. But in the beginning, I remember feeling kind of frustrated with finding myself using Linux again and thinking it’s nice to be back on Linux. Everything is snappy. And the developer experience is really great, but I sure do miss having the source code for everything.
Adam: This is a fascinating distinction to draw.
Linux is open source. Everyone has access to the code. But if you listen to episode 70 with Joey Hess talking about Debian, making changes can be a bureaucratic process. And that’s just for one distribution. There are hundreds of Linux distributions. Even if it’s a one line change, it could take years to get that upstreamed and spread into various Linux distributions. If you listen to episode 67 about Zig, that was one of Andrew’s motivations behind creating Zig.
But meanwhile, Andreas has another strategy at Apple. Everything was in one place, and everything was built internally.
Andreas: And when you’re in that environment, it’s extremely powerful.
https://corecursive.com/serenity-os-with-andreas-kling/
Andreas: Well, I don’t know that I ever had a real direction with it. But in the beginning, I remember feeling kind of frustrated with finding myself using Linux again and thinking it’s nice to be back on Linux. Everything is snappy. And the developer experience is really great, but I sure do miss having the source code for everything.
Adam: This is a fascinating distinction to draw.
Linux is open source. Everyone has access to the code. But if you listen to episode 70 with Joey Hess talking about Debian, making changes can be a bureaucratic process. And that’s just for one distribution. There are hundreds of Linux distributions. Even if it’s a one line change, it could take years to get that upstreamed and spread into various Linux distributions. If you listen to episode 67 about Zig, that was one of Andrew’s motivations behind creating Zig.
But meanwhile, Andreas has another strategy at Apple. Everything was in one place, and everything was built internally.
Andreas: And when you’re in that environment, it’s extremely powerful.
https://corecursive.com/serenity-os-with-andreas-kling/
It seems like the problem is power distance and social credit. Random developer trying to get one line of code changed may run up into a gigantic wall. What about with Linus?
The "problem" with Serenity OS is that yes, now Andreas will have all the power he wants and can get that one line change without the bureaucratic process. But what about when some random user comes along and wants to change the code? They better start programming on Tranquility OS.
The "problem" with Serenity OS is that yes, now Andreas will have all the power he wants and can get that one line change without the bureaucratic process. But what about when some random user comes along and wants to change the code? They better start programming on Tranquility OS.
If you look at the contributors graphs[1] on our GitHub repository, you'll find that folks other than myself have added tens of thousands of lines of code. I'm not quite the power-hungry gatekeeper you might imagine :^)
Regardless, the issue I have with the mainstream FOSS desktop system isn't about any one project's development process, but rather the fact that there are hundreds of independent development processes, each controlling a small fraction of the whole system. Doing any kind of cross-subsystem work in that environment becomes a significant undertaking, and that's what I'd like to avoid.
[1] https://github.com/SerenityOS/serenity/graphs/contributors
Regardless, the issue I have with the mainstream FOSS desktop system isn't about any one project's development process, but rather the fact that there are hundreds of independent development processes, each controlling a small fraction of the whole system. Doing any kind of cross-subsystem work in that environment becomes a significant undertaking, and that's what I'd like to avoid.
[1] https://github.com/SerenityOS/serenity/graphs/contributors
>but rather the fact that there are hundreds of independent development processes, each controlling a small fraction of the whole system. Doing any kind of cross-subsystem work in that environment becomes a significant undertaking
Hi Andreas, hope you are doing well. This is very wrong. There are a lot of distributions of Linux and BSD that try very hard to ship as one cohesive system. Your issue doesn't make any sense. You would find it even more the case if you tried to do something like create a whole userspace from scratch and ship that, but you've already shown otherwise how that's possible. You need to get over this false reasoning or you will find yourself in the same narrow box that a lot of Linux distributions get trapped in. That's my experience anyway from seeing a lot of failures in Linux distributions with poorly defined goals. In any case thanks for making this project, I hope it's not the last OS you design.
Hi Andreas, hope you are doing well. This is very wrong. There are a lot of distributions of Linux and BSD that try very hard to ship as one cohesive system. Your issue doesn't make any sense. You would find it even more the case if you tried to do something like create a whole userspace from scratch and ship that, but you've already shown otherwise how that's possible. You need to get over this false reasoning or you will find yourself in the same narrow box that a lot of Linux distributions get trapped in. That's my experience anyway from seeing a lot of failures in Linux distributions with poorly defined goals. In any case thanks for making this project, I hope it's not the last OS you design.
Please point me to one of these Linux systems where the kernel, drivers, windowing system, GUI framework, networking libraries, image format decoders, font rasterizers and all CLI and GUI applications plus the libraries that support them are developed cohesively within a single project and not assembled from 3rd party sources.
Andreas, that request makes no sense. You didn't write all that code in Serenity either. Other people (a.k.a. third parties) helped out. I assume a lot of the algorithms are standard too so you didn't come up with those either. I don't want to disparage your effort but please give credit where credit is due. Please also don't underestimate the amount of work an OS like Ubuntu does to get everything to function together, it may not be perfect but if you plan to grow to the size of Ubuntu then you sign up for about the same amount of work. It's not particularly relevant if the code came from in house or not.
I get what you're trying to say about vertical integration but even Apple ships a ton of common open source components because it's not practical to write every single thing again from scratch. I also get that it's fun to write your own drivers, GUI controls, TCP stack, image decoders, font rasterizers and such. It's hard for me to see how this is supposed to be "cohesive" when most of the tasks here are implementing standard things that every other OS has, even more so when this is another clone of Unix with a Windows 98 style GUI on top of it. I mean just thinking about something like a web browser, probably a good 95% of that is implementing the DOM/CSS/Javascript engines. It's a great achievement but has nothing to do with SerenityOS at all and gains nothing from any kind of perceived cohesion.
It's just apparent to me this is a really weak selling point, you can do much better than defining yourself as the OS that blatantly copies features but considers it unacceptable to copy code. That's the failing of a lot of bad NIH-syndrome Linux distributions, don't fall into that trap. You need to come up with a good selling point that isn't just "we are another Unix but we hate Linux and refuse to collaborate with them". So many other people have tried that and got nowhere. It's critical for the long term success of your project to move past this.
I get what you're trying to say about vertical integration but even Apple ships a ton of common open source components because it's not practical to write every single thing again from scratch. I also get that it's fun to write your own drivers, GUI controls, TCP stack, image decoders, font rasterizers and such. It's hard for me to see how this is supposed to be "cohesive" when most of the tasks here are implementing standard things that every other OS has, even more so when this is another clone of Unix with a Windows 98 style GUI on top of it. I mean just thinking about something like a web browser, probably a good 95% of that is implementing the DOM/CSS/Javascript engines. It's a great achievement but has nothing to do with SerenityOS at all and gains nothing from any kind of perceived cohesion.
It's just apparent to me this is a really weak selling point, you can do much better than defining yourself as the OS that blatantly copies features but considers it unacceptable to copy code. That's the failing of a lot of bad NIH-syndrome Linux distributions, don't fall into that trap. You need to come up with a good selling point that isn't just "we are another Unix but we hate Linux and refuse to collaborate with them". So many other people have tried that and got nowhere. It's critical for the long term success of your project to move past this.
What frustrates you about Linux is exactly what drew me into FreeBSD. Have you looked into the BSDs and their development model? For example, the FreeBSD kernel and the base operating system are developed as a cohesive unit like you described.
I've been watching videos of your baby progress over the years. I love the look and guiding philosophy. You should be immensely proud of what you've accomplished. But without leveraging the existing drivers, GUI frameworks, decoders from BSD or Linux, I fail to see how it can ever be more than a toy OS. However your vision implemented on a BSD base, could be the next Solus.
I've been watching videos of your baby progress over the years. I love the look and guiding philosophy. You should be immensely proud of what you've accomplished. But without leveraging the existing drivers, GUI frameworks, decoders from BSD or Linux, I fail to see how it can ever be more than a toy OS. However your vision implemented on a BSD base, could be the next Solus.
The BSDs are proof of what I'm saying. Sure the base OS is developed and released together. Meanwhile the stuff in the ports tree (the programs users actually want to run) is very similar to every common Linux distribution.
Also FreeBSD in particular has several Linux compatibility APIs and shares drivers with Linux whenever it's possible. As a founder it's tempting to fantasize about building your own universe but everyone comes back to reality eventually.
Also FreeBSD in particular has several Linux compatibility APIs and shares drivers with Linux whenever it's possible. As a founder it's tempting to fantasize about building your own universe but everyone comes back to reality eventually.
Even Windows and OSX borrow code from Freetype and such.
Windows had an embedded Prolog interpreter for the network settings, a TCP/IP stack borrowed from BSD, and so on.
Then, with OSX... multiply that for 200.
On Harfbuzz: https://wikiless.org/wiki/HarfBuzz?lang=en
Windows had an embedded Prolog interpreter for the network settings, a TCP/IP stack borrowed from BSD, and so on.
Then, with OSX... multiply that for 200.
On Harfbuzz: https://wikiless.org/wiki/HarfBuzz?lang=en
>Even if it’s a one line change, it could take years to get that upstreamed and spread into various Linux distributions. If you listen to episode 67 about Zig, that was one of Andrew’s motivations behind creating Zig.
No, I'm sorry. This is a very, very bad reason to start a new project from scratch. If you want to avoid bureaucracy then it's not hard to create yet another Linux or BSD distribution, countless people have done it. Once your project grows larger you will find bureaucracy creeping back in again because you have to make some of the same decisions. Do I accept breaking change A versus breaking change B? How do I force people to test a patch across thousands of machines at once before accepting it? How do we reach consensus on subjective things like fonts and icons? And so on.
These projects have plenty of other reasons to exist, it's not like they don't. This is just a poor explanation for why they exist. I hope nobody mentions this nonsense again in an interview.
No, I'm sorry. This is a very, very bad reason to start a new project from scratch. If you want to avoid bureaucracy then it's not hard to create yet another Linux or BSD distribution, countless people have done it. Once your project grows larger you will find bureaucracy creeping back in again because you have to make some of the same decisions. Do I accept breaking change A versus breaking change B? How do I force people to test a patch across thousands of machines at once before accepting it? How do we reach consensus on subjective things like fonts and icons? And so on.
These projects have plenty of other reasons to exist, it's not like they don't. This is just a poor explanation for why they exist. I hope nobody mentions this nonsense again in an interview.
"There are hundreds of Linux distributions."
There probably are hundreds of linux distributions exactly because people do not want to wait years for their change to ship, so they create their own project ...
There probably are hundreds of linux distributions exactly because people do not want to wait years for their change to ship, so they create their own project ...
By his own admission he basically did nothing but coding all day long for most of his life, to the point where if he took a long vacation he'd be worried about getting rusty. For SerenityOS he basically holed up in a cabin for 6 months coding. At dayjob it was "60-80 hours a week", not forced but because he wanted to do it.
That kind of sustained and focused work compounds over time and you just get better and better I guess. Reading stories like his makes me think I'm probably in the wrong industry because I don't enjoy coding that much and definitely have a ton of other things I'd rather do.
That kind of sustained and focused work compounds over time and you just get better and better I guess. Reading stories like his makes me think I'm probably in the wrong industry because I don't enjoy coding that much and definitely have a ton of other things I'd rather do.
I don't think someone who enjoys coding that much is neurotypical, and I think you can be both neurotypical and a great programmer.
> Reading stories like his makes me think I'm probably in the wrong industry because I don't enjoy coding that much and definitely have a ton of other things I'd rather do.
You're fine. Comparing yourself to Andreas Kling vis-a-vis coding is like saying you're going to stop playing the guitar because you're not Jimi Hendrix. Andreas Kling, while impressive and inspiring, is not normal.
Most people, myself included, don't want to do any one thing for 80+ hours a week. That's okay. If you enjoy working as programmer, just keep on trukin' and don't worry about what others are doing.
You're fine. Comparing yourself to Andreas Kling vis-a-vis coding is like saying you're going to stop playing the guitar because you're not Jimi Hendrix. Andreas Kling, while impressive and inspiring, is not normal.
Most people, myself included, don't want to do any one thing for 80+ hours a week. That's okay. If you enjoy working as programmer, just keep on trukin' and don't worry about what others are doing.
Thanks, that is a good analogy and definitely helped me!
I don't think there's anything at all wrong with only coding 40 hours a week or less.
SerenityOS is an amazing accomplishment but it's just a hobby project without massive resources like major projects have.
Most real world apps have tons of devs that don't do 60 hours, the modern dev process just doesn't need it, unless you're doing large things entirely done by small teams.
SerenityOS is an amazing accomplishment but it's just a hobby project without massive resources like major projects have.
Most real world apps have tons of devs that don't do 60 hours, the modern dev process just doesn't need it, unless you're doing large things entirely done by small teams.
Linux's rough edges form a fractal.
A fractal with loops
A fractal with loops is a Chaotic Map.
https://en.wikipedia.org/wiki/List_of_chaotic_maps
Wow thanks for the link! These are beautiful
[deleted]
From serenityos.org:
> ... marriage between the aesthetic of late-1990s productivity software and the power-user accessibility of late-2000s *nix
> ... a system by us, for us, based on the things we like
Come on, just say you want back your Win98/Win2K look'n feel ;)
While I personally like my windows less decorated and more Mac OS-like, I'm quite impressed by the determination and progress of the SerenityOS team. Are there app porting guidelines, or maybe POSIX/LSB, X Windows, or other compat statements?
> ... marriage between the aesthetic of late-1990s productivity software and the power-user accessibility of late-2000s *nix
> ... a system by us, for us, based on the things we like
Come on, just say you want back your Win98/Win2K look'n feel ;)
While I personally like my windows less decorated and more Mac OS-like, I'm quite impressed by the determination and progress of the SerenityOS team. Are there app porting guidelines, or maybe POSIX/LSB, X Windows, or other compat statements?
Yeah there are app porting guidelines: https://github.com/SerenityOS/serenity/blob/master/Ports/REA...
Andreas also uploaded 2 videos on his youtube channel of him porting Diablo and Duke Nukem to SerenityOS
https://www.youtube.com/watch?v=ZOzZ8R4gphE
https://www.youtube.com/watch?v=xy1uynuUyPo
Andreas also uploaded 2 videos on his youtube channel of him porting Diablo and Duke Nukem to SerenityOS
https://www.youtube.com/watch?v=ZOzZ8R4gphE
https://www.youtube.com/watch?v=xy1uynuUyPo
See the Ports directory [1] if you're interested in porting software over. Basically, there's a porting script framework with dependency management that you use to download and (cross-)compile into the Serenity disk image.
There's no X server and we don't want to have WindowServer support the X protocol as a standard feature. If you're porting a GUI app, your best bet is SDL2, for which we have a battle-tested well-working port. However, you can just as well port an X server that talks to WindowServer or the video hardware directly, it's just that that doesn't currently exist. But I think such a thing would be perfectly accepted as a port.
Sidenote: If you want less decorated windows, there's System 7-like themes and other minimalistic ones. Or make your own :^)
[1] https://github.com/SerenityOS/serenity/tree/master/Ports
There's no X server and we don't want to have WindowServer support the X protocol as a standard feature. If you're porting a GUI app, your best bet is SDL2, for which we have a battle-tested well-working port. However, you can just as well port an X server that talks to WindowServer or the video hardware directly, it's just that that doesn't currently exist. But I think such a thing would be perfectly accepted as a port.
Sidenote: If you want less decorated windows, there's System 7-like themes and other minimalistic ones. Or make your own :^)
[1] https://github.com/SerenityOS/serenity/tree/master/Ports
That's wonderful! How much RAM does it need?
My biggest complaint about modern browsers is that I can't load a web page in less than 64 MiB, which is more than my entire computer had when I was running Netscape 3. The browsers are better now, but not in ways that necessarily use more memory.
My biggest complaint about modern browsers is that I can't load a web page in less than 64 MiB, which is more than my entire computer had when I was running Netscape 3. The browsers are better now, but not in ways that necessarily use more memory.
We haven't really begun to optimize for memory usage yet, so it swings wildly depending on the content you're viewing.
At this stage, we're primarily focusing on correctness and compatibility, and performance is mostly a luxury. It's an area I look forward to eventually dealing with though, as it used to be my full-time job at Apple years ago and I have many fun ideas. :^)
At this stage, we're primarily focusing on correctness and compatibility, and performance is mostly a luxury. It's an area I look forward to eventually dealing with though, as it used to be my full-time job at Apple years ago and I have many fun ideas. :^)
What's a rough minimum for a page with some text on it? Are we talking about 64MiB like Chromium, WebKit, or Gecko, or more like 16KiB, 256KiB, 4MiB, or 1 GiB?
I think of memory usage as being more about correctness than performance, though I know that isn't how most people see it. Trying to run a 512MiB process on a 64MiB computer, or a 512GiB process on a 64GiB computer, is just never going to run at a usable speed. Broken software is the limit as latency approaches infinity.
Moreover, I've never seen someone take software that needed 1 GiB to run and modify it incrementally into software that could run in 1 MiB, though I have seen the opposite.
I think of memory usage as being more about correctness than performance, though I know that isn't how most people see it. Trying to run a 512MiB process on a 64MiB computer, or a 512GiB process on a 64GiB computer, is just never going to run at a usable speed. Broken software is the limit as latency approaches infinity.
Moreover, I've never seen someone take software that needed 1 GiB to run and modify it incrementally into software that could run in 1 MiB, though I have seen the opposite.
If I open this HN discussion page in the browser, it currently uses 44MB of private memory.
We can definitely shave a couple of megabytes off of it with some effort, but supporting the contemporary web on a 4MB budget seems infeasible.
We can definitely shave a couple of megabytes off of it with some effort, but supporting the contemporary web on a 4MB budget seems infeasible.
This really depends on design goals of course.
Usually browsers are tend to sacrifice memory consumption (e.g. caching) for rendering speed.
In Sciter, for example, this page on HN occupies less than megabyte in RAM. Sciter has quite different design goals than browsers.
Usually browsers are tend to sacrifice memory consumption (e.g. caching) for rendering speed.
In Sciter, for example, this page on HN occupies less than megabyte in RAM. Sciter has quite different design goals than browsers.
Interesting! I didn't know about Sciter, but to me it sounds like Sciter kind of is a browser, heavyweight DOM and all: https://sciter.com/
Proprietary though, same as Presto, so I guess it's kind of a dead end.
Proprietary though, same as Presto, so I guess it's kind of a dead end.
Nice! Thanks! That's a real improvement over the existing browsers! Yeah, clearly you can't run Slack or Fecebutt in 4MiB, but there's a lot you could do.
Even Lynx takes 14MB of RSS (not all private!) and 25MB of VSZ to load this discussion page, and Links is 9MB/13MB. (Neither of them produces a usable layout, but that's not because they're using a lot of memory.) The page source is 179K, links's "formatted output" of the page is 59 kB, and Firefox tells me it has 2908 HTML elements in it, so it's probably possible to render it in under a meg. I doubt anyone ever will.
Even Lynx takes 14MB of RSS (not all private!) and 25MB of VSZ to load this discussion page, and Links is 9MB/13MB. (Neither of them produces a usable layout, but that's not because they're using a lot of memory.) The page source is 179K, links's "formatted output" of the page is 59 kB, and Firefox tells me it has 2908 HTML elements in it, so it's probably possible to render it in under a meg. I doubt anyone ever will.
https://get.opera.com/pub/opera/win/1218/en/ Opera_1218_en_Setup_x64.exe Default portable install.
27.8MB windowed, one empty tab open
24MB minimized, one empty tab open
35MB windowed, one tab open with this thread loaded and scrolled once up and down
31MB minimized, one tab open with this thread loaded and scrolled once up and down
33MB windowed, one tab open with this thread loaded after restart
29MB minimized, one tab open with this thread loaded after restart
For reference, this page+assets are 187kB. I'd guess the bulk of that 44MB comes from having css and javascript on this page, but a breakdown of what it's using 44 MiB on would be interesting!
Obviously I don't know anything about the Serenity browser, but in the Gecko/WebKit/Blink cases it's mostly startup overhead. A page with a single word on it ends up being more than 44MB.
The DOM is a braindead abortion that should never have been standardized. There's no plausible way to implement it with reasonable efficiency.
The DOM is a braindead abortion that should never have been standardized. There's no plausible way to implement it with reasonable efficiency.
That last part sounds interesting. Can you elaborate?
DOM nodes are mutable and have parent pointers, so there's no way to share structure between duplicated parts of the element tree; JS might mutate them to no longer be duplicates. NodeLists like the .childNodes property (but not the results of, say, .querySelectorAll) are required to be "live", magically updating when you change the document; this code produces 1 even though there's no explicit mutation of c:
If you weren't constrained by W3C DOM compatibility and wanted to trade off lower memory usage for slower small mutations, one extreme strategy would be to maintain chunks of the page tree as Polish-notation bytecode instead of materialized nodes full of pointers; then this discussion-thread page, with its 60 K of text and 3000 HTML elements (expanded to 4758 since my earlier comment, but let's disregard that), might require 80K of RAM instead of 512K or more. So for example
You wouldn't want to store the entire page as a single long string of such bytecode, because that would make tree traversals unreasonably slow. You'd limit the bytecode blocks to 32–256 operations and then build a more conventional node tree or B-tree to knit those leaves together into a whole document. Mutations to the page inside such a leaf block would require rebuilding the block.
In 02022 slower small DOM mutations seems like a very reasonable idea given the prevalence of things like React which tend to rebuild large parts of the page from scratch anyway.
Of course even more extreme points on the time/space tradeoff curve do exist; you could reparse the HTML source from an LZMA-compressed representation on every redraw (compression ratio 8.3 on the current 304kB version of this page, so the 179K incarnation we've been using as an example would be about 22K, and a little HTML minification might squeeze that down further). But my intuition is that even with current CPUs you wouldn't get reasonable performance that way.
Why "512K or more"? The DOM more or less requires pointers to parent, nextSibling, and firstChild, which we can suppose are 64 bits, plus a 64-bit field for node type and padding, which gives us 32 bytes per node; there are about 0.85 text nodes per element, so we have about 5400 nodes for 3000 HTML elements, giving 172.8 kB, and adding in the size of the text gets us past 256KiB. And then we need some space for attributes, cached layout, cached styles, etc. So 512K is easy and the reality is more like 1–4 MiB. For a page that Links renders into 60K of UTF-8 text!
For more markup-heavy pages, which is almost all of them, the ratio is larger.
An intermediate tradeoff would be something like Fredrik Lundh's ElementTree interface for Python, but with iterators over the tree represented as variable-size paths down from the root, permitting hash consing to automatically share structure between all the instances of <td class='ind' indent='4'><img src="s.gif" height="1" width="160"></td>, "reply", " | ", "[–]", and <a href="user?id=akling" class="hnuser">akling</a>. Moreover the ElementTree design doesn't require type-tag fields (though CPython of course does spend memory on them).
In ElementTree each element has string attributes .tag, .text (the leading CDATA text inside the element, possibly None in the Python implementation, which I see as a design error), and .tail (any CDATA text that follows the element, also possibly None in the Python implementation), a list of zero or more child elements, and a possibly-empty string-to-string map (dict) of attributes. There are no parent pointers, though the mutability of ElementTree itself means you still can't share child subtrees that happen to be equal. Child elements are always elements; text and tail are always strings (except where null).
Consider a FORTRAN-style linked-list representation of an ElementTree. For a page tree of up to 65535 elements, 65535 text nodes, and 65535 name-value pairs, you could represent these as arrays of 16-bit integers, assigning each element a 16-bit element ID used to index parallel arrays of 16-bit ints named TAG, TEXT, TAIL, KID, NEXT, and ATTR. KID and NEXT contain element IDs which are -1 to indicate no children or no following siblings, respectively. ATTR may contain -1 (no attributes) or index three parallel arrays named NAME, VALUE, and MORE, the third of which contains -1 or another index into these three tables. TAG, TEXT, TAIL, NAME, and VALUE all index a string table, which is an array of 32-bit ints named START. START indexes an array of bytes named CHARS, and there's an allocation pointer FREE which points to the lowest unused index in START. The bytes of string N start at CHARS[START[N]] and continue to CHARS[START[N+1]]; the first unused byte in CHARS is at CHARS[START[FREE]]. Optionally you can build a hash table over the entries in START to allow the reuse of duplicate strings, since you can't efficiently insert or delete characters within an existing string anyway.
This works out to 12 bytes per element, 6 bytes per attribute, and 4 bytes per string, and it allows mutation just as efficiently as the Python version (i.e., you have to make a copy of any string you want to modify, but you can insert and delete elements in constant time, or graft them onto a different part of the element tree). And it's simpler, not more complex, to iterate over or evaluate CSS-style selector queries on, than the W3C DOM.
With this representation, if you had 3000 elements, 3000 attributes, and 2500 strings totaling 60 kB of text, you'd need 124 kB of memory, plus allocation overhead. And if you're in a reasonably dynamic language you can replace these arrays of 16-bit integers with arrays of 32-bit integers whenever one of these collections goes over 65536 elements. (In Numpy this is quite transparent once it is done.)
let d = document, b = d.body, c = b.childNodes, n = c.length; b.appendChild(d.createElement('div')); console.log(c.length - n);
If you weren't constrained by W3C DOM compatibility and wanted to trade off lower memory usage for slower small mutations, one extreme strategy would be to maintain chunks of the page tree as Polish-notation bytecode instead of materialized nodes full of pointers; then this discussion-thread page, with its 60 K of text and 3000 HTML elements (expanded to 4758 since my earlier comment, but let's disregard that), might require 80K of RAM instead of 512K or more. So for example
<tr class='athing comtr' id='30861517'><td><table border='0'> <tr> <td class='ind'indent='3'>
{ tr # 2 bytes
attr class "athing comtr" # 3 bytes
attr id "30861517" # 4 bytes, plus 16 or so for the string table entry
{ td # 2 bytes
} # 1 byte
{ table
attr border "0"
text " " # 4 bytes, text is inline with prefixed length
{ tr
text " " # 6 bytes
{ td
attr class "ind"
attr indent "3"
...
}
}
}
}
You wouldn't want to store the entire page as a single long string of such bytecode, because that would make tree traversals unreasonably slow. You'd limit the bytecode blocks to 32–256 operations and then build a more conventional node tree or B-tree to knit those leaves together into a whole document. Mutations to the page inside such a leaf block would require rebuilding the block.
In 02022 slower small DOM mutations seems like a very reasonable idea given the prevalence of things like React which tend to rebuild large parts of the page from scratch anyway.
Of course even more extreme points on the time/space tradeoff curve do exist; you could reparse the HTML source from an LZMA-compressed representation on every redraw (compression ratio 8.3 on the current 304kB version of this page, so the 179K incarnation we've been using as an example would be about 22K, and a little HTML minification might squeeze that down further). But my intuition is that even with current CPUs you wouldn't get reasonable performance that way.
Why "512K or more"? The DOM more or less requires pointers to parent, nextSibling, and firstChild, which we can suppose are 64 bits, plus a 64-bit field for node type and padding, which gives us 32 bytes per node; there are about 0.85 text nodes per element, so we have about 5400 nodes for 3000 HTML elements, giving 172.8 kB, and adding in the size of the text gets us past 256KiB. And then we need some space for attributes, cached layout, cached styles, etc. So 512K is easy and the reality is more like 1–4 MiB. For a page that Links renders into 60K of UTF-8 text!
For more markup-heavy pages, which is almost all of them, the ratio is larger.
An intermediate tradeoff would be something like Fredrik Lundh's ElementTree interface for Python, but with iterators over the tree represented as variable-size paths down from the root, permitting hash consing to automatically share structure between all the instances of <td class='ind' indent='4'><img src="s.gif" height="1" width="160"></td>, "reply", " | ", "[–]", and <a href="user?id=akling" class="hnuser">akling</a>. Moreover the ElementTree design doesn't require type-tag fields (though CPython of course does spend memory on them).
In ElementTree each element has string attributes .tag, .text (the leading CDATA text inside the element, possibly None in the Python implementation, which I see as a design error), and .tail (any CDATA text that follows the element, also possibly None in the Python implementation), a list of zero or more child elements, and a possibly-empty string-to-string map (dict) of attributes. There are no parent pointers, though the mutability of ElementTree itself means you still can't share child subtrees that happen to be equal. Child elements are always elements; text and tail are always strings (except where null).
Consider a FORTRAN-style linked-list representation of an ElementTree. For a page tree of up to 65535 elements, 65535 text nodes, and 65535 name-value pairs, you could represent these as arrays of 16-bit integers, assigning each element a 16-bit element ID used to index parallel arrays of 16-bit ints named TAG, TEXT, TAIL, KID, NEXT, and ATTR. KID and NEXT contain element IDs which are -1 to indicate no children or no following siblings, respectively. ATTR may contain -1 (no attributes) or index three parallel arrays named NAME, VALUE, and MORE, the third of which contains -1 or another index into these three tables. TAG, TEXT, TAIL, NAME, and VALUE all index a string table, which is an array of 32-bit ints named START. START indexes an array of bytes named CHARS, and there's an allocation pointer FREE which points to the lowest unused index in START. The bytes of string N start at CHARS[START[N]] and continue to CHARS[START[N+1]]; the first unused byte in CHARS is at CHARS[START[FREE]]. Optionally you can build a hash table over the entries in START to allow the reuse of duplicate strings, since you can't efficiently insert or delete characters within an existing string anyway.
This works out to 12 bytes per element, 6 bytes per attribute, and 4 bytes per string, and it allows mutation just as efficiently as the Python version (i.e., you have to make a copy of any string you want to modify, but you can insert and delete elements in constant time, or graft them onto a different part of the element tree). And it's simpler, not more complex, to iterate over or evaluate CSS-style selector queries on, than the W3C DOM.
With this representation, if you had 3000 elements, 3000 attributes, and 2500 strings totaling 60 kB of text, you'd need 124 kB of memory, plus allocation overhead. And if you're in a reasonably dynamic language you can replace these arrays of 16-bit integers with arrays of 32-bit integers whenever one of these collections goes over 65536 elements. (In Numpy this is quite transparent once it is done.)
I missed the editing window, but here's a simple example of ElementTree in Python; consider what it would take to do this in JS with the DOM if you had to implement .innerText yourself:
On the other hand, without the dopey None case I objected to above, you wouldn't need the "or ''".
>>> from xml.etree import ElementTree
>>> def text(e):
... return (e.text or '') + ''.join(
text(kid) for kid in e.getchildren()) + (e.tail or '')
...
>>> text(ElementTree.fromstring('<p>My <b>Malamute</b> is <i>really</i> hairy.</p>'))
'My Malamute is really hairy.'
>>> def find(e, clase):
... if e.get('class') == clase: yield e
... for kid in e.getchildren():
... for nieto in find(kid, clase): yield nieto
...
>>> list(find(ElementTree.fromstring('<p>My <b class="dog">Malamute</b> is <i>really</i> hairy.</p>'), 'dog'))
[<Element 'b' at 0x7f14717c7a10>]
On the other hand, without the dopey None case I objected to above, you wouldn't need the "or ''".
You aren't implementing innerText, you're implementing textContent. Consider the HTML
a<b>c</b>d<div>e<div>f</div></div>. Using textContent results in "acdef", while innerText results in "acd\ne\nf". Implementing textContent is easy:
function getText(node, returnArray){
const a = Array.prototype.map.call(node.childNodes, e=>e.nodeType==3?e.data:getText(e, true))
return returnArray?a:a.flat(Infinity).join("")
}
let getText=(n,f=(n,a)=>[].map.call(n.childNodes,e=>e.nodeType==3?e.data:f(e,1)))=>f(n,f).flat(1e333).join("")
Very nice! And thank you for the correction about innerText.
Still, I think that
Still, I think that
let getText = n => n.text + n.getchildren().map(getText).join('') + n.tail
let getText=(n,f=(n,a)=>[].map.call(n.childNodes,e=>e.nodeType==3?e.data:f(e,1)))=>f(n,f).flat(1e333).join("")
Most of the reason it's more complicated is because I made it return arrays when recursing and only join at the end because that probably doesn't need as many allocations. The rest of the complication is because the DOM has separate text nodes and the library you're using doesn't seem to. (Oh, and also NodeLists don't have .map so we use the .map from the array prototype) Here's a non-optimized version:
let getText = n =>[].map.call(n.childNodes,e => e.nodeType == 3 ? e.data : getText(e)).join("")The lowest bound would be the size of the texture the page is rendered into, no ? If you're on a 4k screen an uncompressed rgba pixmap is already 31MB... And that's really just the raw pixel storage which needs to be associated with your process
You don't have to render the whole page to a pixmap at once; it's very reasonable for a display-list representation of the page using a font atlas to be a tiny fraction of that size, maybe 8 bytes per character, and a GPU shader can render the RGBA pixmap from a spatially partitioned display list on demand. 2144 characters of text on my 1920×1080 display extrapolates to 17152 characters on a 4K display, which would be 140K of display-list data. 0.14 MB is a lot less than 31MB.
(You need additional display-list items for things like the #ff6600 bar at the top and the #f6f6ef background, but those occupy insignificant space even compared to the 2144 characters. The Yahoo/Y-combinator logo and the arrows also add a little bit.)
Of course #notallpages are mostly text, and many of them will require intermediate storage for large photos, <canvas>es, or screenshots of faked Tweets.
If you're on a smaller computer you might render one scan line at a time from a display list consisting of strings rather than individual characters. Those 2144 characters are in 29 lines, so the display list might be under 3K, and a 400-pixel 1-bit-per-pixel scan line is 50 bytes. If you're generating PAL this way you have 64 μs to render each line, which is about 1000–6000 instructions on current microcontrollers, and you can maybe manage 450 color pixels, another 2K or so of raw pixel storage.
(You need additional display-list items for things like the #ff6600 bar at the top and the #f6f6ef background, but those occupy insignificant space even compared to the 2144 characters. The Yahoo/Y-combinator logo and the arrows also add a little bit.)
Of course #notallpages are mostly text, and many of them will require intermediate storage for large photos, <canvas>es, or screenshots of faked Tweets.
If you're on a smaller computer you might render one scan line at a time from a display list consisting of strings rather than individual characters. Those 2144 characters are in 29 lines, so the display list might be under 3K, and a 400-pixel 1-bit-per-pixel scan line is 50 bytes. If you're generating PAL this way you have 64 μs to render each line, which is about 1000–6000 instructions on current microcontrollers, and you can maybe manage 450 color pixels, another 2K or so of raw pixel storage.
> and a GPU shader can render the RGBA pixmap from a spatially partitioned display list on demand.
... but... the GPU shader will need a surface to render into, no ? do you know of any OS where asking for a 1000x1000 surface does not allocate space for that in normal, non-GPU RAM ? I believe that this uses RAM on any mainstream desktop OS
... but... the GPU shader will need a surface to render into, no ? do you know of any OS where asking for a 1000x1000 surface does not allocate space for that in normal, non-GPU RAM ? I believe that this uses RAM on any mainstream desktop OS
The GPU shader could in theory be rendering into a tile that gets squirted out to the screen by the RAMDACs and then reused, but I think you're right that in practice the GPU has at least one full-screen framebuffer, usually two or, dismayingly, three. Often the monitor has an additional two or three!
I'm not sure it's fair to charge that framebuffer to the browser, though. The windowing system needs to use the same 31MB before you start the browser up, after all.
I don't know the answer to your question about mainstream desktop OSes and space allocation for shaders for windows that aren't being displayed. Maybe someone who knows more than you or me can chime in.
I'm not sure it's fair to charge that framebuffer to the browser, though. The windowing system needs to use the same 31MB before you start the browser up, after all.
I don't know the answer to your question about mainstream desktop OSes and space allocation for shaders for windows that aren't being displayed. Maybe someone who knows more than you or me can chime in.
> The windowing system needs to use the same 31MB before you start the browser up, after all.
every process needs its own surface for compositing though. If you open 200 4k windows you'll get 200*31MB, they aren't going to share the memory with the desktop one
every process needs its own surface for compositing though. If you open 200 4k windows you'll get 200*31MB, they aren't going to share the memory with the desktop one
That's definitely one way to do it, and now that you mention it I do know that there are definitely things that do it that way, but it might not be a good one. Windows that aren't visible don't need their output surface to be materialized, and introducing a compositing step after your 4k window renders adds an extra 11 gigabytes per second of memory bandwidth at 120fps, and probably a few precious milliseconds of latency. In the limit of inexpensive rendering — which alpha-blending a few thousand rects from a font atlas might approach — it doubles the battery drain needed to redraw the screen.
Your screen likely has gotten better in ways that necessarily use more memory: more pixels, more bit depth means larger pictures, larger font caches (because of larger characters and anti-aliasing), etc.
The pages you look at also have gotten ‘better’ in ways that necessarily use more memory. I don’t think you regularly loaded megabytes of JavaScript.
Finally, your browser usage likely has gotten ‘better’ in ways that necessarily use more memory. I guess you have more tabs open than you ever had in that 64 MiB.
The pages you look at also have gotten ‘better’ in ways that necessarily use more memory. I don’t think you regularly loaded megabytes of JavaScript.
Finally, your browser usage likely has gotten ‘better’ in ways that necessarily use more memory. I guess you have more tabs open than you ever had in that 64 MiB.
While there is something to this, and antialiased fonts and CJKV rendering are particularly beneficial, I mostly don't agree about necessarily using more memory (see https://news.ycombinator.com/item?id=30872388). We're talking about orders of magnitude more memory than the screen contents.
As for JS, on most pages the only benefit of those megabytes of JavaScript is that I need to use uBlock Origin and/or Reader Mode to read what I'm actually interested in, the page jumps around at random while I'm trying to read it, Twitter tries to extort me into logging in, DoubleClick and reCaptcha can fingerprint my GPU, etc. Also, a megabyte of minified JS might reasonably compile down into a megabyte of bytecode or 4 MiB of native code, not 64 MiB or 128 MiB. JS's execution model is kind of inherently memory-hungry, though.
64 MiB is for one tab.
As for JS, on most pages the only benefit of those megabytes of JavaScript is that I need to use uBlock Origin and/or Reader Mode to read what I'm actually interested in, the page jumps around at random while I'm trying to read it, Twitter tries to extort me into logging in, DoubleClick and reCaptcha can fingerprint my GPU, etc. Also, a megabyte of minified JS might reasonably compile down into a megabyte of bytecode or 4 MiB of native code, not 64 MiB or 128 MiB. JS's execution model is kind of inherently memory-hungry, though.
64 MiB is for one tab.
Try Ultralight web engine or K-Meleon on Goanna, they are really lightweight.
How much memory do they need to load this discussion thread page?
K-Meleon uses just 58.9 MB of RAM: https://i.postimg.cc/Jz1cy8tG/K-Meleon.png
I object strongly to the use of the word "just" in that sentence!
Basically that's the same memory usage as Blink, WebKit, or Gecko.
Basically that's the same memory usage as Blink, WebKit, or Gecko.
Great work by everyone involved. SerenityOS is for me by far the most interesting project in tech right now. It's like watching a different branch of reality evolving. The recent browser optimization videos by Andreas himself have been great. A great moment in particular was seeing Andreas' satisfaction when he go smooth hover effects on links[0], a single moment where he is (presumably) struck with how far his project has come.
0: https://youtu.be/KbTrgXePbwo
0: https://youtu.be/KbTrgXePbwo
Andreas’ excitement is infectious. I find myself sometimes smiling in an empty room watching his reaction to getting something working.
Related:
Serenity OS: Interview - https://news.ycombinator.com/item?id=30214371 - Feb 2022 (52 comments)
SerenityOS demo at Handmade Seattle 2021 [video] - https://news.ycombinator.com/item?id=29270776 - Nov 2021 (180 comments)
SerenityOS: Year 3 in Review - https://news.ycombinator.com/item?id=28817599 - Oct 2021 (46 comments)
Not-a-Linux distro review: SerenityOS is a Unix-y love letter to the ‘90s - https://news.ycombinator.com/item?id=28219800 - Aug 2021 (113 comments)
SerenityOS: Graphical Unix-like operating system with classic 90s UI - https://news.ycombinator.com/item?id=28206840 - Aug 2021 (129 comments)
I quit my job to focus on SerenityOS full time - https://news.ycombinator.com/item?id=27317655 - May 2021 (249 comments)
SerenityOS: Writing a Full Chain Exploit - https://news.ycombinator.com/item?id=26115141 - Feb 2021 (9 comments)
SerenityOS: A love letter to '90s user interfaces with a Unix-like core - https://news.ycombinator.com/item?id=23911180 - July 2020 (1 comment)
SerenityOS Update (April 2020) - https://news.ycombinator.com/item?id=23037581 - April 2020 (1 comment)
Introduction to SerenityOS Programming - https://news.ycombinator.com/item?id=22479132 - March 2020 (43 comments)
Pledge() and Unveil() in SerenityOS - https://news.ycombinator.com/item?id=22116914 - Jan 2020 (28 comments)
CTF writeup: First published SerenityOS kernel exploit - https://news.ycombinator.com/item?id=21918351 - Dec 2019 (2 comments)
SerenityOS: From Zero to HTML in a Year - https://news.ycombinator.com/item?id=21212294 - Oct 2019 (52 comments)
Serenity OS update (August 2019) [video] - https://news.ycombinator.com/item?id=20851356 - Sept 2019 (2 comments)
SerenityOS – a graphical Unix-like OS for x86, with 90s aesthetics - https://news.ycombinator.com/item?id=19986126 - May 2019 (179 comments)
Serenity OS Demo (April 2019) - https://news.ycombinator.com/item?id=19813417 - May 2019 (1 comment)
Serenity: x86 Unix-like operating system for IBM PC-compatibles - https://news.ycombinator.com/item?id=19537807 - March 2019 (83 comments)
Serenity OS: Interview - https://news.ycombinator.com/item?id=30214371 - Feb 2022 (52 comments)
SerenityOS demo at Handmade Seattle 2021 [video] - https://news.ycombinator.com/item?id=29270776 - Nov 2021 (180 comments)
SerenityOS: Year 3 in Review - https://news.ycombinator.com/item?id=28817599 - Oct 2021 (46 comments)
Not-a-Linux distro review: SerenityOS is a Unix-y love letter to the ‘90s - https://news.ycombinator.com/item?id=28219800 - Aug 2021 (113 comments)
SerenityOS: Graphical Unix-like operating system with classic 90s UI - https://news.ycombinator.com/item?id=28206840 - Aug 2021 (129 comments)
I quit my job to focus on SerenityOS full time - https://news.ycombinator.com/item?id=27317655 - May 2021 (249 comments)
SerenityOS: Writing a Full Chain Exploit - https://news.ycombinator.com/item?id=26115141 - Feb 2021 (9 comments)
SerenityOS: A love letter to '90s user interfaces with a Unix-like core - https://news.ycombinator.com/item?id=23911180 - July 2020 (1 comment)
SerenityOS Update (April 2020) - https://news.ycombinator.com/item?id=23037581 - April 2020 (1 comment)
Introduction to SerenityOS Programming - https://news.ycombinator.com/item?id=22479132 - March 2020 (43 comments)
Pledge() and Unveil() in SerenityOS - https://news.ycombinator.com/item?id=22116914 - Jan 2020 (28 comments)
CTF writeup: First published SerenityOS kernel exploit - https://news.ycombinator.com/item?id=21918351 - Dec 2019 (2 comments)
SerenityOS: From Zero to HTML in a Year - https://news.ycombinator.com/item?id=21212294 - Oct 2019 (52 comments)
Serenity OS update (August 2019) [video] - https://news.ycombinator.com/item?id=20851356 - Sept 2019 (2 comments)
SerenityOS – a graphical Unix-like OS for x86, with 90s aesthetics - https://news.ycombinator.com/item?id=19986126 - May 2019 (179 comments)
Serenity OS Demo (April 2019) - https://news.ycombinator.com/item?id=19813417 - May 2019 (1 comment)
Serenity: x86 Unix-like operating system for IBM PC-compatibles - https://news.ycombinator.com/item?id=19537807 - March 2019 (83 comments)
Indeed. It's beyond impressive, especially the web browser from scratch and the whole idea of operating systems that are not typical, yet another Linux distro stuff and having an integrated consistent user interface and open source like RedoxOS, Haiku, Fuchsia, etc has.
But let's be a bit realistic, how long can we expect this to be a reliable daily driver on real machines and not stuck on a VM? It has taken more than a decade for one of them to even run reliably on several PCs and everyone is still waiting for another to not be ridden on a VM and actually run directly on real hardware. That is me not even talking about the apps there.
But if I have to choose one that will achieve all of that in the shortest time, then it would be Fuchsia wouldn't it?
But let's be a bit realistic, how long can we expect this to be a reliable daily driver on real machines and not stuck on a VM? It has taken more than a decade for one of them to even run reliably on several PCs and everyone is still waiting for another to not be ridden on a VM and actually run directly on real hardware. That is me not even talking about the apps there.
But if I have to choose one that will achieve all of that in the shortest time, then it would be Fuchsia wouldn't it?
The challenge here would be getting all those miscellaneous hardware drivers to be ported to SerenityOS. Some hacker might write Serenity drivers for their particular desktop, but that won't do you any good unless you have the exact same hardware. A Raspberry Pi might be a good target, but Serenity OS is currently x86 only. So realistically, Serenity on random consumer hardware is unlikely to ever happen.
Fuchsia is in a similar situation. Google may start pushing Fuchsia on some limited set of hardware, but I don't see a reason for them to start writing drivers for anything other than hardware from Google or Google partners.
Now, I could see SerenityOS as an option inside of something like Qubes OS. Here, the hardware is abstracted so you could run it on whatever. There may be some limited security through obscurity benefit to running an OS so far off the beaten path.
Like you, I'm dumbfounded by the achievement of Serenity OS. According to the Readme, Serenity OS is "a system by us, for us, based on the things we like." I don't know that making Serinity OS a daily driver for anyone who isn't interested in hacking on it is an actual goal for Andreas.
Fuchsia is in a similar situation. Google may start pushing Fuchsia on some limited set of hardware, but I don't see a reason for them to start writing drivers for anything other than hardware from Google or Google partners.
Now, I could see SerenityOS as an option inside of something like Qubes OS. Here, the hardware is abstracted so you could run it on whatever. There may be some limited security through obscurity benefit to running an OS so far off the beaten path.
Like you, I'm dumbfounded by the achievement of Serenity OS. According to the Readme, Serenity OS is "a system by us, for us, based on the things we like." I don't know that making Serinity OS a daily driver for anyone who isn't interested in hacking on it is an actual goal for Andreas.
> I don't know that making SerenityOS a daily driver for anyone who isn't interested in hacking on it is an actual goal for Andreas.
My main goal is to make a system for myself to use. I'm not particularly interested in working on stuff that doesn't affect my own use cases.
However, SerenityOS is not a one-man project. There are hundreds of other developers, all with their own individual goals, each putting their time and effort into making the system into something they would like to see as well.
I have no idea what will come out of this in the long run, but it's the most fun I've ever had, so I'm just gonna keep going and see what happens. :^)
My main goal is to make a system for myself to use. I'm not particularly interested in working on stuff that doesn't affect my own use cases.
However, SerenityOS is not a one-man project. There are hundreds of other developers, all with their own individual goals, each putting their time and effort into making the system into something they would like to see as well.
I have no idea what will come out of this in the long run, but it's the most fun I've ever had, so I'm just gonna keep going and see what happens. :^)
In a world seemingly going down hill, SerenityOS brings back positive thinking for me. Time doesn't matter so much and the projects speed is already most impressive.
I'm planning to port some of my software in the home automation Zigbee/Matter space to SerenityOS when OpenGL progress is far enough.
I'm planning to port some of my software in the home automation Zigbee/Matter space to SerenityOS when OpenGL progress is far enough.
I think this misunderstands the motives of this project. Its not trying to win any popularity or usability awards.
I see it more as art honestly, even if it does end up having good utility, it will very much always be an encapsulation of this guys passion and expression.
Don't get too poisoned by the business world! Computers dont need to be just efficiency machines.
I see it more as art honestly, even if it does end up having good utility, it will very much always be an encapsulation of this guys passion and expression.
Don't get too poisoned by the business world! Computers dont need to be just efficiency machines.
(Skip to 0:40 for initial performance, and to 56:00 for when it turns snappy.)
Corecursive did a podcast with the creator, was interesting
Edit: originally commented on uploading frequency but looks like they only do once a month
Edit: originally commented on uploading frequency but looks like they only do once a month
Discussed here:
Serenity OS: Interview - https://news.ycombinator.com/item?id=30214371 - Feb 2022 (52 comments)
Serenity OS: Interview - https://news.ycombinator.com/item?id=30214371 - Feb 2022 (52 comments)
By the way, I'd love to see a reference implementation of a web browser in a pure functional language like Haskell (it doesn't need to be fast, just correct). I actually have the opinion that the W3C should provide such a reference implementation.
I found out about SerenityOS and Andreas since Andy Kelley retweets him all the time. Is Zig somehow a part of SerenityOS (or its future plans), or is it simply Andy respecting / signal boosting another systems hacker?
They're part of the same group of systems programmers aligned in their values of how to build software. Andreas was featured [0] at our conference that Andrew Kelley gave a talk for. (Though I believe they were friends before this.)
Someone mentioned BoksOS. That one is explicitly using Zig and made a conference demo [1] too.
[0] https://media.handmade-seattle.com/serenityos
[1] https://media.handmade-seattle.com/boksos
Someone mentioned BoksOS. That one is explicitly using Zig and made a conference demo [1] too.
[0] https://media.handmade-seattle.com/serenityos
[1] https://media.handmade-seattle.com/boksos
I'm simply respecting / signal boosting another systems hacker
https://boksos.com/ is a project OS being written in Zig
No, SerenityOS is strictly C++
Which is both very impressive given everything that is being produced, but also a bit scary and sad in 2022.
There is ample evidence that even very excellent developers and teams can't avoid the footguns of c++ and that leads issues down the line.
If we just look at the browser, they seem to make much faster progress than Servo, but there is no doubt it will have security flaws.
There is ample evidence that even very excellent developers and teams can't avoid the footguns of c++ and that leads issues down the line.
If we just look at the browser, they seem to make much faster progress than Servo, but there is no doubt it will have security flaws.
Feels like this might be an example of "worse is better".
Or alternately, that the community that SerenityOS has built and the joy they find in tinkering matters more than their technical foundations, in terms of getting something built that works and is maintained/maintainable. Servo looks like it could have been a technically better browser engine, but it seems the window for it becoming relevant is closing, while the future looks bright for SerenityOS's Browser. (I wonder how different things would be if Servo had reached the point where it was easy to run inside of a browser, in terms of dogfooding and getting people excited about it.)
What I would like to see is SerenityOS's joy and welcoming, vibrant community using better technology (in terms of security, if nothing else). Zig seems like a candidate for this, although people may debate its security features and technical merits. I'd love to see more projects like these.
Or alternately, that the community that SerenityOS has built and the joy they find in tinkering matters more than their technical foundations, in terms of getting something built that works and is maintained/maintainable. Servo looks like it could have been a technically better browser engine, but it seems the window for it becoming relevant is closing, while the future looks bright for SerenityOS's Browser. (I wonder how different things would be if Servo had reached the point where it was easy to run inside of a browser, in terms of dogfooding and getting people excited about it.)
What I would like to see is SerenityOS's joy and welcoming, vibrant community using better technology (in terms of security, if nothing else). Zig seems like a candidate for this, although people may debate its security features and technical merits. I'd love to see more projects like these.
I agree with you about the project being a joy for the developers.
But as a user, in no way I would rely on a browser started in 2020 written in c++ (or in zig, given other comments about its security characteristics). Keep in mind that gecko/webkit were written initially in c++ because c++ was the best language available at the time for these projects. This is not true anymore.
But as a user, in no way I would rely on a browser started in 2020 written in c++ (or in zig, given other comments about its security characteristics). Keep in mind that gecko/webkit were written initially in c++ because c++ was the best language available at the time for these projects. This is not true anymore.
The beauty is when you build your own OS with it's own desktop environment, and browser and tools from scratch you can use the language you feel is appropriate. Would you write a brand new project in a language you don't feel comfortable with just because it is perceived as "safer"? Especially when the project was just for fun, and really to help the creator get through some tough times in their life. Like he didn't start the project to compete with mainstream OSes or browsers. This is just a terrible take especially considering you probably use an OS written in C and a browser written in C++.
AFAIK SerenityOS has no interest in users, and instead targets developers exclusively.
Webkit is still C++, and with its market share slowly reaching zero (now at about 3%), the 10% of Rust code in Gecko hardly matter.
zig has many of the same footguns as C++ and C; it just has better developer ergonomics.
Use after free, double free, invalid stack RW, uninitialized data, race conditions, etc. They're all possible to be found in Zig programs, because the language doesn't provide assurances against them.
Use after free, double free, invalid stack RW, uninitialized data, race conditions, etc. They're all possible to be found in Zig programs, because the language doesn't provide assurances against them.
(Have never written Zig)
Does the design of the language make them less (or more) likely to occur, though? e.g. all these things are possible in Forth too, but the design of the language definitely seems to conspire to make them less likely than C in my experience (I probably have about as many hours in each now? Roughly 1k, maybe 1.5k?).
(I suspect that this is the case in Forth because the stack gives a "linear-like feel" to most code; it's more obvious that you're accidentally not freeing something, because you need to explicitly discard it.)
Does the design of the language make them less (or more) likely to occur, though? e.g. all these things are possible in Forth too, but the design of the language definitely seems to conspire to make them less likely than C in my experience (I probably have about as many hours in each now? Roughly 1k, maybe 1.5k?).
(I suspect that this is the case in Forth because the stack gives a "linear-like feel" to most code; it's more obvious that you're accidentally not freeing something, because you need to explicitly discard it.)
The design doesn't do anything particularly different or cumbersome regarding memory and ownership, so I'll hazard a guess and say no, it doesn't make it less likely.
Not sure why you are downvoted, you are totally correct about the footguns that C++ has and why the same issues found in the other browsers will still apply here.
> If we just look at the browser, they seem to make much faster progress than Servo, but there is no doubt it will have security flaws.
Servo was supposed to be the promise of better security in a new browser thanks to Rust. Unfortunately in reality that was just either hype or it was just slow moving progress or perhaps both.
But yes the SerenityOS browser seems to be moving faster than servo whilst sacrificing security.
> If we just look at the browser, they seem to make much faster progress than Servo, but there is no doubt it will have security flaws.
Servo was supposed to be the promise of better security in a new browser thanks to Rust. Unfortunately in reality that was just either hype or it was just slow moving progress or perhaps both.
But yes the SerenityOS browser seems to be moving faster than servo whilst sacrificing security.
> Servo was supposed to be the promise of better security in a new browser thanks to Rust. Unfortunately in reality that was just either hype or it was just slow moving progress or perhaps both.
AIUI, Servo started as a project to prove out Rust that would also be a research testing ground for working on prototypes to improve aspects of Firefox. I don't think Servo was ever intended to be a browser on its own. Although others may have imputed that goal on to the project.
(I wasn't involved in Servo, but was in Rust, so was pretty adjacent to it.)
AIUI, Servo started as a project to prove out Rust that would also be a research testing ground for working on prototypes to improve aspects of Firefox. I don't think Servo was ever intended to be a browser on its own. Although others may have imputed that goal on to the project.
(I wasn't involved in Servo, but was in Rust, so was pretty adjacent to it.)
[deleted]
The "AK" standard library that they use is extremely good and very dynamic. Much better than the C++ STL
Polemic opinion, the C++ libraries that used to be bundled with compilers, like Turbo Vision, OWL, VCL, PowerPlant, CSet++,... were much convenient and safer to use by default than STL, but things are as they are.
Maybe in 20 years we'll be hacking on this on our desktops while every other user OS is still an heroing for the "grandma's tablet" market.
I don't know, I'm trying to be a bit realistic about it when it comes to another new OS that can run on real hardware and is reliable enough as a daily driver. Might take more than two decades for it to be as usable as macOS.
By then we would be just still running Windows / macOS on our ARM desktops / laptops, Fuchsia on our phones, tablets and chromebooks, Linux still stuck on the server and everything else stuck in a VM or simply abandoned.
By then we would be just still running Windows / macOS on our ARM desktops / laptops, Fuchsia on our phones, tablets and chromebooks, Linux still stuck on the server and everything else stuck in a VM or simply abandoned.
In 20 years desktop users will look back at Windows 11 as "the good old days"
[deleted]
Nah, most devs with be using their tablet playgrounds, as thin clients to Cloud OSes.
I'm amazed how fast Serenity has been gaining momentum lately. How easy is it to port applications from Linux and what bindings are available for this?
Not bad really.. here Andreas ports bash https://www.youtube.com/watch?v=QNK8vK-nkkg
The amount of improvement since Andreas started making those Discord videos is remarkable. Awesome work everybody!
Amazing work from Andreas and the SerenityOS community, it is amazing how far the project has come in such a short amount of time, looking forward to the future of the project :^)
Acid3 test itself is pretty old though. There are now stuff that it doesn't cover. I think people should come up with an Acid4 test for that.
Wow! That was quick given their resources! It wasn’t many weeks ago I saw their browser do 50’ish on the test.
Indeed, we were at 50/100 on February 21st:
https://twitter.com/awesomekling/status/1495875749693243406
And here's a Quote Tweet chain as I was posting progress updates from 99/100 all the way back to 50/100: https://twitter.com/awesomekling/status/1507135024461721605
And here's a Quote Tweet chain as I was posting progress updates from 99/100 all the way back to 50/100: https://twitter.com/awesomekling/status/1507135024461721605
[deleted]
If I wanted to work on Serenity OS, how long does it take to compile?
Of course it depends on your system but it's more a matter of minutes than of hours. It's a really enjoyable experience to hack on the system and being able to rebuild in seconds. Just have a look at some SerenityOS hacking videos, they are truly inspiring.
From my experience building it under WSL on a reasonably recent laptop: from cloning the Git repo to seeing SerenityOS pop up in QEMU, maybe half an hour. A lot of it is downloading and building the toolchain.
And then incremental rebuilds (when I go and pull the latest changes once in a while to see what's new) take anywhere between 1-10 minutes, depending on what changed exactly. YMMV.
For an entire operating system, it's pretty cool already! I wonder if C++20 modules will take it down some more, it's been mentioned a few times as something to investigate.
And then incremental rebuilds (when I go and pull the latest changes once in a while to see what's new) take anywhere between 1-10 minutes, depending on what changed exactly. YMMV.
For an entire operating system, it's pretty cool already! I wonder if C++20 modules will take it down some more, it's been mentioned a few times as something to investigate.
Is the SerenityOS Browser web engine a fork of some other browser engine or is it written from scratch?
Everything in SerenityOS is written from scratch, it’s a point of SerenityOS that it uses no external libraries in its default install and creates & maintains all source code for the entire OS and all built-in apps, inc. SerenityOS Browser.
[deleted]
Does it use GPU for rendering?
JIT engine is impressive too.
Serenity Now!! Serenity Now!!
The test should no longer be used:
> Acid3, in particular, contains some controversial tests and no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers. The tests remain available for historical purposes and for use by browser vendors. It would be inappropriate, however, to use them as part of a certification process, especially for mobile browsers.
Source: http://www.acidtests.org/
> Acid3, in particular, contains some controversial tests and no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers. The tests remain available for historical purposes and for use by browser vendors. It would be inappropriate, however, to use them as part of a certification process, especially for mobile browsers.
Source: http://www.acidtests.org/
I don't think the quote you quoted justifies your conclusion that Acid3 should no longer be used for anything. There's a lot of the web for which Acid3 levels of standards compliance is adequate for readability, and Acid3 enables a very quick feedback loop during development.
https://news.ycombinator.com/item?id=18941348