91–100 of 264 posts
Earlier quoted context omitted.
Alright it's clear you're only here to rile people up. Not sure why you think that's appropriate here.
It's appropriate because it will improve your thinking to consider that I might just be right. Edit: I happened to see your response since deleted. Don't worry, I'm not offended. I will say that HN at its best invites intellectual exploration. Take all your comments in this thread and look at them. What thoughts did you provoke? What did you add?
Earlier quoted context omitted.
Just a nitpick, but I'm pretty sure Opera was gutted of engineers as well after their acquisition fiasco with that Chinese outfit. I don't think they had as much manpower as the good ol days AND not enough manpower to compete with the old engine. I'm on mobile or I'd go find a source, but I'm fairly certain some key people left before all that went down. Not that maintaining a web browser is easy, but they WERE doing…
It's not just Opera though. Microsoft Edge is using also Webkit. I'm legit worried that if Mozilla ever tanks, we could have a complete WebKit browser monoculture.
I'm worried about that as well, but it's not really fair to attribute blame to most people at Opera, especially prior to the China thing. Things were okay there for a long time before that.
And yet some people say that C++ is not a productive language :)
OS/2 with C/Set++, Motif++ on UNIX, BeOS, Symbian, Windows with OWL/VCL/MFC, Mac OS with MPW/PowerPlant, Copland (granted this one went nowhere).
Then FOSS UNIX with C everywhere as part of GNU manifesto, the Java million dollar push happened, and the rest is history.
I'm curious, how can someone implement device drivers (without knowing hardware details.) for a self-made OS like this?
1. Start with a QEMU emulated device. QEMU is more forgiving than real hardware and you can study, understand, and debug the "hardware impersonation side" of the QEMU code to see what happens when you set a bit in some register.
2. Pick a simple device. Don't start with the USB stack or Ethernet. Maybe try to reimplement the UART driver first.
3. Don't freak out about "device driver architecture" stuff like whether you need lock-free queues or allocation-free algorithms or ring buffers or... whatever. Just get it working.
4. Write a userspace program that uses the driver you'd like to see working. That'll motivate you to finish it.
5. Repeat. Until eventually you know how to write device drivers. :)
What's the explanation for this?
Earlier quoted context omitted.
Even if you somehow manage to fully implement all of JS with decent performance, you will finally hit the wall with video DRM - your users will never be able to watch Netflix, for example.
Widevine is the first DRM to be really open to be ported. They suck the least of all DRM systems. This is the DRM used in the Chrome browser and Firefox. I think it would be possible (not easy, or logical, but possible) that Serenity Browser gets Widevine at some point.