Another important thing to mention: if you're compiling and logging to the sd card, buy a lot of them because they'll die on you. They're not designed for this many writes.
Yes. I use mine for a lot of back-end development (I can run Ubuntu on them and Docker, and have a bunch of containers built for them as well, via a multi-arch pipeline[1] I have been adding to for a while and just cleaned up for re-use).
I run Nginx -> Postgrest -> PostgreSQL on the R.Pi, and it has served me faithfully for more than a year. It is blazing fast ( _for my needs_ ) and I can quickly replicate and setup another R.Pi if needed in a jiffy. I can't wait to port my setup to the new ARM64 R.Pi4!
Oh my! This is such a crazy upgrade. I've been using the RPI2 as my HTPC/NAS at my folks, and I'm so happy with it. I was itching to get the last one for myself.
USB 3.0! Gigabit Ethernet! WiFi 802.11ac, BT 5.0, 4GB RAM! 4K! $55 at most?!
What the!? How the??! I know I'm not maintaining decorum at Hacker News, but I am SO mighty, MIGHTY excited!
I'm setting up a VPN to hook this (when I get it) to my VPS and then do a LOT of fun stuff back and forth, remotely, and with the other RPI at my folks.
It might work "well" as long as you don't need a lot of capacity, nor do you care about the fact that everything is running at < 30MB/sec.
The existing rpi lines are seriously IO bandwidth constrained in every manner. The USB3 on the 4 hopefully fixes some of this. Bottom line, unless you don't mind your photo's taking minutes to copy, your going to be much better off with pretty much anything else besides a rpi3 as a file server.
Using the Pi as a file server can be a bit flaky. The ethernet controller was an USB one, and was neither really stable or took load very well. The new PHY on a dedicated link is probably the single biggest improvement with this new revision.
The HEVC is a bit unexpected considering the high license fees and general uncertainties. Let's hope the documentation can be released as well.
So unsure at this stage, but that may well be the case for any license fees regarding HVEC. Heck, if they have absorbed those costs into the base price - I'd be utterly amazed.
I just setup my RockPro64 with 4GB, also PCIex4, have an SSD, going to setup a raid at somepoint when I get it all figured out. The board was a bit more expensive than the pi4, but I am interested in playing around with it.
> The ethernet controller was an USB one, and was neither really stable or took load very well
Hmm... that explains a problem I had with a pi of mine. Every time the 10/100 switch it was connected to rebooted, the pi would lose its ethernet link until rebooted. Never had this with other machines on the same switch.
There is an official PoE board that fits the pi 3+ which uses a 4 pin header by the ethernet jack to grab power. The pi 4 appears to have the same header.
I have one of these but am new to RPi. It covers all of the GPIO pins in addition to the four header pins for power. Is there any way to still use the GPIO pins with the PoE hat?
I agree that it would be nice if PoE was built in, but there are better ways to say that than what you said.
Also, the HAT has a transformer (and I assume if they included it, they know what they are doing), which seems like it would be too much for every single Pi to include one.
I'd guess primarily the lower volume of the PoE HAT would play a role here. But, it's also a fully isolated power supply with a fan. To me, it looks like this couldn't be made on a fully automated line, so there would need to be manual assembly, which is also more expensive.
did they finally release the 100W spec? IEEE really let that spec languish for too long -- vendors got impatient and implemented their own. i had to write 60W PoE code supporting three different specs around 2015. bosch's design was the worst.
My point was that PoE, especially with the recent revision, allows for very useful levels of power to be drawn, so if you're going to have an 'embedded' system with an Ethernet port, I would think it'd be useful to use it.
Why plug in two cables (USB-C (power) and Ethernet (comms)) when you can just plug in one?
I agree with your excitement! I've been waiting for this upgrade forever. I keep looking at the other options out there, but while their hardware is great, their software is terrible.
Even so, A72 is a highly-inefficient chip (which is probably why they set such a low clock speed for it). Cortex-A73 would've been much better. But I guess there always has to be at least one obvious lacking in Raspberry Pi generations.
I'm intrigued as to why they didn't use a big.LITTLE design (or whatever they're calling it these days). Perhaps mainstream-linux still isn't so great at handling it.
Really the only benefit of that is energy efficiency if it is used correctly, in exchange for additional cost or lower max performance. Makes sense for a smartphone, less so for a mains powered device (and the Raspberry Pi SoCs originally were designed for set-top boxes, although I don't know if that's still true for the new ones or if they're custom)
Sure, if you're doing CPU-only tasks, Jetson Nano is A57 and Pi4 is A72 which is maybe twice as fast, but if you can offload anything to the GPU at all (media encoding, neural networks, matrix operations) you'll probably get some enormous gains in efficiency with the Nano.
OTOH, your going to be pretty much stuck with whatever handouts nvidia gives you unless your willing to hack the firmware/etc and reverse engineer stuff.
Pretty much everything works on the existing rpi. Heck you can run Windows IoT on it. It has a UEFI firmware (edk2) port which mostly complete, and pretty much every distro and 3rd party OS supports it. And the hardware itself is mostly open at this point.
This. Jetson is part of NVIDIA's pipeline to drive customers to their chips. Raspberry Pi is vaguely that for Broadcom but is much more an end in and of itself. RPi is massively supported on the web.
If you're doing stuff that needs the Jetson, it's great, but the Pi is definitely better supported.
The Nano's GPU is half of what is available in the Nintendo Switch. Based on some benchmarks I've seen, the one in the Pi 4 should be between 2 and 3 times slower.
> Jetson Nano is A57 and Pi4 is A72 which is maybe twice as fast
A57 and A72 are very close in performance, as the A72 is an evolution of the A57. ARM's numbers have the A72 around 20-30% faster than the A57. The main advantage of the A72 was it fixed the horrific power problems the A57 had so in a phone usage you could actually use the CPU for longer than 10 seconds. But in raw performance it wasn't that much of a jump. A53 to A72 is around 2-3x as fast, though. A53 was the power efficient one. A57 was the performance one.
Both the Jetson Nano & Pi4 are clocked at around 1.5ghz, so the Pi4 should still eek out a bit of a CPU performance gap over the Nano. But if you're purely comparing factory vs. factory then the Nano would probably win over longer stretches as the Pi4's lack of heatsink results in it throttling down to around 1ghz after a few minutes. The Nano looks like it has a beefy enough heatsink to keep the A57's churning for a lot longer at their 1.43ghz spec.
It is in that the rasp pi's price doesn't have much slack. So it will never really go on sale whereas most other hardware with a few exceptions has a lot of slack. So it seems fair to compare the projected prices of things.
So, one party by default overcharging for their product and the other supplying it at cost makes you feel that when the one party puts their product on sale, a temporary condition at best the product suddenly become equivalent?
Then you should also compare the Chrombooks with second hand large format laptops, old servers on sale with new ones and so on.
Chromebooks 'on sale' are an entirely different class of product than raspberry pi's, they are larger, need wall power, have built in batteries and screens, are in general still more expensive and do not have GPIO.
I'm not singling out chromebooks. I'm just saying at $100 price point is crowded with a lot of old and new hardware. So a raspi may not be the best thing for you at that price point.
Not really, what matters to me is the price I can get them at, including shipping, including taxes, including shenanigan fees, including sales, including discount codes, including 5% cashback on Amazon, including 1% cashback on other sites.
If you have a Microcenter near you, they often have 'in store only' sales. Right now a Zero W (limit 1) is $5 and a 3B+ is $25. Right now they list the 4GB 4B due in on the 28th for $55. (All $ in US.)
Sure, wasn't meant to be. Just saying that if you want to use the new capabilities, don't already have the accessories and buy the official ones it adds up. The older ones were cheaper, had less requirements and more common accessories.
IMO, at this point you're not paying so much for the pi, but rather for the community and accessories. It's the entire environment that makes the pi useful; not just the hardware.
(I speak as someone who sucks at programming and doesn't spend a 1/100th of the time learning the latest as I used too as a teen. So having the community around to help with my latest project that I need something more than a microcontroller for, is immensely worthwhile. Obviously those who don't need these types of spillovers would probably be better served with other hardware.)
I mentioned it above, but just to reiterate- there are lots of great hardware boards out there and many beat the Pi (though the 4 makes up the different finally). However, they ALL have terrible software support: old OS's, bad drivers, out of date or incomplete documentation.
To add to this, the bad software support had very real performance implications as well. I was surprised to see benchmarks where the Pi 3 dominated boards that very clearly beat it on paper
That said, does the pi have accelerated graphics yet? I was playing with pygame (based on SDL) and I think all the blits and other operations were in software.
The big shortcoming of the other Raspberry Pis I have is power. Plug anything into it and you risk undervoltage problems (even with the official supply)
I have one system where I relented and did that, but really, for many generations of pi... why is this even a thing?
For example, recently I plugged in a USB stick and a webcam and couldn't boot. So I would boot, then then plug in the webcam ... carefully. And there were still 2 usb ports free.
"The Ethernet controller on the main SoC is connected to an external Broadcom PHY over a dedicated RGMII link, providing full throughput. USB is provided via an external VLI controller, connected over a single PCI Express Gen 2 lane, and providing a total of 4Gbps of bandwidth, shared between the four ports."
> The BCM2835-based chip in Raspberry Pi 1 to 3 provided just one native USB port and no Ethernet, so a USB hub on the board provided more USB ports and an Ethernet port. The 3B+ added a dedicated LAN chip, which gave it Gigabit Ethernet, but this was limited to USB2 speeds. The Pi 4 has dedicated Gigabit Ethernet, and because it's no longer throttled over USB, its networking speeds are much faster.
> In the past, we’ve indicated 2020 as a likely introduction date for Raspberry Pi 4. We budgeted time for four silicon revisions of BCM2711 (A0, B0, C0, and C1); in comparison, we ship BCM2835C2 (the fifth revision of that design) on Raspberry Pi 1 and Zero.
> Fortunately, 2711B0 has turned out to be production-ready, which has taken roughly 9–12 months out of the schedule.
> In the past, we’ve indicated 2020 as a likely introduction date for Raspberry Pi 4. We budgeted time for four silicon revisions of BCM2711 (A0, B0, C0, and C1); in comparison, we ship BCM2835C2 (the fifth revision of that design) on Raspberry Pi 1 and Zero.
> Fortunately, 2711B0 has turned out to be production-ready, which has taken roughly 9–12 months out of the schedule.
According to their article they finished after 2 revisions rather than the predicted 4-5.
The addition of gigabit ethernet and USB 3.0 means that a Pi no longer feels like a bottleneck in one’s home network. I know that the Pi was invented as an educational product, but thanks to the Linux distribution OSMC it is commonly used as a media center for playing films, music, TV, etc.
I have had gigabit internet for a few years now, and every day on average, I torrent a Blu-Ray image onto my main computer. However, subsequently moving the Blu-Ray to my Raspberry Pi 3 media center is always slow on two counts: 1) ethernet from the router to the Pi was limited to 10/100 speeds, and 2) the Pi could push large files to an attached hard drive only over a USB 2.0 port. Consequently, on a Raspberry Pi 1–3 it takes an hour just to move a high-definition file around one’s home network! On a Pi 4, it looks like one can just put the torrent client directly on the media center.
I imagine the wait must be agonizing! Why not just have a NFS server on your more powerful computer for the Pi to stream the file from? 100 Mbps is easily enough to stream any Bluray.
> Why not just have a NFS server on your more powerful computer for the Pi to stream the file from?
The “more powerful computer” is a laptop, and it is only being used for torrenting the films because it has gigabit ethernet. I don’t want to have to leave it on all the time, and sometimes it is still packed in its case when I want to sit down and watch a film. Storing the films on a hard drive attached to the Pi is a lot more convenient.
I haven't actually seen a single 1080p raw bluray file with a higher video bitrate than 35 Mbps. Maybe with TrueHD/Atmos audio the total bitrate could push past 40, but 100 Mbps is way more than you need for 1080p.
Even 4k doesn't seem to push past 50 Mbps, but I think that's because h.265/HEVC is more efficient for the same observed quality/CRF.
You are right. I don't know what your parent comment is talking about.
Blu-rays use H.264 High Level 4.1. That has a maximum bitrate (for a single buffer) of 50 Mbps. The average bitrate for an entire disc is usually closer to 25-30. Even the most extreme cases, like the mastered-in-4K Lawrence of Arabia, have peaks at about 48 Mbps, and average bitrates of about 42 Mbps.
If you're having issues streaming Blurays on a 100 Mbps network, the speed of the network is not your problem!
NFS can not use the entire raw bandwidth for application data, and it is very likely that mplayer compresses its filesystem calls instead of making a perfectly spaced stream of them.
Also, Ethernet does simply stops working way before 100% of the bandwidth is used.
I don't know why you expect things to run smoothly at 50% utilization.
NFS is not the most effect protocol however NFS3 over UDP should be able to hit 75% liberate on that 100M link easy. Something else is the bottle neck here. I have done a great deal of testing on this on 100M all the way to 100G links in my career and properly tuned you should be able to hit 80% or so or the link speed at real data through put.
> If you're having issues streaming Blurays on a 100 Mbps network, the speed of the network is not your problem!
Well, it COULD be the problem if you're not actually getting the 100 Mbps. I've diagnosed WiFi that should have a lot more headroom than 100 Mbps but still stutters on mid-bitrate 1080p. Signal degradation
The ethernet port on the 3B+ is still attached to the USB hub on the board. In my tests it never gets more than 300 Mbps. The Pi 4 should have true GigE support because it doesn't have that limitation.
Just read theverge review on how the Pi struggles to play a video full screen, even if resolution is 480p. How are then people using it as a media center?
I've never had these problems with the various media center apps. My Pi 3B+ has been running Kodi for a few months now, and it happily plays 1080p videos at what appears to be smooth 60 FPS.
Mind, this is specifically running under Kodi, which is optimized as a media center, and is NOT running also a full desktop environment. Attmepting to do the same in, say, the stripped down Chromium browser was an exercise in frustration. That's always been a major limitation of the 3D acceleration in the Pi, as the libraries took a long while to mature and were always a bit hacky.
The announcement for proper OpenGL support and compositing in the desktop environment is huge for me. It seems like it'll finally push the Pi up into "workshop computer" territory that, while underpowered, should be just capable enough to run some of my always on operations and act as a lightweight CAD station for small parts. I ordered one as soon as I woke up and saw the announcement, and we'll see how well that works in practice.
Likewise. While a lightweight desktop on even the 3B+ can be excruciatingly slow, I ws using the 2 as streaming media center for 1080p video without issues. The main thing to look out for is compatible codecs.
What review did you read? Playing video is likely the only thing the PI 3 does really well; even most H265 FHD do play without stuttering on the 3+ although we're close to the board limits.
Are you sure the writer didn't use the board the wrong way? Some people still believe that videos should be streamed after being transcoded because that is the only way to watch them on their ridiculously limited smart TV which lacks the necessary codecs to watch them the right way. Of course doing this over WiFi would make the problem even worse.
To optimize network usage, videos should be kept encoded until they reach the player so that the network won't be clogged. If you use the PI to read the movie as a file over a shared SMB or NFS directory, the network usage is so low that you could watch like 20 different movies on 20 different players on the same home network at the same time. Probably even more.
The PI 3 (and to some extent probably the PI4 too) is still behind many other boards in other contexts (openness, performance, price) but playing video is surely not one of them.
Apparently Verge said it "reportedly" struggles with 480p "Youtube videos". Which is doubly wrong, as who knows whether whatever mechanism was being used to play Youtube even supports the hardware decoding capabilities of the Pi.
I'm not sure that transcoding has anything to do with it, unless the transcoding was happening on the Pi itself (which would indeed be dumb). Most of the time people are transcoding things it's x264 -> x264 with Plex, just with a much lower bitrate (and probably 720p) because (as you say) their player's platform can't handle it and no one cares about video quality these days.
It wasn't The Verge that originally said the Pi4 struggled to play YouTube videos [1], it was Tom's Hardware [2].
Tom’s Hardware’s review notes that the hardware is able to handle many everyday tasks such as web browsing with up to 15 Chromium tabs, light image editing using GIMP, and document and spreadsheet work using LibreOffice. Unsurprisingly, the sub-$100 miniature PC has its limits. It reportedly struggles with full screen video playback from YouTube for example, even if you turn down the resolution to 480p.
Tom's Hardware were using a pre-release OS so it's possible the issues with video playback were caused by this?
It’s important to note that, at launch time, some important Raspberry Pi software doesn’t yet work on the Pi 4. To run Pi 4, you’ll need to download a brand new build of the Raspbian OS, Raspbian Buster. And not everything runs in Buster yet. During testing, we found numerous Python libraries or other required packages that weren’t compatible with the new OS.
My biggest problems involved video playback. If I wanted to watch a YouTube video, I had to keep it in a window, because even in 480p resolution, it was jerky at full screen. The other task I’d like to perform is playing retro games, but as of this writing, the Retropie package of emulators doesn’t work with Pi 4.
During extensive hands-on testing, I found that, while the 4K at 30 Hz is tolerable, little things like the movement of the mouse pointer are a bit sluggish. If you have a 4K screen, you’re definitely better off going for the 60 Hz mode, but note that the added voltage may also cause your CPU to get hot and throttle more easily.
While surfing the web, looking at still images and just enjoying all the extra screen real estate of 4K is great, video playback is the Raspberry Pi 4’s Achille’s heel, at least as of this writing. Whether we were attempting to stream a 4K video or use a downloaded file, we never got a smooth, workable 4K experience, either in Raspbian Buster or LibreElec, an OS that runs the Kodi media player. Several H.264 encoded videos, including Tears of Steel, did not play at all or showed as a jumble of colours. Even the sample jelly fish videos that the folks at Kodi recommended for my testing appeared as still pictures with no movement. Clearly, there’s a lot of optimization that still needs to be done both on the OS and software side to make the Raspberry Pi 4 capable of playing 4K video.
Unfortunately, even streaming 1080p YouTube videos is a challenge at this point. Running at 1080p resolution, full screen video trailer for Stranger Things showed obvious jerkiness. However, the playback was smooth when I watched the same clip in a smaller window. The same problem occurred, even when I dropped the stream’s resolution down to 480p.
Playing offline 1080p videos works well, provided your screen is at 1920 x 1080 or lower resolution. A downloaded trailer of Avenger’s Endgame was perfectly smooth when I watched it using the VLC player.
My slightly older Intel NUC struggled hard with YouTube too, until I installed the extension that forces YouTube to serve me h264 content rather than vp9. After that it has been butter smooth.
tl;dr they "built a gaming pc" with a "wireless anti static bracelet", RAM installed in single channel, backwards PSU, terrible parts choices... don't trust the verge.
Can you link it? Was the video streaming or playing from disk? Perhaps it was an unsupported video codec? There are certain circumstances where the pi may struggle to play video, but I think for common formats they graphics driver has hardware level support for decoding. If the video format was weird and it had to decode with the CPU it could see problems. Another issue is the power supply. If you do not use a quality 2A power supply, a little red light by the power jack will indicate reduced power and it will throttle the CPU. This applies to the older PIs, but I've not seen the Pi4 yet.
Are you running it as both NAS storage and a Plex server? How's transcode performance?
I put together a NAS/Plex box with a Kaby Lake Celeron and some hard drives, but I was thinking of splitting it out into separate NFS and Plex servers.
As to properly balance out this review, what exactly were the issues you had that needed to be answered by a community for the RockPro64? The RPi seems to have a slew of things that just work on it out of the box, and if there are issues, 99.9% of the time you can find the solution with a quick Google. Very curious to understand what type of issues something like the RockPro64 (which has appeared numerously in this thread as a 'great alternative') faces for anyone interested in the alternatives.
I'm looking at buying the raspberry pi 4 right now, as I've been thinking of getting something to replace my odroid-c1 for a while now.
My understanding is that the RockPro64 has pcie slots on it, which allows Sata boards so you can connect drives directly without usb. Personally, I'm more interested in the odroid-h2, with the native Sata. Unfortunately, it costs far more ($111 without ram) and has no wireless connectivity built in.
Keep in mind that you are in a very small world there... most people alive today will never have internet that fast, personally i've never had a connection above 6 Mbits in the middle of a city, and I know that's likely above the median globally (keep in mind average is a poor metric due to connections like yours, SDL is still the primary type of endpoint for homes)
My point being, the previous generations USB based ethernet still has massive headroom for the vast majority of peoples internet.
+ USB 3: Very nice! Finally a pocket-sized, fast USB host.
+ Dual HDMI: Could be useful as a projector computer.
+ 1.5 GHz: Good, it might be fast enough for some real work.
+ Gigabit Ethernet: Excellent for those using it as a NAS.
+ USB-C for power: Not surprising, it's the standard now.
Cons:
- MicroHDMI: Incompatible with the 800x480 HDMI 3.5" screen [1]. Also different again to the MiniHDMI on the Pi Zero (will there be a new Pi Zero soon? Who knows.)
- Power consumption! They recommend a 15W power supply, which means I'm pretty sure this won't run on batteries.
Yes, there are adaptors, but it won't fit with the same loopback HDMI board that's included with the screen. It'll need a wire, which effectively doubles the space it'll take up on a desk.
If there are any other high-res small (<= 4") screens, please let me know - the highest DPI that I know is an iPhone 4S 960x640 3.5" screen with a Creotech adaptor.
certainly a good idea for stuff / locations that have regular writes, just be nice to use a more durable boot disk, hopefully booting via USB storage is well supported
I stand corrected. Turns out it's implemented quite differently and neither netboot or booting from mass storage is supported for pi 4 yet. Hopefully we won't have to wait long.
I have a ClusterHat on a pi3. I am rather looking forward to using it on a p4 since memory space was primarily the issue I had with the controller. The 4 zeros are fine because I don't run a gui on them. The extra speed between the bunch of them will probably go a long way, too.
I’m not very familiar with the hardware here but could someone elaborate on why this seems to be such a big deal that there are four versions of the announcement trending on the first page?
It's a combination of an exciting and hugely popular device gettting a huge upgrade (RAM and networking speed has previously been really limited) and the completely suprise of the announcement: The version 4 was supposed to arrive in 2020, but apparently hardware development went quicker than expected.
You can buy a pretty powerful full computer (networking, video, RAM, etc) that fits on a tiny card for $35. That makes it possible to build all sorts of fun things on next to zero budget - everything from robots to video game emulation systems and tv streaming boxes.
The previous 3 versions were already wildly popular, but there were starting to show their age and to be significantly outperformed by Nvidia's Jetson Nano. But the Jetson Nano is significantly more expensive (starting at $99). This fixes several of the performance issues people had and keeps the price at the original $35.
I always feel like I'm missing something. I don't have a single idea where something like this could be useful. Maybe because I don't care about "fun" projects and live a quit minimalistic live style? I must don't have (small) problems with no solutions. Then again, I've also never had an idea for an interesting software side project.
Another way to think about this is that it's the antidote to seamless portless iGlass slabs for $1000. You've got compute, a pile of mainstream ports and wireless interfaces, GPIO pins and an established ecosystem, all for basically no money. It's an open enough platform that kids, adults, startups, schools, and companies have found endless uses for them, ranging from toy projects for learning purposes to production use in for-profit settings. It's a radically different vision of computing vs. the iStore, and one that deeply appeals to all the hackers and makers out there. It's not a product as much as it's a raw material.
My comment wasn't meant to criticise, just open self reflection. Even reading about some of those projects, I still don't get it and wonder why. What makes some people see this tool and get all excited about the possibilities, while others like me can only shrug their shoulders? As said before, I think I'm missing something, something great I like to have but just don't.
Honestly most raspberry pis are just gathering dust in a drawer somewhere. Unless you want to program on ARM there is no really compelling reason for an average developer to have one. If you have a specific use case, then you already know why you need one.
I have no actual data, but I would be willing to bet that a large percentage sold are used to build multi-video-game emulators or video streaming boxes instead of actual hacker projects. Both uses have premade software images and are nearly plug and play and give you a lot more options than commercial offerings like an Apple TV or Nintendo Classic.
Raspberry pi significantly lowered the barriers to entry for cost and complexity to own a useful Linux computer. The performance for price is really impressive to the point where it seems like the rpi 4 could be a decent daily driver for most people.
Every year we upgrade our autonomous sailboat controller to the latest Raspberry Pi. This year we face a situation to choose from Jetson Nano and RPi 4. Even the decision is hard to made, now is an exciting moment for robot makers.
>Yes. VideoCore 3D is the only publicly documented 3D graphics core for ARM‑based SoCs, and we want to make Raspberry Pi more open over time, not less.
This stated intention and rpi.org's actions are simply not isomorphic. If they want to make Raspberry Pi more open, firstly, why do they publish only abridged (read: fake) schematics? [1]
Secondly, why was rpi.org caught adding DRM chips to their optional camera addon board? [2]
As a previous line manager one said to me “yes, and I want a pony”. That they want to be more open does not mean they are currently fully open – in fact, it requires them to not yet to be fully open. Their primary goal (last I checked) is to be cheap, being fully open is at the very best their secondary goal.
That doesn't follow. Firstly, I don't think I've seen any other SBC vendor fail to publish full schematics. This is a peculiarity of rpi's offering.
Secondly, nobody is forcing them to add DRM chips to anything. That's not something that can be written off on "a contractual obligation made me do it." They did it of their own will.
The camera PCB was made by rpi for specific use with the rpi. The DRM chip is not part of the camera vendor's assembly. It is a separate chip placed on the PCB, therefore placed there by the PCB designer, i.e., by rpi.
> You can plug any CSI camera into the Raspberry Pi. There's even a kernel driver for the CSI receiver, which we paid for ((link: https://patchwork.kernel.org/patch/9951525/) patchwork.kernel.org/patch/9951525/). What you can't do is clone the official v2 camera module and use the default ISP tuning, which we also paid for.
That's a fair point. Perhaps when camera v3 is released they'll have the option of updating start.elf and removing the restrictions on using this hardware.
Well, it's optional in the sense that if you can find a way to use the camera with some board other than a Raspberry Pi then you don't have to use it. If you're doing the intended thing of connecting it to a Raspberry Pi, though? Not optional.
Firstly because the rpi foundation is the one manufacturing the camera units. They are buying parts from vendors, not assembled units.
The more components you use, the more expensive a product is to make. They also don't just have DRM chips inseparably piggybacked onto things like CMOS camera sensors.
> Vendor: “Certainly. We sell $thing for ten dollars per unit if it doesn’t have DRM, or five dollars per unit if it does.”
Hah - sounds like the "boneless vs bone-in steak" sales model - take the bone out of the steak, and suddenly it costs more per pound than it does with the bone left in. Somehow, less costs more - and people sadly pay for it.
Other SBC makers don't have an issue offering full schematics, yet, due to their smaller size, have relatively more to lose from being cloned. Moreover, I hope nobody believes that a lack of full schematics is going to stop people from making clones. Schematics can be reversed with not too much effort. Due to their large audience and brand recognition, rpi actually has less to fear from clones than smaller SBC vendors.
If anything, it seems like they've judged that their large size and brand recognition is something that they can coast on to avoid having to offer what other SBC vendors do.
I'm not complaining about rpi existing, I'm pointing out that what they offer is in certain aspects inferior to the offerings of smaller SBC vendors, which is actually surprising, given that their large size should make them much better resourced to match or exceed the offerings of those vendors. This causes me to question whether these values are actually a priority at all, even if they claim so.
How are you a non-profit if you pay a salary to you employees and allow your suppliers to make a profit?. They act as a 'low profit' company, but they do make profits.
Do you realise that non-profit means that you just don't have leftover cash at the end of the year in your balance sheet? Non-profits pay their employees and their suppliers, their financial situation has absolutely nothing to do with what you are implying.
I think the gp’s point is that to a lot of entities (employees, suppliers) there is little difference between for profit and non profit. And if your nonprofit is passing profit along to a for profit ... you can see how the lines blur. Maybe a way to interpret the above comment is that the incentive structure for many people involved is not significantly impacted by the nonprofit status. And non profits can have money left over at the end of the year, they just don’t distribute it to shareholders.
The Raspberry Pi Foundation is a charity registered in England and Wales. "The object of the charity is to further the advancement of education of adults and children, particularly in the field of Computers, Computer Science and related subjects." They have a trading subsidiary.
Anyone sufficiently cynical (not me) can read the accounts of both entities:
I thought being a non-profit meant you had goals that weren't profit; there are non-profits with billion dollar endowments that presumably have leftover cash on their balance sheet...
It's very unlikely releasing schematics would change anything.
RPi as a board is clearly simple enough that there would be clones if you could get components at competitive prices. The only conclusion is than that you either can't get the CPU, or you can't get it at a competitive price.
RPi use Broadcom chips, which you rarely find these on other hobbyist boards.
The most likely cause, after what I heard from people in the industry, is that you usually either can't can't get Broadcom chips at all, at acceptable prices, or even documentation for them when you are only interested in the small quantities you'd need for introducing a new/clone hobbyist board. Not unless you've got some serious connections.
Yes, given the recent discussions how some projects were surprised that many companies are putting non-copyleft licenses to good use of their investors, when they are full compliant with what the license requires from them.
I believe the point was that some people don't think that view point is fine. No one has yet taken ownership of that position apart from possibly the great grandparent
They've specifically said that the camera module DRM chip is there because they make money from selling the camera modules and they don't want third-party cloners undercutting their pricing and eating into their profits, as happened with the non-DRMed version one of the camera module. Thing is, the third-party camera modules aren't just much cheaper, they're also offered in a whole bunch of useful variants that aren't offered officially. So in order to ensure their continued profits, they're using DRM to actively make their platform less useful.
> So in order to ensure their continued profits, they're using DRM to actively make their platform less useful.
but that is demonstrably not true. The CSI interface and driver is opensource (https://patchwork.kernel.org/patch/9951525/), anyone can create a camera that piggybacks onto that port. Infact, there are a number of aftermarket cameras that do. Some have built in infrared, some are tiny.
What they are attempting to do is stop counterfeit "official" camera.
Also, all that money goes to either developing more board, or running educational outreach. So I think one can forgive them the urge to protect revenue. It's not like they are microsoft in the 90s, or oracle.
The CSI interface is open source, the image processing hardware to take the data and turn it into actual images is not - it's run by a proprietary undocumented blob on a proprietary undocumented core. So you can interface to whatever camera you like, you just can't use it as a camera. Even that part wasn't open source until well over year after they added the DRM chip.
Every one of those afternarket cameras - the tiny ones, the big ones with replaceable lenses, the IR ones, the funny fisheye ones, all of them - works around this by using the same sensor as the official v1 camera and looking enough like it that the existing code will talk to it. This is precisely what the Raspberry Pi Foundation added the DRM chip to the v2 to stop people from doing. They can't do anything about the v1 clones, but they can stop anyone from doing the same with the better sensor in the v2 and they have.
(In theory the open source CSI driver is useful for non-camera hardware though - for example, there's one obscure third party board that uses this for HDMI capture. I think this may be the main intended purpose. It came too late to save the Kickstarter campaign a few years back promising such a board though.)
Is 1) really valuable? There's plenty of computer hardware you could put a fully open software stack on that's as or more powerful than an RPi and would otherwise just end up in a landfill or whatever. Open hardware would be significantly more interesting.
Yeah, I know. The people who stock the vending machine at work throw out 'expired' stuff all the time that I swipe. Your point? We absolutely should not be wasting this stuff, it's bad for the environment, and it's bad for our wallets.
There is merit to ecological reasoning, but sometimes people like nice things; and concern over the use of pi’s over existing arbitrary computers is so low on the list of ecological priorities that perhaps it’s better to simply recognize the value it provides to people who want to buy one.
No droplet feels it is responsible for the flood. These things add up.
I'm not saying Raspberry Pis don't have a place, I just think a lot of things people seem to want them for would be better suited by just reusing old hardware, which has the nice side effects of meaning that hardware isn't wasted.
Citing the part with the VideoCore is just fully nonsensical. The Raspberry Pi is the only SBC out there with a fully open-source, production-level graphics driver.
> This stated intention and rpi.org's actions are simply not isomorphic. If they want to make Raspberry Pi more open, firstly, why do they publish only abridged (read: fake) schematics?
Why do people tend to dismiss the openness of the RasperryPi with completely unrelated things? This is the classic case of Whataboutism[0].
Just because you can't replicate the entire product in your garage, it doesn't mean that it isn't quite open already.
I don't agree with the parent but it isn't an example of whataboutism.
He's taking issue with the stated aim of openess, with examples he feels aren't open.
> Secondly, why was rpi.org caught adding DRM chips to their optional camera addon board?
to stop counterfeit boards. There are many _other_ cameras that you can use for the rpi, so its not like they are trying to block out competition. its to stop people making illegal clones and ripping people off. (cough I'm looking at you amazon)
Thanks to you and @kingosticks above for digging up these official accounts.
Cursory examination of rpi firmware suggests that this DRM logic is implemented in start.elf, one of the proprietary blobs required to boot an rpi. This is, in itself, significant, since opening this blob would obviously make this restriction easy to circumvent. In other words, rpi have taken design decisions which essentially motivate them not to open up these boot blobs, but rather use them as a chokepoint of control over the platform, see also [1].
From this, we can infer that rpi.org will probably never get rid of these boot blobs (as opposed to simply not having found the time/resources to do something about them).
You are right, they probably won't open the blobs if it means circumventing their own DRM, which I think has been shown to be used reasonably. The mpeg license has almost the same argument as the v2 camera, I think we have covered that.
But that aside, "as a chokepoint of control over the platform"? What platform are you specifically talking about?
I don't think they got rid of the blob, so much as moved it from the SD card to an onboard SPI flash more like you'd find on a typical PC. It's still there and even more required to boot the board than on previous Pis, but people distributing images no longer have to worry about the licensing and other headaches that were caused by having to include it.
There's a mainline driver that according to their own statements is now used for the gpu. Whether there's a firmware blob underneath it is a whole other story and as long as it's not something that has to be distributed with the OS I don't see how it should be treated any different than e.g. the AMD or intel gpus.
IIUC, you're saying that, for the Raspberry Pi designers, being open hardware is not only not a requirement, but there's actually requirements to be aggressively closed hardware in some regards?
I don't think one can paint attempting to stop counterfeit cameras (which were aggressively counterfeited) as being aggressively closed hardware.
Look Rpi have a clear goal, to get kids coding. Everything, and I mean _everything_ they do is to further that goal. One part of that is to have a platform that is, safe, easy, expandable and _cheap_. A side effect of that is that its mostly open.
Now, is it as open as say fabbing your own RISC-V SoC? no. But then that would cost a boat load of cash, and it would then be cloned and resold by third parties. Thus, no money for education. (worse still, dangerous counterfeits might be bought by schools, cause injury leading to legal action.)
So, being pragmatic, and noting that the ecosystem is far more valuable to me, and almost everyone else, than the hardware, I will accept this behaviour.
It's fine if that's their requirements, but that wasn't clear originally.
It seems that people who care about technology open standards, open source, and open hardware need a clear understanding of Raspberry Pi requirements, and that they're actually getting hardware that is more closed than a typical PC.
(Related: Starting over a decade ago, some IBM ThinkPad models infamously whitelisted mini-PCIe cards, so that only a small set of particular cards could be used, which was very unusual for PC hardware based on open standards. One of the biggest practical reasons to put Coreboot on those ThinkPads is to get rid of the awful whitelisting, so that people could use whatever cards they wanted, including using WiFi cards supporting later standards and working without having to download closed firmware blobs.)
It was always the requirement. It was designed as a machine to replace the BBC micro.
most PCs have BIOS, which is closed source, and difficult to get access to. yes there are opensource alternatives, but they are not entirely practical.
Most modern PCs have a TPM, EFI and a whole host of other bits that make opensource drivers exceedingly difficult. Then there is the graphics card, where if you want to actually have decent speed it means closed source drivers (I'm talking nVidia/ATI, intel doesn't really count as they are adding GPUs as a value add, not a core business.)
Harddrives have closed source and obfuscated software that actually does the writing/reading.
Then there is the out-of-band management that is shoehorned into a lot of Intel and AMD's kit.
so, to say that it is more closed than a PC, is either ignorance or hyperbole.
Also, you have to remember that yes, the PC was based around open standards, but not open source. You still had to pay to get certified, or even get access to the spec.
Considering that you can attach any hardware either in the form of a HAT, or via the CSI, I think the argument is flawed. Again, there is nothing stopping people using a clone, if they so wish. But all the rpi clones appear to be mediocre at best.
Although PCs have traditionally had closed-source firmware, this firmware has not typically been used to implement malicious functionality (aside from cases such as the Thinkpad example above), making it historically less of a concern (though this is changing). Vendor lockin doesn't magically become acceptable because kids (nor is it ethical to teach kids that DRM is okay/normal).
Also, define rpi clone - rpi did not invent the SBC genre. Many more open products precede it.
> not typically been used to implement malicious functionality
so raspberry pi, in an effort to be more open than say Dell/HP, where you had/have to pay to download drivers, bios and other updates, is _more_ malicious than say apple/google who are competing to create a closed garden with a remote lockout, where nothing is owned, only rented?
ya.
I really don't understand this viewpoint.
Look, I've used embedded 386s. I've seen the evolution of ARM SBC first hand. I've used gumstix, sheevas and custom rolled jobbies. You know what united them all? they were bloody expensive and difficult to use. Pis are a joy to use. Plus if you accidentally blow the board, you're not down £500
Adding a DRM so that people can't make knock off cameras, in exchange for a £10 full linux SBC that is _easy_ is a worthy exchange. Even if they weren't a charity. The fact that they are single-handedly dragging the pathetic excuse for IT education in the UK ("here is how to use Microsoft office") into something approaching usefulness is a massive massive bonus.
The ecosystem that raspberry pi supports, the OS, magazines, training, teaching, class room outreach and research can only be done with cold hard cash. That cash comes from Pi sales.
Don't get me started on DRM. Look I know you think that everything should be free, but that means I can't earn a living.
Teaching kids that copy/pasting someone's work, making a halfarsed cheap copy and selling it for loads of profit, with no support is a good moral choice, you might want to re-asses your world view.
Yes open source is good. Yes you should give back and contribute. But, to move forward, money has to be invested, and it has to come from something.
Yes, removing ownership from the people is exceptionally bad. The trend towards the "sharing" economy undermines workers rights to the point that we are entering digital feudalism. But that is another topic.
I don't own a smartphone/any Apple/Google products, or Dell/HP machines for that matter (not surprising to me that they're bad). My frame of reference is typical PCs, which aren't in the habit of applying vendor lockin with regards to what peripherals you can use - and other SBCs.
I don't understand the premise that not applying vendor lockin to a camera module would make SBCs unreasonably expensive. Competing SBCs are more open, many predate the rpi and despite the fact that they probably sell fewer units than the rpi (due to less brand exposure, not cloning), and thus possess lower economies of scale, I've never seen one which costs "£500".
>Don't get me started on DRM. Look I know you think that everything should be free, but that means I can't earn a living.
I think this is clearly untrue from the success of other, more open SBCs.
>Teaching kids that copy/pasting someone's work, making a halfarsed cheap copy and selling it for loads of profit, with no support is a good moral choice, you might want to re-asses your world view.
But I never claimed that kids should be taught that. What I do claim is that kids should not be taught that it's ethical or normal/acceptable to try and use malicious functionality to institute vendor lockin, creating an artificial monopoly in compatible peripherals, because it isn't.
Moreover, it appears this DRM has had a chilling effect on third-party cameras with novel functionality (i.e., not competing for the same applications as the official camera), according to a comment posted above: https://news.ycombinator.com/item?id=20261787
So there's real evidence of harm done by this.
>Yes, removing ownership from the people is exceptionally bad. The trend towards the "sharing" economy undermines workers rights to the point that we are entering digital feudalism. But that is another topic.
It isn't another topic. There is a systemic trend of hardware vendors using firmware to advance and prioritise their own interests over those of the device owner, essentially using technological measures to undermine the first sale doctrine. Of course, this isn't illegal, though it ought to be.
> But I never claimed that kids should be taught that. What I do
> claim is that kids should not be taught that it's ethical or
> normal/acceptable to try and use malicious functionality to
> institute vendor lockin, creating an artificial monopoly in
> compatible peripherals, because it isn't.
I'm sorry, I didn't buy a Raspberry Pi for my little brother in order to teach him about vendor lock-in. I bought him a Pi so that he'd learn Python and explore the boundary between the electronic, software world and the real physical one that so often seems shrouded in mystery. I did not buy the Pi because I like supporting non-open companies- I bought it because A) it has a great value proposition, especially once you factor in the community support, and B) I like the Raspberry Pi people. They have hearts. They care. I understand them DRM'ing a $10 part when it's not crucial to standard operation (nor a lot of projects) and it's not like you can't just get an old PC and stick a webcam on it.
The way I see it, a Raspberry Pi is more than the sum of its parts- while commercial companies care about the chips and the complexity a solution like a Pi can remove, I personally bought a Pi for my brother to learn on.
2006, gumstix with bluetooth was $180, but that was a very small system to dev for. embedded 386 in volumes of 1 were ~£380, CF flash(certified) £80-200. Software was extra, as was the debugging interface, which may or may not be a fancy serial port. Ethernet, RF, all extra. Wifi? naaa.
The arm board, I don't know how much they cost because they were custom made. So hundreds of thousands I suspect.
Then we have the tools that supported it, not exactly kid friendly.
This doesn't add up either, since they seem to be effectively walling themselves into not opening up some of the software needed to boot rpis, which remains proprietary. See https://news.ycombinator.com/item?id=20261549
The assumption that they would prefer to handicap their main product because of some unknown deal they have on an accessory seems biased to me. The SoCs that they use are Broadcomm ones, a company known for being hostile to open source. Perhaps the fact that they have now sold over 25 million units of what is essentially their old designs that wheren't selling anymore is opening their eyes on the money that can be made. The developer of the new open source gpu driver is a Broadcomm employee.
The point is that for some unknown to us reason they deemed it a good idea to add DRM on a side-project they have. But that doesn't mean they can't make a new camera at some point.
I agree that if rpi decides not to do camera DRM anymore, this motivation not to get rid of the boot blobs in the main product disappears.
Currently they are defending this practice, however. It logically follows that as long as they institute this policy of using DRM on the main product to prevent use of third party camera modules, the boot blobs will remain...
I think people misunderstand what this DRM is about. The Pi has a special connector for a camera. Anyone can use this connector to build their own camera module and they can use the kernel driver that the RPi foundation paid for. But you also need to develop an App for it. The RPi foundation made their own camera accessory and an accompanying app for it. What the DRM does is that it only allows their own accessory to work with the app. So it's more like brand protection than it's market control. There are plenty of other cameras on the market that you can buy. Why they chose the camera to DRM out of all the peripherals I don't know, but the only reasonable place that they can stick it into is the blob that Broadcomm provided.
Btw the situation with the binary blob has been going for years and from what I've gathered in the past what's happening is that the foundation members signed an agreement to not reverse engineer anything on the SoC when they made the first Pi. Since then they offered a price for an open source gpu driver but didn't follow it up with more competions. So either Broadcomm shut them down or it paid off in internal pressure since Broadcomm paid and provided the mainline driver used in this version.
It feels like every time I get round to doing a project with a Pi they create a new one with literally no indication or advertising. Suddenly out of the blue a new one appears.
But it is sort of refreshing not to have the early announcements and then wait for ages for the actual release. And to then either have further delays or find a half finished product that was rushed out to meet some promised deadline. Plus I like waking up to surprise rpi announcements!
Sure I can just buy an adapter, but then I have to keep track of the adapter and always deal with an adapter hacking of the board making it more awkward to handle.
HDMI to micro-HDMI is just a straight passive adapter - only the physical shape of the port is different, and feature support isn’t really a thing. In this case it’s obviously done because the HDMI connector is annoyingly bulky if you want two of them, though I’m surprised a stacked connector wasn’t a better option.
Stacking is risky, because the end of cables might be unreasonably large, thus two might not fit on top of each other that close. Also HDMI cables tend to be pretty bulky, they might simply strain the board too much?
You make it sound like they are being unreasonable, but just like USB-Micro to USB-C and X to headphone jack, it's a huge inconvenience when you can't find/don't have it to hand.
I used to lose the Micro to C adapters all the time, I lost the C to headphone for my OnePlus6T while travelling and was unable to find a replacement so no headphone use for me.
Also, I have about 12 Raspberry Pis, as many display devices, a dozen or so other HDMI devices such as consoles etc, and tens of normal sized HDMI cables lying around and they're all compatible.
You're not wrong, but it feels like an unnecessary problem to have, stacking a couple of full size HDMI ports would have been nice, or just putting a single port on since having two on a Pi is kinda unnecessary.
Exactly, you can solve the dual-display problem via daisy-chaining a couple of DisplayPort monitors instead. Using Micro HDMI was a bad decision in my opinion.
If I remember correctly (and that's a big if), DisplayPort started royalty-free but then they introduced royalties. From my blurry memory: I checked once many years ago and it was free, but then I checked again a couple of years later and it wasn't exactly free any more. Did it change again? Or am I completely wrong from the start? If someone remembers the history better than I do...
More common in monitors perhaps, but I don't think I've ever seen a TV with a DP input. Since AFAIK the target market of the RPi is "plug it into a TV, plug a cheap USB keyboard and USB mouse, and you have a working computer", having HDMI output is a requirement.
Network booting is supported. I don't know if the architecture is similar enough to the x86 bios loading network card option roms that one could say the "ethernet controller supports" it. Booting on ARM is different.
They're possibly thinking about something like the Amlogic S922X. A 12nm SoC with Quad A73 and Dual A53, its definitely more modern and more efficient, though "better" is pretty subjective. As implemented in the Odroid N2 [0], its not cheaper at $79 with 4GB RAM, compared to Raspi 4's $55 (or $63 and $45 for 2GB, respectively). Hard to say if they cut the board down to remove all the things Raspi doesnt support and scaled up to Raspi scale if they could match the price. If not, it'd likely be close.
Missing: SD card performance benchmark. Previous models could only read about 20 MB/s or so, while the modern SD cards can do 10x (maybe even more) that.
Is there any improvement in this? It's pretty important as RPi usually boots off it.
Correction: it seems like RPi4 doesn't boot from USB or Ethernet yet; they will release a firmware update to turn it on.
"Support for these additional bootmodes will be added in the future via optional bootloader updates. The current schedule is to release PXE boot first, then USB boot."
Finally! First RPi SD card performance upgrade ever.
Doubled, so I guess around 40 MB/s. Still a far cry from fastest SD cards that can both read and write over 250 MB/s. Hopefully RPi4+ will improve on this. :-)
People have spent however many years since the release of the last pi suggesting improvements. It's announced today offering basically everything that people were asking for, and you are already planning for the next one?
Huh? I'm not allowed to hope for future improvements?
I'm very happy for RPi4 SD improvements. Until now, RPi has had same lacking ~20 MB/s SD performance from the start. AFAIK, this is the first time ever there's been any hardware improvement in this regard.
I've had a microsdxc card with 90 MB/s reads and 80 MB/s writes since early 2014. Some current cards can read & write more than 250 MB/s, so
there's still room for improvement.
As 95-99% of all RPis boot from (micro) SD and use it as primary storage, I'd say SD performance is a rather fundamental (often ignored) aspect of RPi performance.
"The Pi4B has a dedicated SD card socket which suports 1.8V, DDR50 mode (at a peak bandwidth of 50 Megabytes / sec). In addition, a legacy SDIO interface is available on the GPIO pins."
I'm very excited about these upgrades too (especially GigE), but as far as I can tell nothing on this news page specifies whether the Pi will also support HDR output as part of the 4K upgrade. That's most of the practical benefit of 4K - that 4K releases tend to come with HDR10 or DolbyVision support.
Anyone know if we can expect HDR output to work? If I knew it supported that I'd be purchasing one right now to upgrade my media center from my current Pi 3 setup.
Even the tech specs page says nothing about 10bit decoding, which is required for most real world 4K HEVC video.
That's really too bad. It makes the 4K support useless for building an HTPC, which is a common use for the Pi. As far as I can determine, several of their competitors already support 10bit decoding, although specifics (about stable HDR support) are sometimes hard to come by.
As a fifty seven year old, I don't have 4k eyeballs. agree you have a limitation, not one which is holding me back since osmc does 720p just fine, for Olde telecine mp4s of B&W movies
I have a 4K-capable 40 inch TV in a standard living room (for Europe). 4K videos look slightly crispier than full HD ones.
While I could have a slightly larger TV, I think that for typical domestic use 4K's improvement is marginal because people are not sitting 50cm from the screen and room sizes are limited.
Really, so far the top benefit has been that I could tell my wife: "Look, if I move right up to the screen I can still see Jeremy Clarkson's individual hair strands!"
I'm still struggling a bit with large screens. For something like playing games I'm guessing you can comfortably sit back. High resolution screens for computers feel attractive, but getting up close and personal can feel a bit much with light levels. I'm guessing OLED might be nicer in that regard.
For those of us who aren't there, can you clarify how big a standard European living room is? This has nothing to do with the resolution stuff you mentioned, just curious.
In the UK in a victorian terrace, and our front room is perhaps on the small side at about 3x4m. I'd guess somewhere between that and 4x5m is about average. For us 32inch still can feel imposing. And that size screen seems to be being phased out.
We do have another room, that's slightly larger but it's a bit bleak. And weirdly it's a more fussy room to furnish. The smaller size is better in the winter. The old brick terraces aren't that warm. In large houses people can gravitate to smaller rooms for that reason. Personally I'd like a large room that I could bring the furniture in from the sides. Lucky to even have a house to live in to be honest, so can't really grumble.
I have to comment. That's huge! Way bigger than most UK Victorian 2 up, 2 down terraces. More like the size expected in an older 4 bedroom house if you ignore the extra space the photographer is clearly standing in.
That's slightly smaller than ours probably all in all. But I've seen smaller, like the one up, one down back to backs in Leeds/Woodhouse and many modern flats apartments, are just broom cupboards - but then you look at down town Japan and this feels palacial.
That's larger than mine. Sizes are getting smaller. Can't comment for the rest of Europe but the UK has quite a bad homeless problem, it's very visible at the moment. Rents are prohibitively high, and getting onto the housing ladder is very difficult. Small houses - even semi-detached bungalows around our way are at least £300k (edit: oops missed a 0 originally!). The housing stock is shockingly bad in the UK, and very expensive.
> I wasn't aware of a major homeless problem in Europe.
Homes in the UK can be expensive, so there's a large rental market.
On top of that many people are vulnerably housed - living in emergency temporary accommodation (which may be for many months) or on friend's sofas.
The introduction of the benefit "Universal Credit" has increased homelessness and people who are vulnerably housed. In the UK a landlord can apply for eviction if the tenant hasn't paid for two months. (This is for shorthold tenancy agreements where tenants have most rights - other tenancies have less protection.) There is a minimum wait of 5 weeks before Universal Credit claimants get paid, which pushes some people very close to this limit. The bizarre sanctions regime tips many people over that limit.
But joking aside, I'm surrounded by glass on all sides in a car. That makes a great deal of difference. I probably wouldn't feel confined in a room that size if I had an entire wall of glass.
In a UK terrace, even given a large bay window, your view will likely be squandered by a large work van, as the terraces seldom have off-street parking.
I've got a 4K TV and it's placed in a location that I can tell whether or not something is 4K if I sit a bit closer, but the core problem is that it's still very difficult to provide it true 4K content, since I've not been willing to drop the money for 4K blurays.
I've got a variety of content that is, technically, a video stream that decodes into a framebuffer that is a "4K" framebuffer according to the metadata on the video, but without enough bits for it to truly be "4K"; the same number of bits dedicated to a 1080P video would look just as good.
For all the bragging about how streaming is the future, it seems to me that the companies providing those streams at scale still have a lot of incentive to cut the bitrate back so far that it's not practically a 4K stream anymore, because 95%+ of their audience can't really tell.
I'm in my 50s as well and may eyes are definitely showing their age, but if anything I find high fidelity screens more important to me now than they were years ago. I use 1080p 23" screens at work and the slight blurriness from pixelation is definitely noticeable. Comparatively, the 5k screen on my iMac is dramatically sharper and easier on my eyes.
I find that when my own vision is slightly blurred, add in even more slight blurring on the screen and they compound each other. On the other hand if the source image is pin sharp, it makes it easier to cope with the flaws in my own vision.
I'm sure higher resolution is nice, but nowadays I'm more interested in HDR and larger colour gamuts (Rec.2020).
I don't doubt 4K and 8K look "better", but IMHO we're approaching the point of diminishing returns, and visual enhancements in other areas are worth exploring (even for 1080p).
I know we're talking video here but I wanted to share something. My father just got a new set of 'ears', he's been going deaf. They are titanium studs that are implanted into the bone just behind the ear, about the size of pencil erasers. They work through bone conduction. The hearing part are replaceable electronics that snap on and off the studs.
The current gen are about the size of a quarter and are bluetooth capable, so he can sync to his devices, watch movies, etc with these little guys tucked behind some hair.
It got me thinking, I wonder if audio guys have started to look at some of this sort of thing to really "hear" music perfectly. Very interesting tech.
There are some earphones that use bone conductance, but this sounds like a special case.
If hearing is down to tiny hairs in your ear resonating with the audio frequency, I would have thought being hard of hearing was down to those hairs not being able to function properly. How does bone conductance audio get around that? Does it use a different sense?
My eyesight is also going, I have to rub my eyeball on the phone screen like one of those anti-deorderant balls, I daresay my hearing will be next.
homo cyberia
(That's probably nonsensical latin, if anyone with a modicum of latin knowledge wants to go all Life of Brian on it, please feel free. What is latin for augmented human?)
I'm not sure I'd use a pi has an HTPC for true blue-ray type 4K. Not to ding it, and I'm very excited (and happy to be proven wrong), but I'm not sure it will have the performance for that. I expect quite a bit will depend on whether or not someone puts in the software optimization work, as I remember how powerful PCs couldn't decode what they can on today's codecs a few years back. But we'll see.
I guess maybe if you added a heatsink and/or fan? I'd be a bit concerned about component life, taxing it that hard.
Oh yeah, and I wanna see how this thing overclocks.
The spec table says VideoCore VI. I really hope that is not a typo. I suspect it really is a VC6 because 2x4k is a big bump in pixel count and without a corresponding bump in fill-rate, perceived performance will drop.
[edit] looking at the benchmarks it's a modest boost. Now about twice the FPS of a PI-2 for Quake3 at equal resolution. Be interesting to see if something with more complex shaders changes the relative performance.
The VideoCore 4 (fuck the roman numerals, for exactly this reason) can not output 4k and it is also not a ES 3.0 capable GPU. So this must be a 5 or 6.
I'm crossing my fingers here. This is really something they should have put in the specs if it's supported. With 10bit decoding and Rec. 2100 [1] support, this would make a fantastic platform to build a media center on. I'd certainly upgrade from the Pi 3 even though I don't currently have a 4K television.
Do we know for sure that all VC5/6 SoCs support HDR decoding, or is that still unknown? The Wikipedia page for VideoCore only lists one VC5 SoC and no VC6 SoCs. The Broadcom page for the VC5 SoC is pretty uninformative.
> The H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
Sounds promising! (The documentation on the website should certainly be fixed if this is correct.) Now assuming Rec. 2100 is properly supported to allow connecting to HDR capable displays over HDMI 2.0, we should be good!
> Sounds promising! (The documentation on the website should certainly be fixed if this is correct.) Now assuming Rec. 2100 is properly supported to allow connecting to HDR capable displays over HDMI 2.0, we should be good!
As hopeful as I am, that's quite a big assumption...
Sure, but the video decode IP is a different piece of hardware from the video scaler/compositor. In a typical SoC, you have the GPU and the video decode engines as separate blocks that feed into the video scaler/compositor which then blends, rotates, scales, .. etc the inputs and feeds the final signal to LVDS, HDMI or whatever.
Now does it make sense to have your video decoder support 10 bit when your compositor can't handle that format? I guess you could argue that 10 bit source material will still improve the quality even if you downsample it to 8 bit for display, and I think for example DVB-T2 has standardized on 10 bit so if you can't decode that, that's a large chunk of market gone.
Ultimately, from the little we know, the compositor hardware is the same as the old Rpi, and that couldn't do 4k60 and it can't do 10 bit depths. The Raspbian image currently doesn't use the Linux kernel implementation for driving the compositor (it uses the fkms or "firmware kernel mode setting") so there might well have been hardware tweaks.
(Ok, instead of making this comment thread any longer, I simply asked and the compositor hardware in the RPi indeed has HDR support:
What are the odds that this will support 1080p streaming with Plex? I've tried Plex on a Pi 3 using a Roku as a player with 1080p and it's a complete failure. Plex tries to encode everything even if native playback to the Roku is possible using the Roku media player.
My plex isn't on a Pi but I do not have this issue with Roku Express as a player. Could be other factors like the video codec and direct stream is set on Roku.
If encoding is required? Almost certainly won't work, it's just not powerful enough. But you should avoid reencoding if at all possible, and I imagine it will work if you can manage to disable it.
don't want to derail the RPi4 celebration, but for this specific purpose (media centre) I've been super happy with Nvidia Shield. You can often pick them up for $150 on a sale, less on ebay. 4k HDR, runs Android TV (some people have managed to get Ubuntu running on it too), VLC/Kodi work well, Moonlight works well for game streaming from another gaming PC with NVidia card. It's super zippy, too, and quite small (though bigger than RPi).
Yeah, the Shield seems to be the standard here. If we can get confirmation that the Pi works, we'll have an alternative that is much cheaper and is more useful as a general purpose platform!
I haven't been able to get HDR working on my desktop amdgpu + X11. I don't think it's supported in Wayland yet either (let me know if I'm wrong) and the devs in #mpv on freenode said they don't have HDR10 output support either (although mpv can do HDR10 tone-mapping).
For HDR videos, I still play them via my Windows box. I think the current MacOS supports HDR too (and if not, it will get support soon as they have that crazy new $6k HDR screen).
"The 4B hardware is HDR capable, but software support has a dependency on the new Linux kernel frameworks merged by Intel developers (with help from Team LibreELEC/Kodi) in Linux 5.2 and a kernel bump will be needed to use them. Once the initial excitement and activity from the 4B launch calms down, serious work on HDR and transitioning Raspberry Pi over to the new GBM/V4L2 video pipeline can start."
Desktop performance my behind. What's the point of all that CPU power when IO performance remains in mid 2000s territory? It takes forever to boot, any time disk access occurs everything crawls to a halt. M.2 has been around for 5+ years now and would have easily fit on this design in its short length form factor.
It really depends on your use. If you plan to build a desktop replacement, thread performance matters. If you want a small cluster node for educational purposes, more slow cores are better.
That's great, but if you need crypto (because you have LUKS storage and send AES encrypted data over the network, like in a usual NAS case), A53 with aes instructions may be faster than this A72 without one. And so far it seems these cores don't have aes instructions.
Edit 2: Ah, also RPi3B and 3B+ didn't have those extensions. Oh well.
Edit 3: Just tested my bog standard RPi3B+ running Raspbian. It could do "openssl speed -elapsed aes-256-cbc" 43 MB/s AES-256-CBC. Tried also with "-multi 4" and it resulted 144 MB/s using all 4 cores. So perhaps RPi4 will be fast enough with CPU only crypto... would still love to have HW assist.
Edit 4: RPi4 running 32-bit OS can do about 65 MB/s per core aes-256-cbc. 85 MB/s per core for aes-128-cbc. So by using two CPU cores for encryption (+ heatsink + fan :-)) 1 Gbps ethernet can be saturated.
I believe it might be possible to use VideoCore VI for crypto acceleration.
I think it would be pretty tricky to get LUKS to use it, though. At least writing a kernel module, but most likely LUKS patch would be required. You'd probably have to choose between 3D acceleration and full disk encryption.
Looks like VideoCore VI is getting some compute shader support:
Quick Googling [0] revealed VideoCore VI might have at least some support for Vulkan and/or OpenCL. If this turns out to be true, then yes, VideoCore VI might be able to function as a crypto-coprocessor.
Depends on your use case. If you have SSD attached over USB3, you can easilly pull 400MB/s. This would severely limit that, if that is an encrypted drive. On Allwinner H6, for example, you could get that speed on oncrypted drive while still having other cores free for other stuff.
So if you need to go through/process gigabytes of data on encrypted drive, having to do encryption in SW will slow you down massively, especially if you also need to process the retrieved data somehow.
Yet, you can have the same priced board that can do 200-800MB/s AES-128 encryption (per core), leaving much more time to the actual useful work, or idle (less power consumption).
Yes, these are A53 cores which the RPi 3 used. The RPi 4 uses A72 cores, which are a lot faster. A53 are efficiency optimised cores and A72 are performance optimised cores.
The RPi has such a big community that I imagine performance and optimisation will quickly surpass other chips, eg. Rockchip RK3399 [1] (2xA72 and 4xA53) and will probably end up on par with an Amlogic S922x [2](4xA73 and 2xA53).
I have a great interest in SBCs mainline compatibility, but I think they will always be "compatible but not fully", unless a given board will be specifically designed with this objective (at which point, there will be surely a trade off performance<>compatibility).
The RPi3 has in fact mainline support, but is not "fully compatible" (at least, in the x86 sense). I guess this will be the case for the RPi 4 also.
This is a shame, since any ARM board has essentially an expiry date. For this reason, my next board will be an x86 SBC (the "famous one"), however, it costs considerably more.
- Half the RAM but double the cores. I'm waiting for some benchmarks to see if the RPi4 is faster and by how much.
- Also Gigabit Ethernet and it works great. My downloads are always at 108-111MB/s for the whole transfer.
- Not USB 3.0 but has "oldschool" SATA through an internal USB-2-SATA adapter. It's at least more compact, otherwise the RPi4 with an external USB 3.0 drive will probably work even better.
- works with a normal 12V power supply, which could be lying around already, from older external drives.
Not to disrespect the RPi4, as I'll be getting one of them too very soon.
The OrangePi 3 at $40 is also pretty neat, PCIe 1x, 8GB onboard eMMC, 4x USB 3.0, Bluetooth 5, Wireless AC (pretty sure they beat Raspberry Pi to the punch on this...) and it has mainline kernel support: http://www.orangepi.org/Orange%20Pi%203/
I think this is to avoid the plentiful 12v adapters that use those sizes, as you could fry the board with a bad PSU. The 5v adapters that do use those more standard sizes are generally 500mA or 1A, which is enough to (unreliably) boot and run the board.
Are you sure? I've worked with a myriad of ARM devices, and I would say that despite their small size, Hardkernel are one of the most responsive companies when I have had issues.
Hardware vendors hardly are the best sources for OS images, except maybe for very new boards. When I shop for a board I always look if it is supported by community driven projects such as Armbian, DietPI or even plain Debian.
Im excited to look at the wifi on the RP4! Any word on the chipset used for that?
On a more personal note - thank you for your service.
You got any advice for pulling the aircrack_ng/rtl8812au driver from github and making it into a patch for building in-kernel? I really like having signed-module verification, but I also really want this driver.
The credits at the end of the post thank folks who worked on the CYW43455 integration, which matchs up with the raspberry expectation of being a (former) Broadcom part.
I've performed a `git cherry -v` out of curiosity a month ago, and there were a few dozen commits (even reverts!).
While I think pretty much any programmer could reapply them, my guess is that in the long term, one needs to know how device drivers development works, in order to adapt to the kernel changes.
But I'm not a kernel dev, so the maintenance could be easier.
The USB port on the Odroid HC2 is 2.0, but the SATA interface is connected to a USB3 but, as is the Gigabit Ethernet.
Furthermore, SATA and Ethernet are connected to individual USB3 busses, as opposed to earlier RPi designs where everything shared the same USB2 bus.
I haven't checked the RPi 4 specs yet, but i can imagine it's still the same layout, just a faster bus, which can be "just fine" - it should be plenty fast to saturate a Gigabit ethernet as well as the SSD/HDD IO required to do that.
I had an Exynos 5422, and when it came out it was a great card, however, nowadays, it's old generation - it consumes more and it's less performing than the latest archictures (A7x).
"Double the cores" is not a valid consideration - 4+ core configurations typically have 2/4 cores (the 5422 has 4) with a high-powered architecture, and the remainder with a low powered one.
Compare for example the XU4 with the N2 - the N2 is more powerful, and yet, it has less cores (4 hp. + 2 lp.) and requires no fan.
The RPi is an interesting configuration - they have 4 high-powered architecture cores (4x A72) only. It seems it doesn't require any fan.
Of course if one requires specific chipset/components, we're talking about specific use cases, which is another story.
It does at least need a heatsink. Though it will function without it, you may get temperature warnings, and it will run hot enough to significantly reduce component life. I've also hooked an old PC case fan to the GPIO pins or a USB port, and it runs slower (5V vs the 12 it expects) but does the job fine.
The distinction in actual usage between using cloud, server, and homelab to describe their setup seems to be rooted in their purpose.
* Home Lab :: Running a partial/full enterprise IT stack for fun and education.
* Home Server :: Running primarily internal services like file storage, backups, media streaming, home automation, maybe some light networking.
* Home Cloud :: Running primarily external services on the public internet to replace 3rd party SaaS services. More often than not this is done with a VPS provider rather than physical hardware in your home.
So maybe you find the terminology annoying since everything is cloud these days but it's genuinely useful to us folks in the forums. You can also call "home cloud" selfhosting if you find it less jarring.
I see value in what you call home cloud. It has a lot of potential for distributing things and giving control of data back to people. Is there a place where I can follow developments like this?
Also, it seems like Western Digital would be an ideal player in the space since they want to bring processing to data storage via RISC-V.
Synology is probably the biggest player in this actually. They sell NAS hardware you can just add software to, with a selection of "home cloud" software of their own.
On the hardware front I'll plug the project a friend of mine is working on[0]. As far as self-hosted software goes, the file sharing/sync section[1] of awesome self-hosted is great (the whole list is great).
I am not sure that is a great distinction. A server is traditionally serving some resource, usually to multiple people. The idea behind 'home cloud' is to host 'slice' of a server yourself. Something that used to be hard because of the cost of hardware, making hosting only a few 'sessions' expensive.
Of course hardware hasn't been expensive for probably a decade or more. Today it is almost entirely a software problem. Or more precisely how to create independent quality software when many developers are employed by large corporations and no one wants to pay for development. I am not sure much is happening on that front.
if you run a "home cloud" on a raspberry pi 2/3/4 or an orange pic or something else entirely and it fails, will your "cloud" go down with the hardware?
If does go down then it's not cloud, no matter what hardware you're using.
In general, my rule of thumb is: what's the upper limit, the capacity or your wallet?
Unless your server offers some form of slicing of resources (containerization / virtualization) then it's difficult to describe it as a cloud in anything other than a buzzword.
I think most ISPs don't allow servers on residential, so one would be better off using a home cloud. Preferably one with blockchain to disrupt blocking or throttling.
Most ISP’s don’t actually care if you host a small server for a low number of users. As they shouldn’t.
Seperately, you’re not going to fool anyone by calling a server something else. (Not that “home cloud” is a bad term, but I think everyone realizes that still constitutes a server.)
Hi, author of the piece here! You're right that WordPress wouldn't have given you a popup before you could read, for free, the article I spent a couple of months working on. It also wouldn't have provided me with any income to support creating the article in the first place.
Medium, on the other hand, does. I mean, it's not much - I get a slice of the revenue from paying subscribers', based on how much they 'applaud' my piece - but it's higher than zero. Despite this, Medium also makes it available to read free of charge for non-members - up to, I believe, a somewhat miserly three articles a month, though you can bypass this if you really must by using a private browsing window to get another three, and another three, and another three, and another three...
I've got kids to feed and bills to pay. If you really don't want to click an X on the login prompt and read it all for free, I can give you my payment details and sell you a PDF copy...
- would you mind sharing how much you actually you expect in revenue from this article?
- Have you considered any other ways of monetizing it? Just an idea: if you had your own blog and registered on Brave as a content creator, you could be getting a few cents from me already.
Massively depends on performance. You get money from a subset of a subset of a subset: there's the set of the audience; there's the subset of the audience that are logged in to Medium at the time; there's the subset of the logged-in subset of the audience that bother to click the 'Applaud' button; there's the subset of the bother-to-click-Applaud subset of the logged-in subset of the audience who actually have a paying membership.
Then how much you actually get is totally up in the air. If mine's the only piece Reader A applauds that month, I get 100% of the revenue (minus Medium's cut, of course - the house always wins); if Reader B has applauded 1,000 pieces this month, I get 0.1 percent of the revenue (as do the other 999 authors.)
It's a model which is inherently insular: of the traffic that has visited the piece so far, 90% is external (and thus earns me nothing other than name-recognition) and 10% is internal to Medium. Only a tiny, tiny fraction of that 10% has applauded, and I won't know what that translates to in terms of Cash Monies until Medium calculates it and tells me. I'd be much better off promoting it to existing Medium members - such as by joining a 'publication' on Medium - and ignoring external traffic sources, but I don't want to do that.
As a ballpark, though, the answer - long in coming - is "not much, but considerably more than I'd get on Brave." The Raspberry Pi 3 B+ benchmarking piece I wrote on Medium has earned about $277 lifetime; if this earns the same, I'll have done very well indeed.
Thankfully, I'm not relying on the Medium income: I've pieces in various websites and magazines based on the same core data, which pay one heck of a lot better!
Thanks for your answer. In all honesty and taking what you said in consideration, I still believe that the Medium model should die in a fire, I won't feel bad for not supporting you through it and I hope you consider other alternatives.
I'm not sure you read what I wrote, but I have considered other alternatives: it's called "writing for magazines." If you'd like to support me without supporting Medium, you'll likely find me inside more than one bound collection of thinly-sliced dead tree at your nearest newsagent, supermarket, or bookseller.
I've even considered Brave. Hell, I've even tried Brave. According to my email archive, I signed up as a publisher in January 2018. Sadly, it's just not a sustainable model yet - which is why my piece is monetised by Medium, not Brave.
I wouldn't be keen on supporting dead tree magazines and its excessive ad-to-information ratio, newspapers that only are tangentially focused on providing good content and more focused on creating constant crisis as well or any kind of publishing industry with so many middleman that need to be eliminated.
Sorry, it is really not my intention to pile on you. I am just really tired of the current state of affairs in regards to the publishing/authoring economy. I know it is easier said than done, but we need to have more content creators that are willing to take a principled stand and stay away from these actors and start creating exclusively on terms that are more ethical.
If you're using Brave, I'm assuming you're using the browser's main claim to fame: the ad-blocking/ad-switching functionality, yes?
So, you won't support content creators who publish on a website which uses advertising.
You won't support content creators who publish on a website which allows non-members and free-tier members access to a limited number of articles a month and charges a fee, distributed to the content creators, for unlimited access.
You won't support content creators who publish in print, in magazines or newspapers.
I'm sensing a theme, here: you won't support content creators.
I would love to host my own website (actually, I host several) and write the same kind of content I do now, but how exactly am I going to feed the bills and pay my children? This is literally my job - I'm not just dashing out a quick blog post as I Segway to the London office of my cryptocurrency startup for a day of find-and-replace in the whitepaper. If I'm not getting paid for my words I'm not getting paid at all.
Brave is not the answer, I'm sorry to say. Something like Brave may be - I used to play around with Flattr, which was the same kind of micropayments model as Medium but applicable to any third-party web content, and doesn't have the ethical issue of blocking everybody's adverts but its own - but Brave ain't it, at least as it stands.
You don't want to support content creators, you want to support Brave. That's fine, but don't frame it as wanting to support content creators but only in one very specific and questionably-ethical way.
Otherwise, put your money where your mouth is: pop me a payment across, in the currency or cryptocurrency of your choosing, and I'll publish the same piece on my main website. No adverts, unless you count the cover shots of the books I've published (hey, there's another way you could support me - and if you're worried about ethics, some of them are available for free download under a Creative Commons licence!) down the side.
I used to have about ~$15/month deposited on flattr* for quite some time, and the main reason that I've been using brave is not because of its anti-ad stance but rather their anti-tracking + the possibility of a way to fund content creators.
I am also contributing about ~10€/month on patreon for different software projects and writers. I've written to more than one youtube channel producers asking them to look into alternatives so that they could take my money. The Quilette model is also something that I do appreciate.
Believe me when I say that I am more than willing to support people that create content. And depending how much you are asking for me to send you, I'd gladly take on your offer.
* story time: I got a call from an Eyeo recruiter some months ago, who was looking for people in their ad-block/acceptable ads team. It turned into a most-of-the-time-friendly discussion about how acceptable ads does nothing about the tracking of the users, so I wouldn't be interested in joining their team and me asking him to call me back only if he had some position on flattr.
The problem with Patreon - and thus Quilette, which is 95 percent funded by Patreon - is that there's a massive gulf you can't cross. Popular Content Creator who has a hojillion Patreon backers and gets $10,000 a month from 'em has no worries; person who plays about with it in their spare time and gets $5 a month can buy a beer. Job's a good 'un.
But what about the person who wants to write full time, but hasn't built the audience yet? How do they go from $5 a month to paying the bills? In my case, I didn't have to: by the time I switched careers I had enough regular clients to cover all my outgoings, albeit only just. Quit the day job, picked up some more clients, and here I am doing it full-time to this day.
If I were relying wholly on Patreon - or Brave, or Flattr, or even Medium - I couldn't have done that. Patreon isn't going to give me $300 on spec to write an article that might not do well; Medium won't front me a few grand against royalties so I can take time to write a book.
D'you know who will? The traditional publishers.
I appreciate you have a personal stance on this, but so do I - and mine comes not from the perspective of "I'd like to read this but it's on a website I don't like" but from the perspective of "if I don't get paid for this I'm literally homeless."
Actually, I have a Patreon account - https://www.patreon.com/ghalfacree - I signed up just before the new fee scheme came in to lock in the old rates, but never launched it (hence the zero backers.) Don't really have time to give it the love it would need to gain traction, either - again, we're back to the problem of not having the cash to go from zero Patrons to I-can-feed-my-children Patrons.
I am sorry but this is the point where we disagree. "I still need to make a living" is not that I would accept as an argument to justify all of the unethical issues that arise from the attention economy industry.
Yes, this means that I will actively find ways to accelerate the demise of these business. No matter how much I want to support content creators, it does not make me responsible in guaranteeing their job.
I wouldn’t know. It’s not like I’ve consumed my “fair free share” of your content, I’ve apparently consumed my fair free share of content across all of medium.
Would you accept to be requested documents when you enter the mall? Would you find normal to be stopped by a security guard that says “sir/madame, you’ve browsed enough stores for free without handing in your id card and personal data, please fill this form or leave” ?
I owe you nothing. If anything, you owe me. It’s my time that builds your audience, not the other way around.
I had ODROID C2, I don't know how things are now but I've returned mine as it hanged a lot and had lots of different issues. At same time I had 2x Raspberry Pi and it worked fine. This was couple of years ago.
I'd love to run something like this, but I recently switched to ZFS which recommends having a lot of RAM (my NAS has 4GB). It's what kept me from going the route of the Helios 4.
I have been using Odroid XU4 for home server (home assistant), personal CCTV, controls IR blaster and other sensors for years, still running perfect without rebooting for months. I also have Pi 3 for Pi Hole, but honestly my Odroid XU4 is more stable than Pi 3.
To me, the RPi is the choice only because every other single board I've used had so much less support than RPi does... I have a 3B+ running retropie and it's doing okay, but if this one can also do a decent job with h265 under kodi, I'll be very happy indeed.
Ordered a starter canakit with a couple extras, and looks like I won't see it until August. :-( ... I'll probably forget I ordered it by the time it comes.
I'm cannot determine if the HEVC hardware decoding is full 10bit or only 8bit. A lot of SDR content is encoded in 10 bit for the space savings (or so I've read).
According to the response I've gotten so far, it will not support HDR or 10 bit. :-( However, the vast majority of SDR content is 8 bit. The few exceptions are mostly a few pirate groups who mostly encode anime.
Thanks! That's what I seem to be seeing elsewhere now too, although the main site is now down (for me), so I haven't been able to confirm as much as I'd like.
I wish there were some improvements in the I/O aspect of the board. Having tried to use an RPi for a small automation project, I felt limited by the single ADC input and single PWM output. I was faced with using an Arduino daughter board to do the actual IO or going with a BeagleBoard.
Only if both drives are saturated at the same time. But since the context here is a NAS usage, there's a max 1gbps upstream/downstream in the first place so you could comfortably do a 4 drive mirror NAS off of this and not have any bottlenecks on the USB 3.0 -> SATA side of things.
Does it use ECC memory? If not, you should not use ZFS. Without ECC memory, ZFS carries the nasty risk of writing good data with a bad checksum, leading to data loss which would not occur in other filesystems (those that do not try to correct errors on the fly like ZFS).
In the case of a traditional filesystem, similarly unfortunate memory corruption would just affect the actual data directly. Forgoing ZFS throws out the happy path where the checksum does catch a data error and repairs it transparently.
Edit: To add on to this, ZFS doesn't do parity-based repair at the checksum level. In the mentioned case (good data, bad checksum) no copy of the block will match the checksum and there will be no supposedly-good block to copy over.
As I understand it, this is just a myth. Here's a post [0] from Matthew Ahrens, one of the co-founders of ZFS who has remained active in its development:
> There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
> Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10).
Ooooo, I hadn't heard about that one. I have one non-ECC box running ZFS where I might want to enable this. If the performance impact is negligible, it'd be worth trying.
Without ECC memory, ZFS carries the nasty risk of writing good data with a bad checksum, leading to data loss which would not occur in other filesystems
Assuming a memory error somewhere:
On ZFS you'd be writing bad data with a bad checksum, which would be caught by ZFS later on.
On (most) other filesystems you'd be writing bad data and no checksum, and you'd be none the wiser until garbage comes back.
It's a myth that ZFS requires ECC memory; ZFS is safer when running with ECC, but without ECC it will still save your data in a lot of places where most other filesystems won't.
On the other hand, it carries the advantage of being able to correct bad data (or at least detect it) if it writes bad data and a good checksum, which other filesystems won't do. Seeing as the data for a check-summed block is much larger than the checksum itself, this seems like a net win as assuming a uniform probability of memory errors for each byte of memory, an error is more likely to occur in the data (though I guess it depends on the specifics of the implementation).
I have several 4GB machines that's used in production (ZFS on Linux), however, it's not problem free and require lot's of tuning, the correct workload and smaller sizes of disks.
I have the same setup on 2 pis, and even on a 3b+ I've found it's easier to just put a cheap little microSD card in to hold the bootloader than to try to get USB boot working.
The Pi3b+ can boot of USB without any SD card. Can also do this on previous model https://www.raspberrypi.org/documentation/hardware/raspberry...
but as you can read, that would make a permanent change to enable via a one time programmable bit and remove the ability to boot from SD card.
Though as you have the 3b+, then you have none of that dilemma and it will just boot, done it myself.
858 comments
[ 393 ms ] story [ 923 ms ] thread(I'm new to all this, also unclear on the "dumb terminal interfacing" scenario... is that specific to using Kubernetes?)
I think GP means terminal access through SSH/MoSH
Other than that it's just a normal linux computer.
Mind, I've only done command line and text mode editors, if you want the full desktop and a ram hungry IDE it's going to hurt more.
https://www.raspberrypi.org/documentation/hardware/raspberry...
[0] https://www.alternate.de/Apacer/AS350-120-GB-Solid-State-Dri...
Sometimes it's doable, sometimes not.
https://www.aliexpress.com/item/KingDian-Newest-item-Portabl...
and also have this:
https://www.aliexpress.com/item/KingSpec-External-SSD-hard-d...
These are cheap Chinese SSDs, so I'm not sure about their longevity. There are also similar Samsung SSDs for ~2x price.
Another alternative is to get a good industrial SD card.
[1]: https://github.com/rcarmo/azure-pipelines-multiarch-docker
I run Nginx -> Postgrest -> PostgreSQL on the R.Pi, and it has served me faithfully for more than a year. It is blazing fast ( _for my needs_ ) and I can quickly replicate and setup another R.Pi if needed in a jiffy. I can't wait to port my setup to the new ARM64 R.Pi4!
USB 3.0! Gigabit Ethernet! WiFi 802.11ac, BT 5.0, 4GB RAM! 4K! $55 at most?!
What the!? How the??! I know I'm not maintaining decorum at Hacker News, but I am SO mighty, MIGHTY excited!
I'm setting up a VPN to hook this (when I get it) to my VPS and then do a LOT of fun stuff back and forth, remotely, and with the other RPI at my folks.
It sets up systemd and iptables and generates all certs and keys and wraps them up into tidy, per-client .ovpn files
Could you provide some details? The USB-adapted ethernet & lack of wifi sounds limiting for a NAS.
The existing rpi lines are seriously IO bandwidth constrained in every manner. The USB3 on the 4 hopefully fixes some of this. Bottom line, unless you don't mind your photo's taking minutes to copy, your going to be much better off with pretty much anything else besides a rpi3 as a file server.
Using the Pi as a file server can be a bit flaky. The ethernet controller was an USB one, and was neither really stable or took load very well. The new PHY on a dedicated link is probably the single biggest improvement with this new revision.
The HEVC is a bit unexpected considering the high license fees and general uncertainties. Let's hope the documentation can be released as well.
https://www.raspberrypi.org/documentation/configuration/conf...
So unsure at this stage, but that may well be the case for any license fees regarding HVEC. Heck, if they have absorbed those costs into the base price - I'd be utterly amazed.
I just setup my RockPro64 with 4GB, also PCIex4, have an SSD, going to setup a raid at somepoint when I get it all figured out. The board was a bit more expensive than the pi4, but I am interested in playing around with it.
But it looks like its back ordered for awhile
https://github.com/ayufan-rock64/linux-build/issues/112
https://dietpi.com/
Hmm... that explains a problem I had with a pi of mine. Every time the 10/100 switch it was connected to rebooted, the pi would lose its ethernet link until rebooted. Never had this with other machines on the same switch.
Does it have PoE? Having to deal with one less cable would be nice.
Especially given that the latest spec, IEEE 802.3bt from September 2018, now allows for up to 100W per port:
* https://en.wikipedia.org/wiki/Power_over_Ethernet
https://www.raspberrypi.org/products/poe-hat/
https://www.raspberrypi.org/blog/introducing-power-over-ethe...
IMHO, if one is going to do one of these types of embedded systems, then PoE should really be part of the design process from the beginning.
They're using the Ethernet on the BCM2711, and Broadcom has sadly deemed PoE not needed I guess.
The PoE HAT had a bunch of issues:
* https://www.theregister.co.uk/2018/09/11/raspberry_pi_poe_ha...
They released a new version quite a while ago.
I agree that it would be nice if PoE was built in, but there are better ways to say that than what you said.
Also, the HAT has a transformer (and I assume if they included it, they know what they are doing), which seems like it would be too much for every single Pi to include one.
It doesn't draw anywhere near that. 15W max (for accessories), and 7W in heavy use (without anything other than the board itself).
Why plug in two cables (USB-C (power) and Ethernet (comms)) when you can just plug in one?
- New SoC puts out more heat. Active cooling more important now.
- Video playback at 4K requires H.265
- Micro-HDMI cables now needed.
- Draws more power.
Other than that, looks like a major performance boost.
Not really a con IMO, I haven't seen anything on a 4k bluray encoded in h.264, everything seems to be 265. The microHDMI is kind of a bummer though.
I actually wonder if the A72 CPUs onboard are fast enough to do software h.264 4k decode. They might be.
Pretty much everything works on the existing rpi. Heck you can run Windows IoT on it. It has a UEFI firmware (edk2) port which mostly complete, and pretty much every distro and 3rd party OS supports it. And the hardware itself is mostly open at this point.
If you're doing stuff that needs the Jetson, it's great, but the Pi is definitely better supported.
A57 and A72 are very close in performance, as the A72 is an evolution of the A57. ARM's numbers have the A72 around 20-30% faster than the A57. The main advantage of the A72 was it fixed the horrific power problems the A57 had so in a phone usage you could actually use the CPU for longer than 10 seconds. But in raw performance it wasn't that much of a jump. A53 to A72 is around 2-3x as fast, though. A53 was the power efficient one. A57 was the performance one.
Both the Jetson Nano & Pi4 are clocked at around 1.5ghz, so the Pi4 should still eek out a bit of a CPU performance gap over the Nano. But if you're purely comparing factory vs. factory then the Nano would probably win over longer stretches as the Pi4's lack of heatsink results in it throttling down to around 1ghz after a few minutes. The Nano looks like it has a beefy enough heatsink to keep the A57's churning for a lot longer at their 1.43ghz spec.
Then you should also compare the Chrombooks with second hand large format laptops, old servers on sale with new ones and so on.
Chromebooks 'on sale' are an entirely different class of product than raspberry pi's, they are larger, need wall power, have built in batteries and screens, are in general still more expensive and do not have GPIO.
RPis pretty much never go on sale.
(I speak as someone who sucks at programming and doesn't spend a 1/100th of the time learning the latest as I used too as a teen. So having the community around to help with my latest project that I need something more than a microcontroller for, is immensely worthwhile. Obviously those who don't need these types of spillovers would probably be better served with other hardware.)
I mentioned it above, but just to reiterate- there are lots of great hardware boards out there and many beat the Pi (though the 4 makes up the different finally). However, they ALL have terrible software support: old OS's, bad drivers, out of date or incomplete documentation.
The Pi community makes it worth it to stay there.
The big shortcoming of the other Raspberry Pis I have is power. Plug anything into it and you risk undervoltage problems (even with the official supply)
I hope the new power input will stablize things.Would be nice to build a NAS with as few cables as possible.
For example, recently I plugged in a USB stick and a webcam and couldn't boot. So I would boot, then then plug in the webcam ... carefully. And there were still 2 usb ports free.
Is USB and network bandwidth still shared?
Better than one could've hoped!!
> The BCM2835-based chip in Raspberry Pi 1 to 3 provided just one native USB port and no Ethernet, so a USB hub on the board provided more USB ports and an Ethernet port. The 3B+ added a dedicated LAN chip, which gave it Gigabit Ethernet, but this was limited to USB2 speeds. The Pi 4 has dedicated Gigabit Ethernet, and because it's no longer throttled over USB, its networking speeds are much faster.
> Fortunately, 2711B0 has turned out to be production-ready, which has taken roughly 9–12 months out of the schedule.
> Fortunately, 2711B0 has turned out to be production-ready, which has taken roughly 9–12 months out of the schedule.
According to their article they finished after 2 revisions rather than the predicted 4-5.
I have had gigabit internet for a few years now, and every day on average, I torrent a Blu-Ray image onto my main computer. However, subsequently moving the Blu-Ray to my Raspberry Pi 3 media center is always slow on two counts: 1) ethernet from the router to the Pi was limited to 10/100 speeds, and 2) the Pi could push large files to an attached hard drive only over a USB 2.0 port. Consequently, on a Raspberry Pi 1–3 it takes an hour just to move a high-definition file around one’s home network! On a Pi 4, it looks like one can just put the torrent client directly on the media center.
I can't trust my main computer to be stable for that long, and certainly wouldn't want to rely on it for long-range contact.
The “more powerful computer” is a laptop, and it is only being used for torrenting the films because it has gigabit ethernet. I don’t want to have to leave it on all the time, and sometimes it is still packed in its case when I want to sit down and watch a film. Storing the films on a hard drive attached to the Pi is a lot more convenient.
It does suffice on average, but the bitrate changes a lot within the same file.
Even 4k doesn't seem to push past 50 Mbps, but I think that's because h.265/HEVC is more efficient for the same observed quality/CRF.
Blu-rays use H.264 High Level 4.1. That has a maximum bitrate (for a single buffer) of 50 Mbps. The average bitrate for an entire disc is usually closer to 25-30. Even the most extreme cases, like the mastered-in-4K Lawrence of Arabia, have peaks at about 48 Mbps, and average bitrates of about 42 Mbps.
If you're having issues streaming Blurays on a 100 Mbps network, the speed of the network is not your problem!
Also, Ethernet does simply stops working way before 100% of the bandwidth is used.
I don't know why you expect things to run smoothly at 50% utilization.
Well, it COULD be the problem if you're not actually getting the 100 Mbps. I've diagnosed WiFi that should have a lot more headroom than 100 Mbps but still stutters on mid-bitrate 1080p. Signal degradation
The model 3B+ already had this though.
Just read theverge review on how the Pi struggles to play a video full screen, even if resolution is 480p. How are then people using it as a media center?
Mind, this is specifically running under Kodi, which is optimized as a media center, and is NOT running also a full desktop environment. Attmepting to do the same in, say, the stripped down Chromium browser was an exercise in frustration. That's always been a major limitation of the 3D acceleration in the Pi, as the libraries took a long while to mature and were always a bit hacky.
The announcement for proper OpenGL support and compositing in the desktop environment is huge for me. It seems like it'll finally push the Pi up into "workshop computer" territory that, while underpowered, should be just capable enough to run some of my always on operations and act as a lightweight CAD station for small parts. I ordered one as soon as I woke up and saw the announcement, and we'll see how well that works in practice.
Are you sure the writer didn't use the board the wrong way? Some people still believe that videos should be streamed after being transcoded because that is the only way to watch them on their ridiculously limited smart TV which lacks the necessary codecs to watch them the right way. Of course doing this over WiFi would make the problem even worse. To optimize network usage, videos should be kept encoded until they reach the player so that the network won't be clogged. If you use the PI to read the movie as a file over a shared SMB or NFS directory, the network usage is so low that you could watch like 20 different movies on 20 different players on the same home network at the same time. Probably even more.
The PI 3 (and to some extent probably the PI4 too) is still behind many other boards in other contexts (openness, performance, price) but playing video is surely not one of them.
I'm not sure that transcoding has anything to do with it, unless the transcoding was happening on the Pi itself (which would indeed be dumb). Most of the time people are transcoding things it's x264 -> x264 with Plex, just with a much lower bitrate (and probably 720p) because (as you say) their player's platform can't handle it and no one cares about video quality these days.
Tom’s Hardware’s review notes that the hardware is able to handle many everyday tasks such as web browsing with up to 15 Chromium tabs, light image editing using GIMP, and document and spreadsheet work using LibreOffice. Unsurprisingly, the sub-$100 miniature PC has its limits. It reportedly struggles with full screen video playback from YouTube for example, even if you turn down the resolution to 480p.
Tom's Hardware were using a pre-release OS so it's possible the issues with video playback were caused by this?
It’s important to note that, at launch time, some important Raspberry Pi software doesn’t yet work on the Pi 4. To run Pi 4, you’ll need to download a brand new build of the Raspbian OS, Raspbian Buster. And not everything runs in Buster yet. During testing, we found numerous Python libraries or other required packages that weren’t compatible with the new OS.
My biggest problems involved video playback. If I wanted to watch a YouTube video, I had to keep it in a window, because even in 480p resolution, it was jerky at full screen. The other task I’d like to perform is playing retro games, but as of this writing, the Retropie package of emulators doesn’t work with Pi 4.
During extensive hands-on testing, I found that, while the 4K at 30 Hz is tolerable, little things like the movement of the mouse pointer are a bit sluggish. If you have a 4K screen, you’re definitely better off going for the 60 Hz mode, but note that the added voltage may also cause your CPU to get hot and throttle more easily.
While surfing the web, looking at still images and just enjoying all the extra screen real estate of 4K is great, video playback is the Raspberry Pi 4’s Achille’s heel, at least as of this writing. Whether we were attempting to stream a 4K video or use a downloaded file, we never got a smooth, workable 4K experience, either in Raspbian Buster or LibreElec, an OS that runs the Kodi media player. Several H.264 encoded videos, including Tears of Steel, did not play at all or showed as a jumble of colours. Even the sample jelly fish videos that the folks at Kodi recommended for my testing appeared as still pictures with no movement. Clearly, there’s a lot of optimization that still needs to be done both on the OS and software side to make the Raspberry Pi 4 capable of playing 4K video.
Unfortunately, even streaming 1080p YouTube videos is a challenge at this point. Running at 1080p resolution, full screen video trailer for Stranger Things showed obvious jerkiness. However, the playback was smooth when I watched the same clip in a smaller window. The same problem occurred, even when I dropped the stream’s resolution down to 480p.
Playing offline 1080p videos works well, provided your screen is at 1920 x 1080 or lower resolution. A downloaded trailer of Avenger’s Endgame was perfectly smooth when I watched it using the VLC player.
[1] https://www.theverge.com/circuitbreaker/2019/6/24/18715211/r...
[2] https://www.tomshardware.com/reviews/raspberry-pi-4-b,6193.h...
tl;dr they "built a gaming pc" with a "wireless anti static bracelet", RAM installed in single channel, backwards PSU, terrible parts choices... don't trust the verge.
they write "It reportedly struggles with full screen video playback from YouTube for example, even if you turn down the resolution to 480p."
I was surprised by this review too. Not sure where they get that from
Ugh.
The board is a bit more expensive, but you can probably get it faster than the pi4 at the moment.
The Dietpi community seems to be pretty great, any issues I ran into were answered pretty quickly
I put together a NAS/Plex box with a Kaby Lake Celeron and some hard drives, but I was thinking of splitting it out into separate NFS and Plex servers.
My understanding is that the RockPro64 has pcie slots on it, which allows Sata boards so you can connect drives directly without usb. Personally, I'm more interested in the odroid-h2, with the native Sata. Unfortunately, it costs far more ($111 without ram) and has no wireless connectivity built in.
Keep in mind that you are in a very small world there... most people alive today will never have internet that fast, personally i've never had a connection above 6 Mbits in the middle of a city, and I know that's likely above the median globally (keep in mind average is a poor metric due to connections like yours, SDL is still the primary type of endpoint for homes)
My point being, the previous generations USB based ethernet still has massive headroom for the vast majority of peoples internet.
Pros:
+ USB 3: Very nice! Finally a pocket-sized, fast USB host.
+ Dual HDMI: Could be useful as a projector computer.
+ 1.5 GHz: Good, it might be fast enough for some real work.
+ Gigabit Ethernet: Excellent for those using it as a NAS.
+ USB-C for power: Not surprising, it's the standard now.
Cons:
- MicroHDMI: Incompatible with the 800x480 HDMI 3.5" screen [1]. Also different again to the MiniHDMI on the Pi Zero (will there be a new Pi Zero soon? Who knows.)
- Power consumption! They recommend a 15W power supply, which means I'm pretty sure this won't run on batteries.
[1] https://www.aliexpress.com/item/New-3-5-inch-800x480-IPS-LCD...
As for the screen you pointed to, isn't an adapter available?
If there are any other high-res small (<= 4") screens, please let me know - the highest DPI that I know is an iPhone 4S 960x640 3.5" screen with a Creotech adaptor.
https://hackaday.com/2019/04/08/give-your-raspberry-pi-sd-ca...
https://www.raspberrypi.org/documentation/hardware/raspberry...
I've got an sd card reader on my laptop, it isn't a bottleneck though.
(How often does this happen?)
The previous 3 versions were already wildly popular, but there were starting to show their age and to be significantly outperformed by Nvidia's Jetson Nano. But the Jetson Nano is significantly more expensive (starting at $99). This fixes several of the performance issues people had and keeps the price at the original $35.
Raspberry pi significantly lowered the barriers to entry for cost and complexity to own a useful Linux computer. The performance for price is really impressive to the point where it seems like the rpi 4 could be a decent daily driver for most people.
>Yes. VideoCore 3D is the only publicly documented 3D graphics core for ARM‑based SoCs, and we want to make Raspberry Pi more open over time, not less.
This stated intention and rpi.org's actions are simply not isomorphic. If they want to make Raspberry Pi more open, firstly, why do they publish only abridged (read: fake) schematics? [1]
Secondly, why was rpi.org caught adding DRM chips to their optional camera addon board? [2]
[1] https://www.raspberrypi.org/documentation/hardware/raspberry... Note the nonsensical, incomplete nature of these schematics, and the complete absence of details such as the USB3 ports, and most of the SoC's connections.
[2] https://hackaday.io/project/19480-raspberry-pi-camera-v21-re...
Secondly, nobody is forcing them to add DRM chips to anything. That's not something that can be written off on "a contractual obligation made me do it." They did it of their own will.
Pi: “Hello we wish to buy a $thing”
Vendor: “Certainly. We sell $thing for ten dollars per unit if it doesn’t have DRM, or five dollars per unit if it does.”
> You can plug any CSI camera into the Raspberry Pi. There's even a kernel driver for the CSI receiver, which we paid for ((link: https://patchwork.kernel.org/patch/9951525/) patchwork.kernel.org/patch/9951525/). What you can't do is clone the official v2 camera module and use the default ISP tuning, which we also paid for.
https://mobile.twitter.com/EbenUpton/status/1088440503622909...
Personally I have no problem at all with protecting the investments around add-ons like this module, if it means they continue to persue them.
Firstly because the rpi foundation is the one manufacturing the camera units. They are buying parts from vendors, not assembled units.
The more components you use, the more expensive a product is to make. They also don't just have DRM chips inseparably piggybacked onto things like CMOS camera sensors.
Hah - sounds like the "boneless vs bone-in steak" sales model - take the bone out of the steak, and suddenly it costs more per pound than it does with the bone left in. Somehow, less costs more - and people sadly pay for it.
Their revenue stream is through the sale of their hardware, why do they need to allow people to make clones?
2) Maybe it's to do with the terms in which they get the camera module?
I don't know but I don't see them selling the camera as interoperable.
Your comment just seems to exemplify the phrase:
"No good deed goes unpunished"
They do something good but freeloaders just turn up and demand more.
If anything, it seems like they've judged that their large size and brand recognition is something that they can coast on to avoid having to offer what other SBC vendors do.
I'm not complaining about rpi existing, I'm pointing out that what they offer is in certain aspects inferior to the offerings of smaller SBC vendors, which is actually surprising, given that their large size should make them much better resourced to match or exceed the offerings of those vendors. This causes me to question whether these values are actually a priority at all, even if they claim so.
Anyone sufficiently cynical (not me) can read the accounts of both entities:
- https://beta.charitycommission.gov.uk/charity-details?regid=...
- https://beta.companieshouse.gov.uk/company/08207441
> This was another year of exceptional growth with Revenues at £25.5m (2016 - 16.3m) and Operating Profit of £9.7m (2016 - £8.9m)
[0] https://en.wikipedia.org/wiki/Nonprofit_organization#Nonprof...
How does paying your employees suddenly make you for-profit?
Do you know the definition of "profit"?
RPi as a board is clearly simple enough that there would be clones if you could get components at competitive prices. The only conclusion is than that you either can't get the CPU, or you can't get it at a competitive price.
RPi use Broadcom chips, which you rarely find these on other hobbyist boards. The most likely cause, after what I heard from people in the industry, is that you usually either can't can't get Broadcom chips at all, at acceptable prices, or even documentation for them when you are only interested in the small quantities you'd need for introducing a new/clone hobbyist board. Not unless you've got some serious connections.
The only reason I would consider buying an Arduino (or similar) is for super-low-power applications.
Otherwise RPi would have been copied a long time ago at a lower price.
If this were software, this would be a discussion about open source, would you accuse people of forking an open source project of being freeloaders?
I hope you realize that by "they" you mean the hardware vendor and by "freeloaders" you mean the vendor's customers.
but that is demonstrably not true. The CSI interface and driver is opensource (https://patchwork.kernel.org/patch/9951525/), anyone can create a camera that piggybacks onto that port. Infact, there are a number of aftermarket cameras that do. Some have built in infrared, some are tiny.
What they are attempting to do is stop counterfeit "official" camera.
Also, all that money goes to either developing more board, or running educational outreach. So I think one can forgive them the urge to protect revenue. It's not like they are microsoft in the 90s, or oracle.
Every one of those afternarket cameras - the tiny ones, the big ones with replaceable lenses, the IR ones, the funny fisheye ones, all of them - works around this by using the same sensor as the official v1 camera and looking enough like it that the existing code will talk to it. This is precisely what the Raspberry Pi Foundation added the DRM chip to the v2 to stop people from doing. They can't do anything about the v1 clones, but they can stop anyone from doing the same with the better sensor in the v2 and they have.
(In theory the open source CSI driver is useful for non-camera hardware though - for example, there's one obscure third party board that uses this for HDMI capture. I think this may be the main intended purpose. It came too late to save the Kickstarter campaign a few years back promising such a board though.)
I'm not saying Raspberry Pis don't have a place, I just think a lot of things people seem to want them for would be better suited by just reusing old hardware, which has the nice side effects of meaning that hardware isn't wasted.
Please, never shorten or distort domain names... I went to rpi.org which turned out to be a spam trap.
Why do people tend to dismiss the openness of the RasperryPi with completely unrelated things? This is the classic case of Whataboutism[0].
Just because you can't replicate the entire product in your garage, it doesn't mean that it isn't quite open already.
[0] https://en.wikipedia.org/wiki/Whataboutism
to stop counterfeit boards. There are many _other_ cameras that you can use for the rpi, so its not like they are trying to block out competition. its to stop people making illegal clones and ripping people off. (cough I'm looking at you amazon)
see semi official explanation here: https://www.raspberrypi.org/forums/viewtopic.php?t=149426
The people that make the raspberry pi are a not for profit, they use the money made to sponsor children learning to code. Its not like they hide their aims: https://static.raspberrypi.org/files/about/RaspberryPiFounda...
tl;dr:
its to stop people making knockoffs, taking money from a foundation who are trying to educate an entire generation.
Cursory examination of rpi firmware suggests that this DRM logic is implemented in start.elf, one of the proprietary blobs required to boot an rpi. This is, in itself, significant, since opening this blob would obviously make this restriction easy to circumvent. In other words, rpi have taken design decisions which essentially motivate them not to open up these boot blobs, but rather use them as a chokepoint of control over the platform, see also [1].
From this, we can infer that rpi.org will probably never get rid of these boot blobs (as opposed to simply not having found the time/resources to do something about them).
[1] https://github.com/nucular/raspi-keygen
But that aside, "as a chokepoint of control over the platform"? What platform are you specifically talking about?
Look Rpi have a clear goal, to get kids coding. Everything, and I mean _everything_ they do is to further that goal. One part of that is to have a platform that is, safe, easy, expandable and _cheap_. A side effect of that is that its mostly open.
Now, is it as open as say fabbing your own RISC-V SoC? no. But then that would cost a boat load of cash, and it would then be cloned and resold by third parties. Thus, no money for education. (worse still, dangerous counterfeits might be bought by schools, cause injury leading to legal action.)
So, being pragmatic, and noting that the ecosystem is far more valuable to me, and almost everyone else, than the hardware, I will accept this behaviour.
It seems that people who care about technology open standards, open source, and open hardware need a clear understanding of Raspberry Pi requirements, and that they're actually getting hardware that is more closed than a typical PC.
(Related: Starting over a decade ago, some IBM ThinkPad models infamously whitelisted mini-PCIe cards, so that only a small set of particular cards could be used, which was very unusual for PC hardware based on open standards. One of the biggest practical reasons to put Coreboot on those ThinkPads is to get rid of the awful whitelisting, so that people could use whatever cards they wanted, including using WiFi cards supporting later standards and working without having to download closed firmware blobs.)
most PCs have BIOS, which is closed source, and difficult to get access to. yes there are opensource alternatives, but they are not entirely practical.
Most modern PCs have a TPM, EFI and a whole host of other bits that make opensource drivers exceedingly difficult. Then there is the graphics card, where if you want to actually have decent speed it means closed source drivers (I'm talking nVidia/ATI, intel doesn't really count as they are adding GPUs as a value add, not a core business.)
Harddrives have closed source and obfuscated software that actually does the writing/reading.
Then there is the out-of-band management that is shoehorned into a lot of Intel and AMD's kit.
so, to say that it is more closed than a PC, is either ignorance or hyperbole.
Also, you have to remember that yes, the PC was based around open standards, but not open source. You still had to pay to get certified, or even get access to the spec.
Considering that you can attach any hardware either in the form of a HAT, or via the CSI, I think the argument is flawed. Again, there is nothing stopping people using a clone, if they so wish. But all the rpi clones appear to be mediocre at best.
Also, define rpi clone - rpi did not invent the SBC genre. Many more open products precede it.
FYI, AMD graphics drivers are fully open now.
so raspberry pi, in an effort to be more open than say Dell/HP, where you had/have to pay to download drivers, bios and other updates, is _more_ malicious than say apple/google who are competing to create a closed garden with a remote lockout, where nothing is owned, only rented?
ya.
I really don't understand this viewpoint.
Look, I've used embedded 386s. I've seen the evolution of ARM SBC first hand. I've used gumstix, sheevas and custom rolled jobbies. You know what united them all? they were bloody expensive and difficult to use. Pis are a joy to use. Plus if you accidentally blow the board, you're not down £500
Adding a DRM so that people can't make knock off cameras, in exchange for a £10 full linux SBC that is _easy_ is a worthy exchange. Even if they weren't a charity. The fact that they are single-handedly dragging the pathetic excuse for IT education in the UK ("here is how to use Microsoft office") into something approaching usefulness is a massive massive bonus.
The ecosystem that raspberry pi supports, the OS, magazines, training, teaching, class room outreach and research can only be done with cold hard cash. That cash comes from Pi sales.
Don't get me started on DRM. Look I know you think that everything should be free, but that means I can't earn a living.
Teaching kids that copy/pasting someone's work, making a halfarsed cheap copy and selling it for loads of profit, with no support is a good moral choice, you might want to re-asses your world view.
Yes open source is good. Yes you should give back and contribute. But, to move forward, money has to be invested, and it has to come from something.
Yes, removing ownership from the people is exceptionally bad. The trend towards the "sharing" economy undermines workers rights to the point that we are entering digital feudalism. But that is another topic.
I don't understand the premise that not applying vendor lockin to a camera module would make SBCs unreasonably expensive. Competing SBCs are more open, many predate the rpi and despite the fact that they probably sell fewer units than the rpi (due to less brand exposure, not cloning), and thus possess lower economies of scale, I've never seen one which costs "£500".
>Don't get me started on DRM. Look I know you think that everything should be free, but that means I can't earn a living.
I think this is clearly untrue from the success of other, more open SBCs.
>Teaching kids that copy/pasting someone's work, making a halfarsed cheap copy and selling it for loads of profit, with no support is a good moral choice, you might want to re-asses your world view.
But I never claimed that kids should be taught that. What I do claim is that kids should not be taught that it's ethical or normal/acceptable to try and use malicious functionality to institute vendor lockin, creating an artificial monopoly in compatible peripherals, because it isn't.
Moreover, it appears this DRM has had a chilling effect on third-party cameras with novel functionality (i.e., not competing for the same applications as the official camera), according to a comment posted above: https://news.ycombinator.com/item?id=20261787 So there's real evidence of harm done by this.
>Yes, removing ownership from the people is exceptionally bad. The trend towards the "sharing" economy undermines workers rights to the point that we are entering digital feudalism. But that is another topic.
It isn't another topic. There is a systemic trend of hardware vendors using firmware to advance and prioritise their own interests over those of the device owner, essentially using technological measures to undermine the first sale doctrine. Of course, this isn't illegal, though it ought to be.
The way I see it, a Raspberry Pi is more than the sum of its parts- while commercial companies care about the chips and the complexity a solution like a Pi can remove, I personally bought a Pi for my brother to learn on.
2006, gumstix with bluetooth was $180, but that was a very small system to dev for. embedded 386 in volumes of 1 were ~£380, CF flash(certified) £80-200. Software was extra, as was the debugging interface, which may or may not be a fancy serial port. Ethernet, RF, all extra. Wifi? naaa.
The arm board, I don't know how much they cost because they were custom made. So hundreds of thousands I suspect.
Then we have the tools that supported it, not exactly kid friendly.
The point is that for some unknown to us reason they deemed it a good idea to add DRM on a side-project they have. But that doesn't mean they can't make a new camera at some point.
Currently they are defending this practice, however. It logically follows that as long as they institute this policy of using DRM on the main product to prevent use of third party camera modules, the boot blobs will remain...
Btw the situation with the binary blob has been going for years and from what I've gathered in the past what's happening is that the foundation members signed an agreement to not reverse engineer anything on the SoC when they made the first Pi. Since then they offered a price for an open source gpu driver but didn't follow it up with more competions. So either Broadcomm shut them down or it paid off in internal pressure since Broadcomm paid and provided the mainline driver used in this version.
Outstanding. Very pleased with this upgrade
But it is sort of refreshing not to have the early announcements and then wait for ages for the actual release. And to then either have further delays or find a half finished product that was rushed out to meet some promised deadline. Plus I like waking up to surprise rpi announcements!
Just means i can start planning my upgrade before ive even built the first version lol
https://en.wikipedia.org/wiki/Osborne_effect
https://www.netonnet.se/art/ljud-och-bild/kablar/hdmi-kablar...
So it's not rated for 4k, but it will support all the DRM stuff.
Or there were no cheap enough stacked port.
I used to lose the Micro to C adapters all the time, I lost the C to headphone for my OnePlus6T while travelling and was unable to find a replacement so no headphone use for me.
Also, I have about 12 Raspberry Pis, as many display devices, a dozen or so other HDMI devices such as consoles etc, and tens of normal sized HDMI cables lying around and they're all compatible.
If I remember correctly (and that's a big if), DisplayPort started royalty-free but then they introduced royalties. From my blurry memory: I checked once many years ago and it was free, but then I checked again a couple of years later and it wasn't exactly free any more. Did it change again? Or am I completely wrong from the start? If someone remembers the history better than I do...
More common in monitors perhaps, but I don't think I've ever seen a TV with a DP input. Since AFAIK the target market of the RPi is "plug it into a TV, plug a cheap USB keyboard and USB mouse, and you have a working computer", having HDMI output is a requirement.
https://www.raspberrypi.org/documentation/hardware/raspberry...
[0] https://blog.mythic-beasts.com/2019/06/22/raspberry-pi-on-ra...
the fact that they decided to go with a 2015 inefficient one is kinda strange
Name one?
[0] https://www.hardkernel.com/shop/odroid-n2-with-4gbyte-ram/
Is there any improvement in this? It's pretty important as RPi usually boots off it.
"Support for these additional bootmodes will be added in the future via optional bootloader updates. The current schedule is to release PXE boot first, then USB boot."
https://www.raspberrypi.org/documentation/hardware/raspberry...
Doubled, so I guess around 40 MB/s. Still a far cry from fastest SD cards that can both read and write over 250 MB/s. Hopefully RPi4+ will improve on this. :-)
<captainpickardfacepalm.gif>
I'm very happy for RPi4 SD improvements. Until now, RPi has had same lacking ~20 MB/s SD performance from the start. AFAIK, this is the first time ever there's been any hardware improvement in this regard.
I've had a microsdxc card with 90 MB/s reads and 80 MB/s writes since early 2014. Some current cards can read & write more than 250 MB/s, so there's still room for improvement.
As 95-99% of all RPis boot from (micro) SD and use it as primary storage, I'd say SD performance is a rather fundamental (often ignored) aspect of RPi performance.
Of course you can. My tongue was very much in cheek :)
...but still, it was announced today, savour the moment :P
https://www.raspberrypi.org/documentation/hardware/raspberry...
"The Pi4B has a dedicated SD card socket which suports 1.8V, DDR50 mode (at a peak bandwidth of 50 Megabytes / sec). In addition, a legacy SDIO interface is available on the GPIO pins."
I'm very excited about these upgrades too (especially GigE), but as far as I can tell nothing on this news page specifies whether the Pi will also support HDR output as part of the 4K upgrade. That's most of the practical benefit of 4K - that 4K releases tend to come with HDR10 or DolbyVision support.
Anyone know if we can expect HDR output to work? If I knew it supported that I'd be purchasing one right now to upgrade my media center from my current Pi 3 setup.
Even the tech specs page says nothing about 10bit decoding, which is required for most real world 4K HEVC video.
> H.265 (4kp60 decode), H264 (1080p60 decode, 1080p30 encode)
https://www.raspberrypi.org/products/raspberry-pi-4-model-b/...
While I could have a slightly larger TV, I think that for typical domestic use 4K's improvement is marginal because people are not sitting 50cm from the screen and room sizes are limited.
Really, so far the top benefit has been that I could tell my wife: "Look, if I move right up to the screen I can still see Jeremy Clarkson's individual hair strands!"
If so, you're right; that's pretty small. Is it just a matter of acclimation?
Also, can you clarify what you mean that you're lucky to have a house? I wasn't aware of a major homeless problem in Europe.
Have a random right move link of what I think as typical Victorian worker's terrace: https://www.rightmove.co.uk/property-for-sale/property-62228...
The door by the yellow chair is a tiny porch with front door beyond. No idea how it compares with OP's.
Homes in the UK can be expensive, so there's a large rental market.
On top of that many people are vulnerably housed - living in emergency temporary accommodation (which may be for many months) or on friend's sofas.
The introduction of the benefit "Universal Credit" has increased homelessness and people who are vulnerably housed. In the UK a landlord can apply for eviction if the tenant hasn't paid for two months. (This is for shorthold tenancy agreements where tenants have most rights - other tenancies have less protection.) There is a minimum wait of 5 weeks before Universal Credit claimants get paid, which pushes some people very close to this limit. The bizarre sanctions regime tips many people over that limit.
Detailed information can be found here:https://www.crisis.org.uk/media/238700/homelessness_monitor_...
How do you cope in a car?
But joking aside, I'm surrounded by glass on all sides in a car. That makes a great deal of difference. I probably wouldn't feel confined in a room that size if I had an entire wall of glass.
I've got a variety of content that is, technically, a video stream that decodes into a framebuffer that is a "4K" framebuffer according to the metadata on the video, but without enough bits for it to truly be "4K"; the same number of bits dedicated to a 1080P video would look just as good.
For all the bragging about how streaming is the future, it seems to me that the companies providing those streams at scale still have a lot of incentive to cut the bitrate back so far that it's not practically a 4K stream anymore, because 95%+ of their audience can't really tell.
I find that when my own vision is slightly blurred, add in even more slight blurring on the screen and they compound each other. On the other hand if the source image is pin sharp, it makes it easier to cope with the flaws in my own vision.
I'm sure higher resolution is nice, but nowadays I'm more interested in HDR and larger colour gamuts (Rec.2020).
I don't doubt 4K and 8K look "better", but IMHO we're approaching the point of diminishing returns, and visual enhancements in other areas are worth exploring (even for 1080p).
And they'll remove the optic nerve connector in favour of Bluetooth that will allow them to be 0.1mm thinner, and be wireless!
Ps did you miss iBalls on purpose?
The current gen are about the size of a quarter and are bluetooth capable, so he can sync to his devices, watch movies, etc with these little guys tucked behind some hair.
It got me thinking, I wonder if audio guys have started to look at some of this sort of thing to really "hear" music perfectly. Very interesting tech.
If hearing is down to tiny hairs in your ear resonating with the audio frequency, I would have thought being hard of hearing was down to those hairs not being able to function properly. How does bone conductance audio get around that? Does it use a different sense?
My eyesight is also going, I have to rub my eyeball on the phone screen like one of those anti-deorderant balls, I daresay my hearing will be next.
homo cyberia
(That's probably nonsensical latin, if anyone with a modicum of latin knowledge wants to go all Life of Brian on it, please feel free. What is latin for augmented human?)
I guess maybe if you added a heatsink and/or fan? I'd be a bit concerned about component life, taxing it that hard.
Oh yeah, and I wanna see how this thing overclocks.
You people are never happy, aren't you? You're still getting more stuff for basically the same price...
[edit] looking at the benchmarks it's a modest boost. Now about twice the FPS of a PI-2 for Quake3 at equal resolution. Be interesting to see if something with more complex shaders changes the relative performance.
[1] https://en.wikipedia.org/wiki/Rec._2100
[drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
So this is vc5/6, not vc4. Additionally:
Edit: I found this thing someone on the RaspPi forums put together! https://cdn.shopify.com/s/files/1/1560/1473/files/Inside_Ras...
> The Pi 4 has seen an upgrade to VideoCore VI.
> The H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1
Sounds promising! (The documentation on the website should certainly be fixed if this is correct.) Now assuming Rec. 2100 is properly supported to allow connecting to HDR capable displays over HDMI 2.0, we should be good!
As hopeful as I am, that's quite a big assumption...
(But it also wasn't capable of 4k60, so maybe there are some modifications there.)
Now does it make sense to have your video decoder support 10 bit when your compositor can't handle that format? I guess you could argue that 10 bit source material will still improve the quality even if you downsample it to 8 bit for display, and I think for example DVB-T2 has standardized on 10 bit so if you can't decode that, that's a large chunk of market gone.
Ultimately, from the little we know, the compositor hardware is the same as the old Rpi, and that couldn't do 4k60 and it can't do 10 bit depths. The Raspbian image currently doesn't use the Linux kernel implementation for driving the compositor (it uses the fkms or "firmware kernel mode setting") so there might well have been hardware tweaks.
(Ok, instead of making this comment thread any longer, I simply asked and the compositor hardware in the RPi indeed has HDR support:
https://github.com/raspberrypi/linux/issues/3020#issuecommen...
Tweaked from the old HVS in the old RPis.)
For HDR videos, I still play them via my Windows box. I think the current MacOS supports HDR too (and if not, it will get support soon as they have that crazy new $6k HDR screen).
"The 4B hardware is HDR capable, but software support has a dependency on the new Linux kernel frameworks merged by Intel developers (with help from Team LibreELEC/Kodi) in Linux 5.2 and a kernel bump will be needed to use them. Once the initial excitement and activity from the 4B launch calms down, serious work on HDR and transitioning Raspberry Pi over to the new GBM/V4L2 video pipeline can start."
Full article: https://libreelec.tv/2019/06/libreelec-9-2-alpha1-rpi4b/
No datasheet for the SoC either. Again.
There are vastly better SBCs out there.
Can you provide some examples please?
Always keen to try out any alternatives
https://www.friendlyarm.com/index.php?route=product/product&...
Has an eight-core 1.4GHz CPU, and is otherwise mostly comparable to the new Pi: 1G RAM, 1Gb ethernet. Has an SD card slot and no built-in storage.
But yeah, perhaps it's better to have a lot of small cores for a cluster.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
Edit: Ouch if this turns out to be true... https://www.raspberrypi.org/forums/viewtopic.php?t=243410
Edit 2: Ah, also RPi3B and 3B+ didn't have those extensions. Oh well.
Edit 3: Just tested my bog standard RPi3B+ running Raspbian. It could do "openssl speed -elapsed aes-256-cbc" 43 MB/s AES-256-CBC. Tried also with "-multi 4" and it resulted 144 MB/s using all 4 cores. So perhaps RPi4 will be fast enough with CPU only crypto... would still love to have HW assist.
Edit 4: RPi4 running 32-bit OS can do about 65 MB/s per core aes-256-cbc. 85 MB/s per core for aes-128-cbc. So by using two CPU cores for encryption (+ heatsink + fan :-)) 1 Gbps ethernet can be saturated.
I think it would be pretty tricky to get LUKS to use it, though. At least writing a kernel module, but most likely LUKS patch would be required. You'd probably have to choose between 3D acceleration and full disk encryption.
Looks like VideoCore VI is getting some compute shader support:
https://gitlab.freedesktop.org/anholt/mesa/tree/v3d-cs/src/g...
Hmm, anyone know if the VideoCore VI would be any good for crypto?
We'll see.
[0]: https://www.phoronix.com/scan.php?page=news_item&px=Broadcom...
So if you need to go through/process gigabytes of data on encrypted drive, having to do encryption in SW will slow you down massively, especially if you also need to process the retrieved data somehow.
In fact, being slow can be considered a feature in this scenario.
https://github.com/ThomasKaiser/sbc-bench/blob/master/Result...
See PineH64 for example.
Shipping from them used to be horrendously expensive, but I'm happy to notice that changed. Thank you.
The RPi has such a big community that I imagine performance and optimisation will quickly surpass other chips, eg. Rockchip RK3399 [1] (2xA72 and 4xA53) and will probably end up on par with an Amlogic S922x [2](4xA73 and 2xA53).
[1] http://rockchip.wikidot.com/rk3399 [2] https://www.cnx-software.com/2019/02/01/amlogic-s922x-benchm...
To get the full performance out of the RPi, you are going to need a beefy heatsink or it will thermal throttle very quickly.
Which ones would you recommend for this price?
Plus, the Pi 4 will have something approaching mainline kernel support and a large community of people working on it.
The RPi3 has in fact mainline support, but is not "fully compatible" (at least, in the x86 sense). I guess this will be the case for the RPi 4 also.
This is a shame, since any ARM board has essentially an expiry date. For this reason, my next board will be an x86 SBC (the "famous one"), however, it costs considerably more.
- VideoCore VI graphics, supporting OpenGL ES 3.x - including 3.2? GFLOPS?
Does it support Android, Play Store etc?
thanks to this comment: https://news.ycombinator.com/item?id=20261084
Not in a way supported by Google of course.
- Half the RAM but double the cores. I'm waiting for some benchmarks to see if the RPi4 is faster and by how much.
- Also Gigabit Ethernet and it works great. My downloads are always at 108-111MB/s for the whole transfer.
- Not USB 3.0 but has "oldschool" SATA through an internal USB-2-SATA adapter. It's at least more compact, otherwise the RPi4 with an external USB 3.0 drive will probably work even better.
- works with a normal 12V power supply, which could be lying around already, from older external drives.
Not to disrespect the RPi4, as I'll be getting one of them too very soon.
Even don't think about it - shitty support from vendor. They don't care about updates in general.
I say that as both a Gentoo and Kali ARM dev
Take a look here if your board is supported.
https://www.armbian.com/download/
https://dietpi.com/#download
On a more personal note - thank you for your service.
You got any advice for pulling the aircrack_ng/rtl8812au driver from github and making it into a patch for building in-kernel? I really like having signed-module verification, but I also really want this driver.
Of couse, such SBCs have an expiry date (which is also official), but this applies to any vendor, not only to them.
Additionally, they're one of the most engaging companies when it comes to community - just check their forums and see for yourself.
While I think pretty much any programmer could reapply them, my guess is that in the long term, one needs to know how device drivers development works, in order to adapt to the kernel changes. But I'm not a kernel dev, so the maintenance could be easier.
Furthermore, SATA and Ethernet are connected to individual USB3 busses, as opposed to earlier RPi designs where everything shared the same USB2 bus.
I haven't checked the RPi 4 specs yet, but i can imagine it's still the same layout, just a faster bus, which can be "just fine" - it should be plenty fast to saturate a Gigabit ethernet as well as the SSD/HDD IO required to do that.
"Double the cores" is not a valid consideration - 4+ core configurations typically have 2/4 cores (the 5422 has 4) with a high-powered architecture, and the remainder with a low powered one.
Compare for example the XU4 with the N2 - the N2 is more powerful, and yet, it has less cores (4 hp. + 2 lp.) and requires no fan.
The RPi is an interesting configuration - they have 4 high-powered architecture cores (4x A72) only. It seems it doesn't require any fan.
Of course if one requires specific chipset/components, we're talking about specific use cases, which is another story.
Can we just start calling them servers again?
* Home Lab :: Running a partial/full enterprise IT stack for fun and education.
* Home Server :: Running primarily internal services like file storage, backups, media streaming, home automation, maybe some light networking.
* Home Cloud :: Running primarily external services on the public internet to replace 3rd party SaaS services. More often than not this is done with a VPS provider rather than physical hardware in your home.
So maybe you find the terminology annoying since everything is cloud these days but it's genuinely useful to us folks in the forums. You can also call "home cloud" selfhosting if you find it less jarring.
Also, it seems like Western Digital would be an ideal player in the space since they want to bring processing to data storage via RISC-V.
[0] https://rootprojects.org/hub/
[1] https://github.com/Kickball/awesome-selfhosted#file-sharing-...
Of course hardware hasn't been expensive for probably a decade or more. Today it is almost entirely a software problem. Or more precisely how to create independent quality software when many developers are employed by large corporations and no one wants to pay for development. I am not sure much is happening on that front.
If does go down then it's not cloud, no matter what hardware you're using.
In general, my rule of thumb is: what's the upper limit, the capacity or your wallet?
If the limit is the capacity, then it's HA.
If the limit is your wallet, then it's cloud.
Last I checked, Amazon had the fewest 9s of the three (going back a few years...)
If you pay enough money to run things on their computers all problems are solved. it is only when you self host that is the problem :)
Seperately, you’re not going to fool anyone by calling a server something else. (Not that “home cloud” is a bad term, but I think everyone realizes that still constitutes a server.)
If we had the logs I'd bet money that someone Googled "home cloud" to see if that would somehow get around hosting a server behind residential.
I'd also bet that even more people nodded "knowingly" while reading my sentence about blockchain.
Needless to say, I won't be reading that link.
Wordpress.com wouldn't have done that with your content. Just saying.
Medium, on the other hand, does. I mean, it's not much - I get a slice of the revenue from paying subscribers', based on how much they 'applaud' my piece - but it's higher than zero. Despite this, Medium also makes it available to read free of charge for non-members - up to, I believe, a somewhat miserly three articles a month, though you can bypass this if you really must by using a private browsing window to get another three, and another three, and another three, and another three...
I've got kids to feed and bills to pay. If you really don't want to click an X on the login prompt and read it all for free, I can give you my payment details and sell you a PDF copy...
- would you mind sharing how much you actually you expect in revenue from this article?
- Have you considered any other ways of monetizing it? Just an idea: if you had your own blog and registered on Brave as a content creator, you could be getting a few cents from me already.
Then how much you actually get is totally up in the air. If mine's the only piece Reader A applauds that month, I get 100% of the revenue (minus Medium's cut, of course - the house always wins); if Reader B has applauded 1,000 pieces this month, I get 0.1 percent of the revenue (as do the other 999 authors.)
It's a model which is inherently insular: of the traffic that has visited the piece so far, 90% is external (and thus earns me nothing other than name-recognition) and 10% is internal to Medium. Only a tiny, tiny fraction of that 10% has applauded, and I won't know what that translates to in terms of Cash Monies until Medium calculates it and tells me. I'd be much better off promoting it to existing Medium members - such as by joining a 'publication' on Medium - and ignoring external traffic sources, but I don't want to do that.
As a ballpark, though, the answer - long in coming - is "not much, but considerably more than I'd get on Brave." The Raspberry Pi 3 B+ benchmarking piece I wrote on Medium has earned about $277 lifetime; if this earns the same, I'll have done very well indeed.
Thankfully, I'm not relying on the Medium income: I've pieces in various websites and magazines based on the same core data, which pay one heck of a lot better!
I've even considered Brave. Hell, I've even tried Brave. According to my email archive, I signed up as a publisher in January 2018. Sadly, it's just not a sustainable model yet - which is why my piece is monetised by Medium, not Brave.
Sorry, it is really not my intention to pile on you. I am just really tired of the current state of affairs in regards to the publishing/authoring economy. I know it is easier said than done, but we need to have more content creators that are willing to take a principled stand and stay away from these actors and start creating exclusively on terms that are more ethical.
So, you won't support content creators who publish on a website which uses advertising.
You won't support content creators who publish on a website which allows non-members and free-tier members access to a limited number of articles a month and charges a fee, distributed to the content creators, for unlimited access.
You won't support content creators who publish in print, in magazines or newspapers.
I'm sensing a theme, here: you won't support content creators.
I would love to host my own website (actually, I host several) and write the same kind of content I do now, but how exactly am I going to feed the bills and pay my children? This is literally my job - I'm not just dashing out a quick blog post as I Segway to the London office of my cryptocurrency startup for a day of find-and-replace in the whitepaper. If I'm not getting paid for my words I'm not getting paid at all.
Brave is not the answer, I'm sorry to say. Something like Brave may be - I used to play around with Flattr, which was the same kind of micropayments model as Medium but applicable to any third-party web content, and doesn't have the ethical issue of blocking everybody's adverts but its own - but Brave ain't it, at least as it stands.
You don't want to support content creators, you want to support Brave. That's fine, but don't frame it as wanting to support content creators but only in one very specific and questionably-ethical way.
Otherwise, put your money where your mouth is: pop me a payment across, in the currency or cryptocurrency of your choosing, and I'll publish the same piece on my main website. No adverts, unless you count the cover shots of the books I've published (hey, there's another way you could support me - and if you're worried about ethics, some of them are available for free download under a Creative Commons licence!) down the side.
I am also contributing about ~10€/month on patreon for different software projects and writers. I've written to more than one youtube channel producers asking them to look into alternatives so that they could take my money. The Quilette model is also something that I do appreciate.
Believe me when I say that I am more than willing to support people that create content. And depending how much you are asking for me to send you, I'd gladly take on your offer.
* story time: I got a call from an Eyeo recruiter some months ago, who was looking for people in their ad-block/acceptable ads team. It turned into a most-of-the-time-friendly discussion about how acceptable ads does nothing about the tracking of the users, so I wouldn't be interested in joining their team and me asking him to call me back only if he had some position on flattr.
But what about the person who wants to write full time, but hasn't built the audience yet? How do they go from $5 a month to paying the bills? In my case, I didn't have to: by the time I switched careers I had enough regular clients to cover all my outgoings, albeit only just. Quit the day job, picked up some more clients, and here I am doing it full-time to this day.
If I were relying wholly on Patreon - or Brave, or Flattr, or even Medium - I couldn't have done that. Patreon isn't going to give me $300 on spec to write an article that might not do well; Medium won't front me a few grand against royalties so I can take time to write a book.
D'you know who will? The traditional publishers.
I appreciate you have a personal stance on this, but so do I - and mine comes not from the perspective of "I'd like to read this but it's on a website I don't like" but from the perspective of "if I don't get paid for this I'm literally homeless."
Actually, I have a Patreon account - https://www.patreon.com/ghalfacree - I signed up just before the new fee scheme came in to lock in the old rates, but never launched it (hence the zero backers.) Don't really have time to give it the love it would need to gain traction, either - again, we're back to the problem of not having the cash to go from zero Patrons to I-can-feed-my-children Patrons.
Yes, this means that I will actively find ways to accelerate the demise of these business. No matter how much I want to support content creators, it does not make me responsible in guaranteeing their job.
Would you accept to be requested documents when you enter the mall? Would you find normal to be stopped by a security guard that says “sir/madame, you’ve browsed enough stores for free without handing in your id card and personal data, please fill this form or leave” ?
I owe you nothing. If anything, you owe me. It’s my time that builds your audience, not the other way around.
Ordered a starter canakit with a couple extras, and looks like I won't see it until August. :-( ... I'll probably forget I ordered it by the time it comes.
According to the response I've gotten so far, it will not support HDR or 10 bit. :-( However, the vast majority of SDR content is 8 bit. The few exceptions are mostly a few pirate groups who mostly encode anime.
Edit: this is apparently now in doubt.
https://libreelec.tv/2019/06/libreelec-9-2-alpha1-rpi4b/
I think I might go ahead and put in a preorder.
With 4GB of RAM, you'd even be able to use ZFS.
- 1Gbit ethernet
- 1Gbit USB 3.0 port 1
- 1Gbit USB 3.0 Port 2
Total: 3Gbit of 4Gbit, having some margin to spare.
1 Gbit Ethernet over RGMII
4 Gbit PCIe Gen 2 shared by 2 USB 3.0 (so 1x 4 gbps max or 2 x 2 Gbps shared)
Total: 5 Gbits, no margin to spare
Only if both drives are saturated at the same time. But since the context here is a NAS usage, there's a max 1gbps upstream/downstream in the first place so you could comfortably do a 4 drive mirror NAS off of this and not have any bottlenecks on the USB 3.0 -> SATA side of things.
Does it use ECC memory? If not, you should not use ZFS. Without ECC memory, ZFS carries the nasty risk of writing good data with a bad checksum, leading to data loss which would not occur in other filesystems (those that do not try to correct errors on the fly like ZFS).
Only difference is that other filesystems may have better tools to rescue damaged filesystem after metadata is corrupted.
Edit: To add on to this, ZFS doesn't do parity-based repair at the checksum level. In the mentioned case (good data, bad checksum) no copy of the block will match the checksum and there will be no supposedly-good block to copy over.
> There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
[0] https://arstechnica.com/civis/viewtopic.php?p=26303271#p2630...
Ooooo, I hadn't heard about that one. I have one non-ECC box running ZFS where I might want to enable this. If the performance impact is negligible, it'd be worth trying.
Assuming a memory error somewhere:
On ZFS you'd be writing bad data with a bad checksum, which would be caught by ZFS later on.
On (most) other filesystems you'd be writing bad data and no checksum, and you'd be none the wiser until garbage comes back.
It's a myth that ZFS requires ECC memory; ZFS is safer when running with ECC, but without ECC it will still save your data in a lot of places where most other filesystems won't.
See https://www.reddit.com/r/zfs/comments/7ng231/does_a_zfs_mirr... for a bunch of links on this.
A guide: https://wiki.freebsd.org/ZFSTuningGuide
Though as you have the 3b+, then you have none of that dilemma and it will just boot, done it myself.