We need an iBrowse replacement for 68k!!!

[bbond007]

I
This upset a few classic users that couldn't use the site after the update. So, I wrote a small degrader proxy in PHP that parses the markup and degrades it into (far obsoleted) HTML that iBrowse (and AWeb) can cope with.

Compare this site in iBrowse versus this one: http://aoproxy.extropia.co.uk/

What you could do is set up a sub domain on a1k and we could look at installing a suitably modified version of the code on it to cope with whatever forum engine you ultimately go for.

Karlos, I use this on my A1200 all the time. Can the parser replace the bad grammer as well? J/K

I always wondered if you had a similar proxy for EAB?

Thanks!

[bbond007]

What would really be useful in a 68k browser is a Javascript whitelist feature such as NoScript provides for Firefox. An improved JS engine would be nice, but ultimately there's just too much JS bloat on modern websites; even modern systems get dragged down by it. A whitelist would at least help to contain the insanity; as is, I spend more time in iBrowse waiting for scripts to time out than I do actually looking at webpages.

Even if you get some sort of browser(for the classic amiga) that supports the latest CSS and whatnot, its still going to be kind of discouraging to watch it lock-up the machine for minutes on end while it does some inefficient javascript routine. This is the situation on the Raspberry Pi which I'm sure is faster than an 060.

HTML started as a good idea, but it evolved into this mess that only somewhat runs correctly on high-end x86 hardware.

The best browser on amiga is rdesktop

[AmigaClassicRule]

Even if you get some sort of browser(for the classic amiga) that supports the latest CSS and whatnot, its still going to be kind of discouraging to watch it lock-up the machine for minutes on end while it does some inefficient javascript routine. This is the situation on the Raspberry Pi which I'm sure is faster than an 060.

HTML started as a good idea, but it evolved into this mess that only somewhat runs correctly on high-end x86 hardware.

The best browser on amiga is rdesktop

What if Amiga classic systems say have the latest custom chipset (instead of AGA) with 512 Mb of CHIP RAM and say running at a good high end speed, made by Commodore itself, a real Commodore Amiga in every since of way with a sexy famous Commodore Amiga keyboard case and even have RF, Composite, etc...and it can handle the latest browsers with all their "bloating" just fine....beyond find. Would you still believe in your sentence above? Would you still hate flash, javascript, asp.net, etc?

[chris]

A more basic browser supporting CSS and javascript (netsurf isnt bad, but lack of javascript is quite limiting) is way more realistic/reasonable in my opinion.

