8GB Raspberry Pi 4 Launched For $75 USD

[M@GOid]

People who wish the RPi with SATA ports should really ask themselves if their needs are not better satisfied with a X86 board. Just look at the other RPi competitors that have all sorts of connectivity. They all cost a lot more than the RPi and even surpass low cost PC boards.

There are low cost, mostly ATOM based, boards that are small and powered by 12V laptop PSUs that have most connectors people here want. The RPi will never be a desktop replacement. Is not their market.

[jabl]

If the entirety of Windows XP could run in under 128MB, I am unsure as to why FOSS desktops lacking even 10% of the features of a desktop belonging to a 20+ year old OS, can not do the same!

128 MB, what kind of bloated crap is that? My first Linux machine had 8 MB, and it ran X + some simple applications just fine (get off me lawn!). And it had features like virtual desktops that was missing on Windows, and sorely needed in the age of 14" screens. Started swapping when launching that newfangled NCSA Mosaic though, so the new pastime of "web surfing" was a bit painful. Not to mention a bit later when the bloated monstrosity called Netscape Navigator was released. My next machine had an ungodly 64 MB though, and OMG that was lightning fast.

Seriously though, today I can't be arsed to care. Today's FOSS desktops are miles ahead of what was the norm back then, so if that means an extra GB compared to a barebones environment I think it's money well spent. YMMV.

[zoltanp]

There are low cost, mostly ATOM based, boards that are small and powered by 12V laptop PSUs that have most connectors people here want. The RPi will never be a desktop replacement. Is not their market.

This is the current rational approach.

However, how trustable are Intel CPUs and especially their BIOS/UEFI implementation? With the news about Intel Management Engine's "features", I have some concerns.
Unfortunately, Raspberry PIs need large binary blobs for booting, and AFAIK these blobs have not been audited.
Maybe ARM based devices have some extra obscurity against malware, though.

I would like to see a trustable (open-source hardware, software; possibility for security audit) computer, usable as a decent home-server.

[skeevy420]

This is the current rational approach.

However, how trustable are Intel CPUs and especially their BIOS/UEFI implementation? With the news about Intel Management Engine's "features", I have some concerns.
Unfortunately, Raspberry PIs need large binary blobs for booting, and AFAIK these blobs have not been audited.
Maybe ARM based devices have some extra obscurity against malware, though.

I would like to see a trustable (open-source hardware, software; possibility for security audit) computer, usable as a decent home-server.

With ARM devices, the security comes from the OS used more than anything else. Use Linux and you'll be fine, use Android and you won't be. That's basically true regardless of the architecture.

Frankly, you should be buying a Talos if you're that paranoid and in that much of a need of open source else just stick to low end x86_64 desktop parts since any of cheap stuff you can buy will come with proprietary firmware blobs.

[kpedersen]

128 MB, what kind of bloated crap is that?

Haha. What can I say? I like my 128MB worth of luxuries

Nowadays that same amount would get you... actually nothing, since Fedora 6(?) era initrd wouldn't even fit and load.

[Viki Ai]

Haha. What can I say? I like my 128MB worth of luxuries

Nowadays that same amount would get you... actually nothing, since Fedora 6(?) era initrd wouldn't even fit and load.

Yeah, my Kubuntu desktop is bloated with a huge number of 'features' I don't use (and sometimes even get in my way, frustratingly). I really should look into Gentoo or some similar system that will let me (hopefully) checkbox out a bunch of that with a ports-like system.

[Terrablit]

These SBC board manufacturers need to start standardizing more connectors. The Pi hat is a standard, and it's a very simplistic standard, but there's three problems with it:
1. Sspace on an SBC is very limited, and the connector is pretty big.
2. It's designed for stacking boards, but there's a lot of situations where you don't want extra vertical height.
3. It's GPIO only.

Most SoCs used in SBCs have support for a lot of extra features that don't get used because:
1. It increases the base cost to mount connectors for these and design new board layouts.
2. Not every user *wants* the same connectors.
3. Manufacturing multiple versions of the same SBC just drives up costs.

I'd like to see some versions with smaller connectors and some multi-purpose "feature connectors" - a storage connector, a PCI-E connector, a USB connector, internal/external video connectors, etc. They can even be combined into high-density slots or connectors that expose multiple features, and they can ship little squid adapters to use them. Use of the connector requires you to route every feature you support. Any board that doesn't implement a feature available on the connector still exposes the full connector, but documents what's not supported and disconnects the pins.

Standardize supported distances for the data traveling over the connectors, build small PCBs that use the connectors that be mounted to the side or above, if you get the right set of standoffs for it. The small component PCBs would have standard sizes, and you could get mounting surfaces for stackers at cheap rates. Maybe we could even start shunting a lot of special purpose hardware to 1x PCIe lanes. Perhaps the module-style SBCs could get boards that run all of pins.

With this, people could start building special-purpose hardware with commodity components. Maker clubs and conventions could group-purchase the squids and addon boards. You could swap out the main SBC and the kernel to get newer features. People could buy build chassis adapter kits for servers to convert them to house several low-power ARM boards.

We need a way for SBCs to offer standardized features without having to mount much beyond power and internal connectors. This could reduce the implementation cost and the time to manufacturing. SBCs should be leading the way towards componentizing everything. And they need to design a means to expose new chip functionality without requiring a new SBC design.

Other things needed:
1. Power switch support.
2. Soft-off support so you can actually shut down the hardware without physical interaction.
3. Standardized quality board power connectors for power supplies.

As-is, I don't know that you really save much money building a NAS out of these things. Yes, power costs are lower, but if you're only doing storage on your NAS and it's not super old, it should be using < 35 watts without drives anyway.

[wizard69]

What I'd really like to have at this point is 2 SATA ports.

Wonder why they haven't included it yet.
Cost? Board size? Not an interesting feature for the average raspy user?

SATA is far too retro. I'm much rather see two PCI-Express based M.2 slots though one would do. This especially in the case of PI-5 which would be the logical place for new capability. In a nut shell SATA doesn't have anymore reason to exist on modern hardware than ATA, SCSI or other outdated tech.

[Paradigm Shifter]

As nice as an 8GB model is, after much experimentation with various SBCs since the original RPi arrived, I've painfully concluded that with a few very explicit exceptions, I've had enough of SBCs. If I want something to sit and act as a target for logs, or a personal DNS or whatever, a Pi (or similar) is often great. I've had great fun tinkering over the years with RPi, RPi3, RPi4, ODROID-C1/C2/XU4, etc, but I've also had a lot of trouble at times for apparently inexplicable reasons simply getting them to do stuff that is little more than a compile/install, tweak config files, enable at boot on x86...

[wizard69]

With 8 GB of RAM or even more it's about time to switch to a 64bit userland.

Just install a 64 bit ARM distro! I have to agree that the people running the PI program have some sort of block over 64 bit OS's and the future of computing but the hardware is open enough and the volume is there that 64 bit distros do exists. It will not take long for other hardware to fill the PI niche if they don't go 64 bit soon.