Low-resource open source developers pretty much screwed now

always learning something new, I never think was possible to create a website in C
If you think, it is not so unnatural. Many web servers are written in C. Especially in embedded systems, it makes sense write a UI in HTML for exposing some data to the external world. You can have a very simple web-server written in C (it must support very few users and the web-server API is simple), and simple C code emitting HTML output. You are using few resources on the embedded part, and the majority of power is used on the web-browser client-side.

For complex Web applications, the majority of frameworks are on higher level languages, but the C path is not so strange...
 
Python can compile in ~6 mins on a P4.
libSDL3 can compile ~10 mins.
Linking them into an open-source project takes ~1 second on a P4. This is where much of your time will be spent anyway with the compile/debug iteration. Again working on gcc doesn't need to compile from scratch each time.

Try building some common C libraries (libogg, libpng, libvncserver, libglfw, etc, etc) on a weaker machine. You will be surprised how light they really are.
I tried now to compile SDL3 and vim, under FreeBSD quarterly ports, on a cloud host, using some unspecified shared AMD Epyc CPU. I limited the jail to one single CPU. SDL3 required 55 seconds (only the build, the configure part was probably longer). vim required 118s.

Using all the 4 cores, SDL3 compiled in 15s.

Considering a single-core speedup of 6x respect a P4, 6m vs 55s is credible. I have not a P4 to test.

To be honest, a full compilation under 15m is manageable for coding, especially if incremental recompilation is ~ 1m. So, if you want to code old but evergreen tools; you accept to use x86 code (no AMD64); and you have workarounds for navigating on documentation web sites, using a P4 with 2-3GB of RAM; then this approach can be feasible. But you said:

I can purchase a P4 system today for a fraction of the cost than I could back then. A pentium 4 is easily good enough for open-source development.

"easily good enough" considering all these constraints seem detached from reality. BTW, I doubt you can still find a used P4 to purchase. It is free junk. There are old i3-i5 at very cheap prices (at least before RAM increases), and for these systems I can agree. I can run modern web browsers on them.

A P4 would still provide a stronger development environment than a modern Raspberry Pi.

A modern Raspberry Pi has a lot more powerful CPU, no fans, cheaper on the energy bill, and in some scenario ARM is the way to go. It is not legagy as x86 architecture.

So, if it is a theorical discussion: YES you can compile with a P4. If it is a pragmatic one, then P4 is probably one of the worst possible choices, considering also the energetic consumption.
 
If you think, it is not so unnatural. Many web servers are written in C. Especially in embedded systems, it makes sense write a UI in HTML for exposing some data to the external world. You can have a very simple web-server written in C (it must support very few users and the web-server API is simple), and simple C code emitting HTML output. You are using few resources on the embedded part, and the majority of power is used on the web-browser client-side.

For complex Web applications, the majority of frameworks are on higher level languages, but the C path is not so strange...

Right,I know the foundations are writen in C , apache,nginx,etc
I mean the server, but never see or think write directly a render page to the web
used all my life to use html editors->web server , or PHP->web server
 
So, if you want to code old but evergreen tools
Sure, since the most impactful open-source projects are old and evergreen. Such as SDL, busybox, Vim, etc.

Lindy's Law tends to predict open-source lifecycles quite well. It also suggests that the oldest software in use today will be the most likely to remain alive for another 20 years.

A modern Raspberry Pi has a lot more powerful CPU, no fans, cheaper on the energy bill, and in some scenario ARM is the way to go. It is not legagy as x86 architecture.
A weaker integrated GPU, no replaceable parts, less standardized architecture for desktop usage compared to x86... big old list. Also, no fans is not the "benefit" you may think it is.

Don't get hung up on the word 'legacy'. Not only can these machines outlive you and me (we are legacy) but the same C code compiles and runs on them just fine. That's the whole point of C. Its also useful to expose errors or inefficiencies in your code.

So, if it is a theorical discussion: YES you can compile with a P4. If it is a pragmatic one, then P4 is probably one of the worst possible choices, considering also the energetic consumption.
Energy consumption when compiling software isn't that big a gap. If you are worried about energy usage, use a 14inch 1024x768 monitor. I notice that's always the real power saver.

A P4 is between 40W and 115W. My more recent i5 is 250W. Workstation computers, the power requirements doesn't just come from the CPU.