Agreed, however NetSurf does actually have some basic JavaScript support (it's early days, but I have a build here with working JavaScript).  Once ported, the JS stuff will improve with no additional front-end effort required.

netsurf and aros owb 68k prove a css browser is possible at least on 060. optimized plotter that doesnnt just render the whole content new even when just scrolling would make it even faster. trade off antialiasing on fonts might bring another speedup. one just needs to do that.

NetSurf (OS4) already has an optimised scroll, and anti-aliasing can be switched off (it makes a big difference even on PPC with 16-bit screenmodes)

[wawrzon]

NetSurf has built-in "grab and drag" so the scrollbars could be omitted initially

this is actually even more tempting, having that scrollbars are even almost not necessary except for really huge pages. couldnt you try to build it for 68k target commenting out whatever does not compile? this way we would at least exactly know what parts need work. this is everything i could ever do, rewriting offending parts is completely out of question in my case, but you being familiar with the particular build process and likely having everything necessary at hand are better off anyway. i guess it wouldnt take longer for you than posting in this thread.

[fishy_fiz]

Agreed, however NetSurf does actually have some basic JavaScript support (it's early days, but I have a build here with working JavaScript).  Once ported, the JS stuff will improve with no additional front-end effort required.

Ah, cool, I didnt know that. Obviously complicated javascript stuff is going to be too heavy for classics (can use massive amounts of ram for starters, even disregarding cpu usage), but some sort of basic javascript support for basic things like file uploads (most of file/image hosting sites use javascript for this) is in my opinion nigh on essential, especially with the goal in question (essentially a browser to make classic users more content vs. the options currently available).

[commodorejohn]

What if Amiga classic systems say have the latest custom chipset (instead of AGA) with 512 Mb of CHIP RAM and say running at a good high end speed, made by Commodore itself, a real Commodore Amiga in every since of way with a sexy famous Commodore Amiga keyboard case and even have RF, Composite, etc...and it can handle the latest browsers with all their "bloating" just fine....beyond find. Would you still believe in your sentence above? Would you still hate flash, javascript, asp.net, etc?

Considering that I keep them turned off even on a Core 2 Duo system running at 1.66GHz wit 2GB of RAM, yes, yes I would still hate them. Flash and Javascript have their uses, but the abuse of them is so utterly rampant that it's really easier to do without unless a site specifically requires them to function at all (and in that case, it's usually easier to just avoid the site if possible.)

[Karlos]

I always wondered if you had a similar proxy for EAB?

I don't, but as it's already using vbulletin, I don't expect it to be a big task to adapt it. It's just text processing at the end of the day.

[AmigaClassicRule]

Considering that I keep them turned off even on a Core 2 Duo system running at 1.66GHz wit 2GB of RAM, yes, yes I would still hate them. Flash and Javascript have their uses, but the abuse of them is so utterly rampant that it's really easier to do without unless a site specifically requires them to function at all (and in that case, it's usually easier to just avoid the site if possible.)

I am not going into the "what if game" because that is childish and silly. However, with full honesty, even if we have a sophisticated and well optimized developers who develop the newest features for website it will eventually  require a more powerful system to run them (even if you code it in 100% assembly). People need new technology and features in their website, business demand them to make things look professional and easier to develop. In the end, upgrading hardware is much easier than being stagnated in our software features just because we find that it takes too much from the hardware.

Amiga would have not have had all these problems had the company did not go under and had they always upgraded their hardware, always updated their software, improved in their security level and memory managed, worked in selling their computer as a good business machine and not just as a toy, and not have bickering, backstabbing, fighting, not fulfilling their promises and have history of developing bad Amiga models like A600 for example when A1200 was out, and if they have not made their A1200 so weak as will as their A4000 with it's limited chip RAM of 2 MB and still stuck in AGA...if they have not done all that...then perhaps the issue of a browser being too strong to run in an Amiga classic hardware would not have being a real issue.

Then people who like bloated and fat features of a browser such as java and so forth would not be complaining that their hardware is not up to the bar. And people who hate fat and bloated java and HTML would disable it if they want...at LEAST we have a choice. At least it works...at least it runs..and maybe Amiga would have lived as a niche market of 1% and survived like Mac survived in a competition against Windows.

[bbond007]

I don't, but as it's already using vbulletin, I don't expect it to be a big task to adapt it. It's just text processing at the end of the day.

Yeah, so I can log in to EAB on my 1200 and see the lack of progress on the Indivision AGA MK2...

[wawrzon]

@chris:
sigh, apparently yet again the most dumb ungifted and uneducated noob has to give it a try and give up just after few stabs. ive lost count how many times ive already tried.

chris, just took a look at 2.9 source for starters. i would have to try to compile it under amidevcpp, compiling native under cubic has never led to any usable progress, especially lacking appropriate shell, and was damn slow every time i tried.

