@afxgroup

Quote:
What about https://www.researchgate.net/publicati ... ith_compiler_optimization? The other two sites work with IBrowse too, while this one doesn't.

@afxgroup

Quote:
I don't think it's an SSL problem- that's not the kind of security issue that Cloudflare is looking for. They're looking for automated web bots that are probing or potentially attacking a web site. Simply checking SSL certificates and looking at user agents isn't good enough, as robots also use SSL, and know how to spoof as being an actual web browser.

I'm sure the details of how they attempt to discriminate between bots and real users are proprietary, but it seems to involve running some Javascript (no doubt heavily obfuscated) on the browser, and if they're still not sure, putting up a CAPTCHA.

Quote:
No, it's an Odyssey problem. Most likely the Javascript makes use of some Javascript or browser functionality that Odyssey doesn't support, so the test fails or doesn't even run. It never gets as far as putting up the CAPTCHA, though in the past when the CAPTCHA did appear it didn't help- though the CAPTCHA itself seemed to work, clicking 'Verify' at the end just brought up another CAPTCHA, and you still couldn't access the site or page.

Regardless of the cause, the effect is the same- Cloudflare threat protection on a site means you can't access it with Odyssey. The situation with IBrowse seems a little more complex.

@Futaura

Quote:
This link that LiveForIt posted over on the RadeonHD V.5 driver thread is an example of a web page that is not accessible to Odyssey because of Cloudflare's threat protection:

https://www.researchgate.net/publicati ... ith_compiler_optimization

There's no CAPTCHA with this page, so either there are different versions of the threat detection code, or the code has changed and no longer gets far enough to even bring up the CAPTCHA.

When I try to follow the link with Odyssey, I get a page with a "Checking if the site connection is secure" message, followed by a high CPU load as a lot of Javascript runs. After a bit the message "This check is taking longer than expected" pops up. After a bit more the page reloads, and the whole thing repeats.

Every now and then, for whatever reason, I instead get a "Verify you are human" button in addition to the "This check is taking longer than expected" message. With other sites in the past clicking on such a button has brought up the CAPTCHA, but here it has no effect, and eventually the page reloads again.

When I try this same link with IBrowse I get the same "Checking if the site connection is secure" page, but there doesn't seem to be any Javascript executing, and nothing further happens (no "taking longer" message or page reloading).

Here's another link that doesn't work with Odyssey due to Cloudflare:

www.bhphotovideo.com

When I try it with Odyssey, I get the same result as with the link above. But curiously, when I try it with IBrowse it works fine (or as well as it can, with no CSS support).

@Futaura

I was thinking more of the threat protection aspect of Cloudflare- almost every time I encounter a website that wants me to prove I'm not a robot and then won't let me in no matter how many times I complete the CAPTCHA, it turns out to be Cloudflare. So I've come to associate Cloudflare with "can't go there with Odyssey." I imagine IBrowse also has this problem, though I've never actually tried it.

If that part of Cloudflare can be separated from the SSL/certificates part, then of course I have no objection to that.

Quote:
Definitely don't do that- it would make it inaccessible to Odyssey (and presumably IBrowse, too).

@kas1e

Quote:
While the version tag date is 03/06/2022, the file date on the one in Enhancer seems to be 03/06/1980- I'm not sure what happened there.

@rjd324

Quote:
Ranger can display all the firmware environment variables in its Hardware->Firmware tab.

@khayoz

OS 4 version 1.943 also crashes on exit if "sort by date" has been used.

@rjd324

Quote:
You could always get a Sentinel X-Logger!

@kas1e

Quote:
Yes, that's right.

@kas1e

Quote:
On my X1000 I get 49 seconds from power on to working system, which includes a five second timeout for the CFE boot menu. It takes 32 seconds from power on to where the progress bar first appears as amigaboot.of starts loading modules (including that five second menu timeout), and another 17 seconds from there to a full working system. That's with the standard (not debug) kernel and a mechanical HDD formatted with SFS2.

@kas1e

Quote:
I vaguely remember seeing that at some point in the past (perhaps when I was having boot problems due to a depleted backup battery), but in normal use I never have that problem.

@walkero