and you have workarounds for navigating on documentation web sites, using a P4 with 2-3GB of RAM; then this approach can be feasible. But you said:
Heh, a P4 can happily read docs in a web browser. This concept has been around since the 90s.
Luckily man-pages and, more recently, LLMs work nicely through the terminal.
 
Energy consumption when compiling software isn't that big a gap. If you are worried about energy usage, use a 14inch 1024x768 monitor.

If I'm worried about energy usage, I doubt I had to follow your suggestions. If this data, I found on the web is correct, an idle P4 consumes more than a Raspberry Pi 5 at full power: 70W vs 10W. During compilation a P4 will consume 130W, and the compilation times will be longer than on the Raspberry, because it is a lot slower.

A 24-inch monitor consumes 30W, so also if I switch to small LCD, I can never compensate the 120W of differences between the two and/or the 70W difference at idle state.

So what you said seems incorrect.

Regarding the GPU: a Raspberry has a rather decent one, supporting Vulkan 1.3, and with Linux drivers. Many P4 systems still use AGP.
 
Nobody uses P4 for modern stuff. The only appropriate case is occasional Linux session on a computer that is built to run period correct software with period correct hardware - and the 99% of that market today is gaming. People build P4 to game old games, not work on them...

The P4 market is understood by the simple fact - most of 90s DOS games can be run on any computer with nvidia graphics card, they are not CPU speed sensitive (if they are, there are patches) and nvidia has nearly 100% compatible IBM VGA DOS core and latest VESA BIOS exensions in its ROM. But - if the computer does not have an fully capable ISA slot (IRQ, PIO and DMA capability) the sound under DOS with PCI solutions is hit and miss, mostly miss. To game DOS, you need ISA sound card.

So, P4 is valued because it was the last platform to be equipped with proper PCI-ISA bridges.
This makes a fast P4 an "all arounder" that can
- run ancient late 80s/early 90s games with full native sound
- run software rendered 3D DOS games at high framerate at SVGA res
- run the entirety of win32/nt software library up to mid 00s with great performance.

Correct me if I'm wrong, but this is nothing you seek.

For the same price of (non-ISA) P4, which is next to 0, you get the same non-ISA Core Duo or Phenom or even better. Even early gen i7 you could get for free. Fast P4s are still slower per watt than newer CPUs.
 
A P4 would still provide a stronger development environment than a modern Raspberry Pi. Especially since C long ago solved the gap between porting to different processors of varying ages.

I really cannot agree. You would have to try it for yourself.
I have all these hardware we speak of and have tried to run some FreeBSD at least once on them. RPi4 is a bad development workstation. P4 is worse.

C solved little in this regard, you need to see how various codebases fail to compile or behave in runtime if devs just assumed a 64 bit word size.

Running a x86 platform today for any sort of "non-retro" development is really really something. I'm not saying it is a bad idea throughout, just saying I never heard people do that, yes they run Win7 32 on some ancient hardware with some patched browser for light daily duties etc, but not actual dev efforts...

If you're speaking all of this from theory, then you should try and put it in practice.
My 64-bit Q35 4 core 8 GB ram computer cannot run modern FreeBSD, I would need to compile everything manually.
It can probably run some Linux, and then it would be a fine development env. But this is not a P4.
 
I really cannot agree. You would have to try it for yourself.
I have all these hardware we speak of and have tried to run some FreeBSD at least once on them. RPi4 is a bad development workstation. P4 is worse.
Yeah, so the main P4 I use is an IBM NetVista 6790-21G (32-bit Willamette). I also have a more modern Fujitsu Siemens Scaleo P (64-bit Prescott).

1782514612276.png
1782514739396.png


They work well. Though admittedly I have never been much of an Eclipse or VSCode kind of guy. Your mileage may vary if you like that kind of stuff. Eclipse was slow and shite back then too.
C solved little in this regard, you need to see how various codebases fail to compile or behave in runtime if devs just assumed a 64 bit word size.
Its more common the other way round, that devs assume 32-bit ints and pointers are interchangeable breaking code for 64-bit platforms. But yes, this exactly why older machines are useful for testing broken code. Assuming any word size is incorrect and avoiding older hardware just to sidestep your broken code is not good practice.

