Pyra without decent web browser?


Currently, Debian Testing is "frozen". This means no new upstream versions will enter it. This creates a tailback that ripples into Unstable.
Not all bugs are security-relevant. Those that are, are patched by the Debian maintainers into the versions in Stable. For those types of software, where patching is not possible or not practical, there is the Debian security repository. Firefox and Chromium reside here for example.
This approach however is time-consuming, so it's not done for a lot of packages. "Minor" browsers don't get that luxury.

If you build your own packages from newer upstream sources on top of Debian Stable's well hung package base, then you'll have to make sure on your own that there are no ABI breaks. This is why I wouldn't want to build my own newer browser packages and why I wouldn't want to have the responsibility of doing it for others.
 
I think that PaleMoon will also be a nice, customizable choice as it's another attempt to avoid making all browsers Chrome-like inefficient tools for clicking ads. However, PM is built with Visual in Windows and I don't know with what exactly in Linux, so I'm afraid a bit that ARM users may get similar attention from PM developers as Haiku OS users got from Abiword developers few years ago.
 
To be fair the bug itself was a little rude to begin with.
The thing with this bug was that there was already port running on BeOS kits and it was rather OK, and Haiku is in many aspects program-compatible with BeOS.

As a PaleMoon user, I see what happens when someone tries to use some other browser than "Chrome-FF-IE" trinity - many webpages don't even let user in with other user agent. That's the price of Web 4.0 based on profiling.
 
I use a webkitgtk based browser. Nobody has tried locking me out in years, although that might be because almost all websites identify it as "Safari 8 on Linux", despite the Doris/0.1 at the end of my user agent.

The main blocker is the tens of times a day when the window goes dark as webkit crapped itself.
 
To be quite honest, I'm probably going to use Chromium. I want to be able to cast things to my Chromecast.
 
The thing with this bug was that there was already port running on BeOS kits and it was rather OK, and Haiku is in many aspects program-compatible with BeOS.

Yes, but apparently not compatible enough to run the code in question. The associated text posted with the bug report does add some pleases and thankyous, but I get the feeling showing any evidence of actually trying to use the code freely given to you to build it yourself. It's absolutely not a bug in the code that your community hasn't tried to build it yet.

But sure, the coder's reply was a little more rude than submitter's bluntness, who probably just didn't know any better.

In other, potentially more important news, here's another reason not to run untrusted javascript on your machines:
https://www.theregister.co.uk/2017/02/14/aslr_busting_javascript_hack/

It still boggles my mind how javascript is letting code access addresses outside of its own program space, and that isn't considered a fatal bug apparently.
 
I'm not sure about the technical details, but I'm liking Midori (for use with Octoprint). It's so fast.

Quite like Lynx too. For some sites.
 
Midori is webkit based, so won't get the latest patches always apparently. I've not been a debian user for a while and always used firefox (or derivative) browsers then anyway, so I'm not sure if that's a real issue, but we could always build our own copy and put it in our own repo if it is a real issue ever.
 
It still boggles my mind how javascript is letting code access addresses outside of its own program space, and that isn't considered a fatal bug apparently.

Sorry for a slight offtopic, but the thing is complex here. JS was made for something totally different that is used for. Internet was made for something different. To solve these differences JS had to grow outside its design rules and it started to happen.The same thing is with Flash, but they tried to accommodate by including highly optimized media codecs and making bigger impact on programming. Finally I'm still sticking with this insecure program as I don't have a few video accelerators nearby to decode HTML5 video :).

The main problem is that after a longer development nobody has a clear picture what happens inside a complex system! Everyone knows their parts only.
Let me tell you a story of one bug. I am working in a FEM numerical simulation package with origins in 1980s. This is a very well-known package in some scientific and industrial applications and it applies very well, it was developed by few institutes and companies. It is of course closed source except some uncommented user programs code. Solver input files grown so much, that they're now formed from includes by a complex set of BAT files, but that's only a temporary hack (since 1998). There is a memory leak (reading after boundary of array) while computing destruction of solids which makes one variable normalized to 0..1 range go past 1.0 value if some conditions are met. I intentionally use it to trim solids in some conditions, the leak was introduced 15 years ago with few other ones allowing to specify quite funny conditions when the material disappears. Everyone knows about the leak, I know the internals of the company. But that's what happens when someone tries to fix it:
1. Solids team (trying to maintain compatibility with paper tape, err, elements mesh in text files for Outline-compatible plotters) tells domain team to fix it.
2. Re/meshing (domain) team tells that it's not their business as they're doing Fortran, not C. Let "math magicians" do it as they are responsible for models.
3. "Math magicians" have no idea about leak. They use "Trivial solutions" as per LoseThos definition (no protection, no security, continuous memory access) and, for them, array boundaries are questionable if only two arrays are placed one near another which happens all time thanks to their C programs. Let coding team do it, they translate their notes in poor C pseudo-code to Fortran for the solver.
4. Coding team: We translate WHAT?
5. In 2014 one programmer tried to fix a leak. Instantly everything failed. The deeper you go, the worse things you see. Output format locked to 4 threads? Why not, there were maximum 4 when it was designed! Unconditional reporting errors to serial port using proprietary codes? There must be a ADM3a terminal connected to this 64-core Xeon HPC machine! Both endian values in one array in results file? Why not? Switch endianness reading every 4th float and you're OK.
6. Managers try not to see function (name translated by me) "value_take_from_space(uint coordinate, unsigned char typecode)" which hacks all over memory. Inside there is a bloody mess of memory management, #define hell to make it work on different architectures and terrible hacks to avoid "platform-dependent complications".

I hope Pyra project will never reach this stage and people designing it will always know what they design.
 
Do not blame the language, Javascript, rather, the implementation: TraceMonkey. (souped up version of SpiderMonkey). Where speed was suddenly the highest priority because V8 was faster. Then there are normal runners like Ductape, which I like because it is so small and can be embedded in C. No fancy JIT, but solid execution.
 
I don't think we will need such small browsers like qupzilla on the pyra anyway. I guess palemoon will fit very well.

This would be my bet. I love and use Palemoon on my 1ghz Pandora with a swap file. It isn't super fast, but I wouldn't call it slow either...It does just fine plus I love the fit-to-width setting so there is no sideways scroll. I wish other browsers had that function.

I would be good with Epiphany too, I use that on my Pi. It is lightweight and I haven't found a page it wont load, granted it has some strange behavior at times and doesn't feature a homepage or bookmark bar which would be nice.
 
This would be my bet. I love and use Palemoon on my 1ghz Pandora with a swap file. It isn't super fast, but I wouldn't call it slow either...It does just fine plus I love the fit-to-width setting so there is no sideways scroll. I wish other browsers had that function.
Another Palemoon user here, but on 2x1.3GHz Intel. I have a question - do you use any addons like NoScript?
I use a machine with 2GB of RAM in everyday work, I have many tabs opened (currently: 25 in this window, 9 in another) and I don't have bigger problems with RAM utilization (500-600MB at full load) - because I have NoScript with detailed, domain-based whitelist.

I'm just slowly evaluating usable power of these ARM computers.
 
Back
Top