i would have to set up a new target, borrowing what is set for os4 at the beginning. something like m68k-amigaos should do i guess. i would have to override host detection as it looks like, i guess mingw would be the right choice, likely other settings would might need to be overridden as well. ive tried to consult arturs sources (http://aminet.net/comm/www/netsurf-m68k-sources.lha) but i see nothing that would help me in the makefiles. looks like hes using amidevcpp interface to build netsurf. id like to try to stay conform with the genuine makefiles.

[commodorejohn]

People need new technology and features in their website, business demand them to make things look professional and easier to develop.

But that's not the problem here. The problem isn't the things that Javascript is needed for, the problem is all the places it isn't necessary but gets used anyway. Modern web developers are so stuck on fetishizing glitz and flashy animation and such that they don't ever stop to think about whether it's necessary, and it usually isn't, or whether it impairs usability, which it often does, or whether there's a simpler alternative, which there usually is. (If I had a dollar for every time I've seen JS drop-down menus when CSS has been able to do that since forever, I'd be a significantly richer man.)

(The further irony is that all this often actually looks uglier, in a trashy disco drag-queen kind of way, than the simpler alternatives.)

Hell, we're even getting to the point where it's common practice to reimplement basic browser functionality like links and the back button in Javascript, often in ways that break the real in-browser implementation. That is Bad And Wrong. This is not a problem of old technology not keeping up with the requirements of real improvements in web design, it's a problem of bad design becoming the rule on the web.

[zylesea]

While netsurf seems to be a good candidate what about OWB/Odyssey? I don't know how modular it is, but stripped down (JS & some other cpu demading things disabled) I could imagine it could work on higher spec'ed 68k machines.
Either AROS OWB or Odyssey could be good starting points for a stripped down OWB 68k version.
But probably netsurf is the better starting point as there is a working 68k build already.

[chris]

@chris:
sigh, apparently yet again the most dumb ungifted and uneducated noob has to give it a try and give up just after few stabs. ive lost count how many times ive already tried.

chris, just took a look at 2.9 source for starters.

Don't bother with 2.9.  3.0-dev is pretty stable at the moment and due for release in the next 2-3 months.  The palette-mapped plotters aren't in 2.9 either.

i would have to set up a new target, borrowing what is set for os4 at the beginning. something like m68k-amigaos should do i guess. i would have to override host detection as it looks like, i guess mingw would be the right choice, likely other settings would might need to be overridden as well. ive tried to consult arturs sources (http://aminet.net/comm/www/netsurf-m68k-sources.lha) but i see nothing that would help me in the makefiles. looks like hes using amidevcpp interface to build netsurf. id like to try to stay conform with the genuine makefiles.

I use Cygwin, mingw ought to work as well.

I would advise trying to build the toolchains used by the auto-builder.  See this email: http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2012-December/002983.html

There is a m68k-unknown-amigaos target set up in there already.

I've never tried building the toolchains.  I keep meaning to as my OS4 builds have a weird issue that doesn't show up on the auto-built versions.  However, these might get around the problems NovaCoder had.

You can then build the libraries (and NetSurf itself) using TARGET=amigaos3 as an argument to make.

It's worth reading this as well: http://wiki.netsurf-browser.org/Documentation/GettingCoding

[chris]

this is actually even more tempting, having that scrollbars are even almost not necessary except for really huge pages. couldnt you try to build it for 68k target commenting out whatever does not compile? this way we would at least exactly know what parts need work. this is everything i could ever do, rewriting offending parts is completely out of question in my case, but you being familiar with the particular build process and likely having everything necessary at hand are better off anyway. i guess it wouldnt take longer for you than posting in this thread.

Well, my 68k cross-compilation environment is pretty broken, as it's really an OS4 cross-compilation environment which is hacked to bits to force everything to cross-compile ppc-amigaos.  So actually it'll take me a while to set one up that works properly.

Here's a build log from a while back:
http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-January/002306.html

Some of those errors won't appear now, because there's an os3support.h file which hides a load of them.

[danbeaver]

Interesting thread, but to put it simply, "A 5 ounce sparrow cannot carry a 1 pound coconut."

Simpler, tighter and optimized code in the form of a quicker browser cannot handle the modern web page when the processor that runs it was designed over 20 years ago.  Heck, ever thought of what a modern X86 processor would do with code that wasn't bloated with waste?  Oops, the ghost of Linux past pops in the room.