Running a x86 platform today for any sort of "non-retro" development is really really something. I'm not saying it is a bad idea throughout, just saying I never heard people do that, yes they run Win7 32 on some ancient hardware with some patched browser for light daily duties etc, but not actual dev efforts...
Yeah but those same people would then struggle with developing on a Pi (or even some crappy Android phone). People do arrive at weird conclusions daily, I can't protect everyone.

FreeBSD is considerably lighter than Windows 7 so you shouldn't be struggling to run it on a machine of that era.

If you're speaking all of this from theory, then you should try and put it in practice.
I do, and often with more exotic machines (big fan of 2001 SPARC machines). But then again, much of my PhD was on resilience and portability of software, so it kind of comes with the territory. But the key message is that development hasn't considerably changed from that era. So needing to buy "modern" machines to develop open-source software is simply incorrect. And you can pick these things up for £30.

My 64-bit Q35 4 core 8 GB ram computer cannot run modern FreeBSD, I would need to compile everything manually.
You absolutely can. I am not sure what you are doing wrong. I believe FreeBSD even supports i440fx chipsets.
Qemu provides Q35 as one of the more modern platforms.
 
By that I mean no one touched Rust till the US government made a statement about it just recently. Then everyone had to have it and use it for everything. If you didn't, there was something wrong with you.
I don't know Rust, but I'm using (or I'm interested) into many projects written in it, like: Niri wayland compositor; Meta Sapling version control system; Pijul version control system; ripgrep; Alacritty; Helix editor; Zed editor; Meta Buck2.

So, something of good there must be in the language, or at least it is not completely a fake.
 
If I'm worried about energy usage, I doubt I had to follow your suggestions. If this data, I found on the web is correct, an idle P4 consumes more than a Raspberry Pi 5 at full power: 70W vs 10W. During compilation a P4 will consume 130W, and the compilation times will be longer than on the Raspberry, because it is a lot slower.
It doesn't look correct. As a base, under full load that chip alone can get to 16W. Then you want to include the same accessories as the P4 machine. Consider SSD, keyboard, cdrom, etc, it could even start to near 40W. If you remove the dedicated GPU and sound card from the desktop machine, it will bring that down too.

Its naive to suggest that the Pi5 will be faster for every problem, because the Pentium 4 does have a higher clock, so for single threaded tasks it could still very much remain competitive.

And ultimately, perfectly serviceable for most open-source projects.

Regarding the GPU: a Raspberry has a rather decent one, supporting Vulkan 1.3, and with Linux drivers. Many P4 systems still use AGP.
So the best AGP card is generally the Radeon HD 4670 AGP. This has ~480 GFLOPs vs the Raspberry Pi 5's ~125GFLOPS.

Also note that there is no FreeBSD support for the Pi5 GPU, so you have Zero GFLOPS.

The P4 era also supported early PCI-e, so this opens you up to considerably faster GPUs. There really is no competition here. Which is quite funny for a many decade old platform for a fraction of the price.
 
Remember https://en.wikipedia.org/wiki/Common_Gateway_Interface ?
At a time this was the standard for "interactive" web pages. The request is piped into a external program, processed and sent back.
CGI was mostly seen as "scripts" in Perl but more elaborate web applications used C code.

I am not sure what you are doing wrong

Nothing. The FreeBSD 14.x or 15 DVD doesn't boot, the kernel hangs immediately.
This machine was my daily driver until 2015, it doesn't have issues. It is a rock solid system based on Intel, cpu, mainboard, chipset and SSD drive.
 
But the key message is that development hasn't considerably changed from that era. So needing to buy "modern" machines to develop open-source software is simply incorrect. And you can pick these things up for £30.

Oh I do not disagree with that. Agreed fully that open source development can be done on an older system, even a legacy platform.
What I add to that, is that 30 pounds can also buy a much more powerful, newer, 64 bit CPU platform, compared to P4.

However realistic price is more than those 30 pounds, it is for you and me probably, but not for somebody that's on a budget, has nothing, and looking for a dev. station - in all honesty you wont be getting a case with newer PSU and SSD for that kind of money. For that range, up to 50 euros I can see bland corporate P4 boxes, ideal for this, sometimes in case, sometimes just the mb+cpu+ram, sometimes they have a discrete gfx card, but I've yet to see one retrofited with some good modern ATX supply and a SSD for that money.
 
Its naive to suggest that the Pi5 will be faster for every problem, because the Pentium 4 does have a higher clock, so for single threaded tasks it could still very much remain competitive.
Naive yes, because I didn't checked. It seems so natural to me that a rather modern ARM CPU can beat the worst processor Intel made, 25 years ago, also in single-core tasks.

The Raspberry Pi 500+ (2025) is based on the Pi 5. It features the same 2.4 GHz quad-core Cortex-A76 processor as the Pi 500, 16 GB of RAM and an M.2 slot with a 256 GB SSD preinstalled.

The first benchmark I found. In single-core, it is 1104-991 (the Cortex 2.4 GHz and Cortex 1.8 GHz) vs 237 (P4 3.83 GHz). Benchmarks can lie, but it is 5 times better, and you have 4 cores, instead of 1, and a better instruction set.

So the best AGP card is generally the Radeon HD 4670 AGP. This has ~480 GFLOPs vs the Raspberry Pi 5's ~125GFLOPS.

These are the spec of your 2009 GPU. It cannot decode many video formats in hardware. It does not support modern API.

These are benchmarks of the VideoCore VII.. To be honest, they are not very good. You cannot play many games. But it is a full featured GPU. It decodes all video formats in hardware. It supports all modern API like Vulkan. You can use it on the desktop without problems.

For all practical use, it beats the old ATI card, especially if paired with an ancient P4.

Also note that there is no FreeBSD support for the Pi5 GPU, so you have Zero GFLOPS.
FreeBSD 15 does not support i386, so it is even worse. At least I can hope that the Linux drivers will be ported to FreeBSD.

The P4 era also supported early PCI-e, so this opens you up to considerably faster GPUs. There really is no competition here. Which is quite funny for a many decade old platform.
I have no time to check if a rather modern GPU can work with i386 drivers on Linux or FreeBSD 14. But it is a Frankstein. It does not make logical sense.

As a base, under full load that chip can get to 16W. Then you want to include the same accessories as the P4 machine. Consider SSD, etc, it will be around 40W.

Sorry but this analysis does not make sense. A Raspberry (CPU, GPU, RAM, SSD) can nearly run using a phone charger. Only the external GPU of a P4 system consumes more wats.

In any case this is the last time I will answer you. I replied to non-sense, and it is a waste of time. Probably you are thinking the same of mine answers.
 
Sapling version control system
never heard of that one (but that's not a big surprise because I live under a rock). *click-click* ...meh. It's a VCS. I don't have repos that big.

HOWEVER!? I find this so very annoying.
Code:
$ sl commit -m "Fix bug"
$ vim broken_file.rs
$ sl commit -m "Add test"
1. For what?!
2. For what?!
...I should be able to read the log and determine what you changed and why otherwise what's the point for versioning the files? -i.e. did the bug fix introduce another breakage? did the test leave this memory hanging there?
 
never heard of that one (but that's not a big surprise because I live under a rock). *click-click* ...meh. It's a VCS. I don't have repos that big.
I'm using Sapling in a personal project, on a small repo, and it works wonderfully. It can interoperate with Git repo, with push and pull too.

Probably a more pragmatic choice should be using Jujutsu, that is 100% Git compatible, but Sapling is simpler to use. I like it very much.

EDIT: I'm using right-now on a NixOS bhyve VM, under a FreeBSD server. If I continue to use it, maybe I will try to add to FreeBSD ports.
 
What's wrong with git?

o.0 ...last month I decided I wanted to make/get RCS in a "more distributed mindset" because I have been using the same simple git commands for years and I felt like git/git-tiny was too much bloat. I eventually put it aside but the exercise was a fun diversion.
 
What's wrong with git?
Completely wrong, not much, also because it is a successful project.

Pijul manage repos as set of patches, instead of a tree/DAG. It stores and remember also how merge conflicts were resolved. So it is easier forking projects or branching, maintaining them in touch with the upstream repo.

Sapling follow a "stack approach". You have polite commits, and "working" commits. You can fold and split working commits. Every operation is saved also in a private "operation log", so you have both a clean repo history, and low level details of every dirty operation you have done. You can revert anything. You can move working commits like in a stack. When you are happy, you push finished commits to a Git repo, and during review they can improve them. In practice the operation on the history of commits are more natural and composable.
 
Back
Top