More generally I feel that Core 2 serves as a pretty good line in the sand across the board. It’s not too hard to make machines of that vintage useful, but becomes progressively challenging with anything older.
Frankly, anything older than that sucks so much power per unit of work that I wouldn’t want to use them for anything other than a space heater.
As long as you don’t open a million tabs and aren’t expecting to edit complex Figma projects, I’d expect browsing the web with a Pentium + a lightweight distro to be mostly fine.
Idk, I think this is sad. Reviving old hardware has long been one thing Linux is really great at.
My wife had an HP Stream thing with an Intel N3060 CPU and 4GB of RAM. I warned her but it was cheap enough it almost got the job done.
Gmail's web interface would take almost a minute to load. It uses about 500MB of RAM by itself running Chrome.
Does browsing the web include checking your email? Not if you need web mail, apparently.
Check out the memory usage for yourself one of these days on the things you use daily. Could you still do them?
4GB of RAM should be more than enough.
Pale Moon and K-Meleon are really just using an old Gecko engine fork, aren't they? I think Waterfox is the same.
Otter Browser is using QtWebEngine, which is Blink, so it's Chromium with a different UI.
At this point, as far as I can tell, if it successfully renders the modern web, it's a Firefox or Chrome fork anyway. None of the lightweight browsers ever seem to improve my life any.
Got the Thinkpad for half the ebay value on a hamfest. Made in 2018-ish, i5-8350U CPU... It's a nice thing, the form factor is awesome and so is the built-in LTE modem. The problem is, more than a dozen Chrome tabs and it slows to a crawl. Even the prior work machine, a 2015 MBP, performed better.
And yes you absolutely need a beefy CPU for a news site. Just look at Süddeutsche Zeitung, a reputable newspaper. 178 requests, 1.9 MB, 33 seconds load time. And almost all of that crap is some sort of advertising - and that despite me being an actually subscribed customer with adblock enabled on top of that.
- Ublock origin instead of AdBlock
- git clone git://bitreich.org/privacy-haters
- either copy the chromium file to /etc/profile.d/chromium.sh under GNU/Linux/BSD and chmod +x it, or copy the --arguments array to the desktop launcher path under Windows, such as C:\foo\bar\chrome.exe" --huge-ass-list-of-arguments-copied-there.
Go try browsing the web without UBlock Origin today under an i3.
These things that look like institutions, that look like bricks carved from granite, are just spinning plates that have been spinning for a few years.
When I fight glibc dependency hell across Ubuntu 22 and Ubuntu 24, I sympathize with Firefox choosing to spin the 64-bit plates and not the 32-bit plates.
Employees: “We want to use new feature X.”
Boss: “Sorry, but that isn’t available for our wealthy customers who are stuck on Eee PCs.”
Nah.
Nah mate, something doesn't add up. I can't buy this. Even the cheapest Atoms had 64bit support much earlier than that and Atoms were lower tier silicone than Celeron so you can't tell me Intel had brand new 32 bit only Celerons in 2019.
My Google-fu found the last 32-bit only chips intel shipped were the Intel Quark embedded SoCs EoL in 2015. So what you're saying doesn't pass the smell test.
As in, a product that was manufactured, kept in its original packaging, and "unopened and unused".
(Although there's some allowances for the vendor to test because you don't want to buy something DOA.)
(Although I won't get too angry for someone saying "brand new." "New old stock" is kind of an obscure term that you don't come across unless you're the kind of person who cares about that kind of thing.)
My point is this stuff is still in play in a lot of places.
So when you tell me "brand new 32 bit Celeron" it is understood as "just came onto the market".
Am I right or wrong with this understanding?
>My point is this stuff is still in play in a lot of places.
I spent ~15 years in embedded and can't concur on the "still in play in a lot of places" part, but I'm not denying some users can't still exists out there, however I'm sure we can probably count them on very few fingers since Intel's 32 bit Embedded chips never had much traction to begin with.
Mate, 20 year old system means a Pentium 4 Prescott and Athlon 64, both of which had 64 bit support. And in another year after we already had dual core 64 bit CPUs.
So if you're stuck on 32 bit CPUs then your system is even older than 20 years.
So you could very well have bought a decent quality 32 bit system after 2005, although the writing was on the wall long before then.
Not really. With the launch of Athlon 64, AMD basically replaced all their 32bit CPUs lineups with that new arch, and not kept them along much longer as a lower tier part. By 2005 I expect 90% of new PCs sold were already 64 bit ready.
You're several years off:
"The FIRST processor to implement Intel 64 was the multi-socket processor Xeon code-named Nocona in June 2004. In contrast, the initial Prescott chips (February 2004) did not enable this feature."
"The first Intel mobile processor implementing Intel 64 is the Merom version of the Core 2 processor, which was released on July 27, 2006. None of Intel's earlier notebook CPUs (Core Duo, Pentium M, Celeron M, Mobile Pentium 4) implement Intel 64."
https://en.wikipedia.org/wiki/X86-64#Intel_64
"2012: Intel themselves are limiting the functionality of the Cedar-Trail Atom CPUs to 32bit only"
https://forums.tomshardware.com/threads/no-emt64-on-intel-at...
Intel had 80% of the CPU market at the time.
They will be in dire straights if the Google money goes away for some reason, but right now they have plenty of money.
(not that I think it makes any sense for them to maintain support for 32-bit cpus)
Last i checked, Mozilla was an ad company with Google as the main "donor".
Question: Don't optimizers support multiple ISA versions, similar to web polyfill, and run the appropriate instructions at runtime? I suppose the runtime checks have some cost. At least I don't think I've ever run anything that errored out due to specific missing instructions.
https://news.ycombinator.com/item?id=44884709
but generally it is rare to see higher than x86-64-v3 as a requirement, and that works with almost all CPUs sold in the past 10+ years (Atoms being prominent exception).
The last processor without the CMPXCHG16B instruction was released in 2006 so far as I can tell. Windows 8.1 64-bit had a hard requirement on the CMPXCHG16B instruction, and that was released in 2013 (and is no longer supported as of 2023). At minimum Firefox should be building with -mcx16 for the Windows builds - it's a hard requirement for the underlying operating system anyway.
You could also have only one implementation of strcpy and use no exotic instructions. That would also be faster for small inputs, for the same reasons.
Having multiple implementations of strcpy selected at runtime optimizes for a combination of binary portability between different CPUs and for performance on long input, at the cost of performance for short inputs. Maybe this makes sense for strcpy, but it doesn't make sense for all functions.
You can't really state this with any degree of certainty when talking about whole-program optimization and function inlining. Even with LTO today you're talking 2-3% overall improvement in execution time, without getting into the tradeoffs.
> Even with LTO today you're talking 2-3% overall improvement in execution time
Is this comparing inlining vs no inlining or LTO vs no LTO?
In any case, I didn't mean to imply that the difference is large. We're literally talking about a couple clock cycles at most per call to strcpy.
And at runtime, there is no meaningful difference between strcpy being linked at runtime or ahead of time. libc symbols get loaded first by the loader and after relocation the instruction sequence is identical to the statically linked binary. There is a tiny difference in startup time but it's negligible.
Essentially the C compilation and linkage model makes it impossible for functions like strcpy to be optimized beyond the point of a function call. The compiler often has exceptions for hot stdlib functions (like memcpy, strcpy, and friends) where it will emit an optimized sequence for the target but this is the exception that proves the rule. In practice, the benefits of statically linking in dependencies (like you're talking about) does not have a meaningful performance benefit in my experience.
(*) strcpy is weird, like many libc functions its accessible via __builtin_strcpy in gcc which may (but probably won't) emit a different sequence of instructions than the call to libc. I say "probably" because there are semantics undefined by the C standard that the compiler cannot reason about but the linker must support, like preloads and injection. In these cases symbols cannot be inlined, because it would break the ability of someone to inject a replacement for the symbol at runtime.
Repeating the part of my post that you took issue with:
> If there was only one implementation of strcpy and it was the version that happens to be picked on my particular computer, and that implementation was in a header so that it could be inlined by my compiler, my programs would execute faster.
So no, I'm not talking about LTO. I'm talking about a hypothetical alternate reality where strcpy is in a glibc header so that the compiler can inline it.
There are reasons why strcpy can't be in a header, and the primary technical one is that glibc wants the linker to pick between many different implementations of strcpy based on processor capabilities. I'm discussing the loss of inlining as a cost of having many different implementations picked at dynamic link time.
There are more relevant modern examples, but one example that I really think illustrates the issue well is floating point instructions. The x87 instruction set is the first set of floating point instructions for x86 processors, first introduced in the late 80s. In the late 90s/early 2000s, Intel released CPUs with the new SSE and SSE2 extensions, with a new approach to floating point (x87 was really designed for use with a separate floating point coprocessor, with a design that's unfortunate now that CPUs have native floating point support).
So modern compilers generate SSE instructions rather than the (now considered obsolete) x87 instructions when working with floating point. Trying to run a program compiled with a modern compiler on a CPU without SSE support will just crash with an illegal instruction exception.
There are two main ways we could imagine supporting x87-only CPUs while using SSE instructions on CPUs with SSE:
Every time the compiler wants to generate a floating point instruction (or sequence of floating point instructions), it could generate the x87 instruction(s), the SSE instruction(s), and a conditional branch to the right place based on SSE support. This would tank performance. Any performance saving you get from using an SSE instruction instead of an x87 instruction is probably going to be outweighed by the branch.
The other option is: you could generate one x87 version and one SSE version of every function which uses floats, and let the dynamic linker sort out function calls and pick the x87 version on old CPUs and the SSE version on new CPUs. This would more or less leave performance unaffected, but it would, in the worst case, almost double your code size (since you may end up with two versions of almost every function). And in fact, it's worse: the original SSE only supports 32-bit floats, while SSE2 supports 64-bit floats; so you want one version of every function which uses x87 for everything (for the really old CPUs), one version of every function which uses x87 for 64-bit floats and SSE for 32-bit floats, and you want one function which uses SSE and SSE2 for all floats. Oh, and SSE3 added some useful functions; so you want a fourth version of some functions where you can use instructions from SSE3, and use a slower fallback on systems without SSE3. Suddenly you're generating 4 versions of most functions. And this is only from SSE, without considering other axes along which CPUs differ.
You have to actively make a choice here about what to support. It doesn't make a sense to ship every possible permutation of every function, you'd end up with massive executables. You typically assume a baseline instruction set from some time in the past 20 years, so you're typically gonna let your compiler go wild with SSE/SSE2/SSE3/SSE4 instructions and let your program crash on the i486. For specific functions which get a particularly large speed-up from using something more exotic (say, AVX512), you can manually include one exotic version and one fallback version of that function.
But this causes the problem that most of your program is gonna get compiled against some baseline, and the more constrained that baseline is, the more CPUs you're gonna support, but the slower it's gonna run (though we're usually talking single-digit percents faster, not orders of magnitude faster).
Probably less, not more. Many distros either stopped supporting 32bit systems, or are planning to. As the announcement says, that's why they're stopping support now.
Kiosks and desktops and whatnot on Raspis still on 32-bit and likely to have Firefox without telemetry.
Debian supports MIPS and SPARC still. Last I checked OpenSSL is kept buildable on OpenVMS. Surely there must be a handful of people out there who cares about good old x86?
If your numbers are correct, there are millions if not tens of millions of Firefox users on 32-bit. If none of them are willing to keep Firefox buildable, there must be something more to it.
We've carefully ran some numbers before doing this, and this affects a few hundreds to a few thousand people (hard to say, ballpark), and most of those people are on 64bits CPUs, but are using a 32bits Firefox or 32bits userspace.
The comparatively high ratio of 32bits users on Windows is not naively applicable to the Linux Desktop population, that has migrated ages ago.
That's the specific meaning of support that it was my intention to point out. Free software projects usually do not "support" software in the commercial sense, but consider platforms supported when there are enough persons to keep the build alive and up to date with the changing build requirements etc. It was my expectation that Firefox was more like free software project than a commercial product, but perhaps that is not the case?
Commercial products have to care about not spreading their resources thin, but for open source cause and effect are the other way around: The resources available is usually the incoming paramter that decides what is possible to support. Hence my surprise that not enough people are willing to support a platform that has thousands of users and isn't particularly exotic, especially compared to what mainstream distributions like Debian already build.
Maybe they could also drop support for older x86_64 CPU's, releasing more optimised builds. Most Linux distributions are increasing their baseline to x84-64-v2 or higher, most Firefox users (>90%)[0] seem to meet at least x84-64-v2 requirements.
[0]: https://firefoxgraphics.github.io/telemetry/#view=system
[1]: https://firefoxgraphics.github.io/telemetry/#view=general