Quote:
That's not entirely true. If you look at adtools.lha on OS4Depot, which contains GCC 8.3.0, you'll find in the share/info directory the file gcc.info, which has been edited to document the Amiga-specific alterations to GCC, including -athread. This information apparently never made it to any of the PDF versions of the GCC documentation.

@kas1e

I got a crash as well, a DSI. The redzone was not damaged, but the stack pointer was out of bounds. Looks like an infinite recursion leading to a stack overflow, with the stack full of two alternating addresses in elf.library.

My libjpeg.so is the same size as yours, and I got the same crash even if I used the FILE switch.

So no, it's not just you.

@walkero

As a user, I don't always immediately upgrade to the latest version of something, as for every bug it fixes and new feature it adds, it also may break something or add new bugs. For example, I stayed with OS 4.1.6 for some time after FE was released, because the initial incarnation of FE was rather buggy. It was only after Update 1 came out that I switched to FE.

As a developer, I try to keep users like me in mind when writing software, and generally make some attempt at supporting older versions of the OS/libraries/MUI/whatever. I try to avoid using conditional code to add backwards compatibility, as it makes the code hard to read and maintain. But if I can use a DOS function that only supports 32-bit file sizes, for example, when I know that my application will never generate files large enough for that to be a problem, then why not? Likewise, does that gee-whiz new feature really add value to the user, or would the program be just as useful -- though maybe less sparkly -- without it?

If there's a compelling reason to use the latest version of something (for example, it fixed a bug that my application can't reasonably work around, or it adds a useful new feature that it's not practical to reproduce some other way) then I'll certainly do so. But I'll also at least look at whether I can work around the bug, or if I really need that new feature.

Balanced against all that is the stark reality that there are far more Amiga programs that need to be written than there are developers to write them, so whatever makes it most efficient (and enjoyable, since most of us are not in it for the money) to work on Amiga software is the way to go. If for any given programmer that means only using/testing with the very latest version of everything, then so be it. But please do publicize the requirements so no one will be caught by surprise, and have the program display a helpful error message and safely quit if it encounters an outdated version of something, rather than crashing or not working properly.

@kas1e

Quote:
That sounds like heatsink compound, not thermal glue. Heatsink compound is a silicone paste that helps heat transfer between the CPU and the heatsink by filling any tiny gaps between the two. It intentionally gets softer when it's hot. It's not intended to hold anything in place, and is only used when you have some other means of securing the heatsink.

If you do end up with a stick-on or glue-on heatsink you'll want to remove the heatsink compound first, as nothing is going to stick to it.

@trixie

Quote:
The 'reading' part is not entirely true. There's an occasional worthwhile posting (like Robert Bernardo's Amiwest videos), so I do find myself checking in from time to time, just in case.

@Mlehto

Quote:
That tells the SAS/C code to get the address of ExecBase from a global variable called SysBase, instead of getting it by reading address 4. GCC always uses SysBase, so this definition is not needed (but it does no harm if present).

Quote:
By default the OS4 includes define SysBase as a generic pointer to struct Library, rather than what it actually is, a pointer to struct ExecBase. That allows calls like OpenLibrary() and CloseLibrary() to work without needing to cast to and from a pointer to whatever that library's base is called.

But of course struct Library has no TaskWait and TaskReady fields, so you get errors. One way to fix this is to cast SysBase to a pointer to ExecBase before referencing those fields. Another way is to add the definition

#define __USE_BASETYPE__

before including anything; that causes SysBase to be defined as pointing to struct ExecBase, which will let the code reference ExecBase fields like TaskWait and TaskReady without a cast.

Note that those two fields of ExecBase are marked as obsolete, so they may not do anything useful even after you get the code to compile. There are enough differences between OS4 and OS3 that OS3 code that pokes around in ExecBase is unlikely to work properly under OS4.

Quote:
Some people feel that same way about writing code.

@Capehill

Quote:
Better to make TimerBase a library pointer, instead of a device pointer; that way no casting is required. It's also cleaner that way, since the purpose of obtaining the TimerBase from the device is to be able to treat it like a library.

@Raziel

Quote:
If you want to get rid of all the warnings, just use "-Wno-deprecated-declarations".