Banana Pi is working on the upcoming Banana Pi BPI-M7 SBC powered by Rockchip RK3588 SoC whose low profile design reminds me of boards from Khadas such as
The Banana Pi BPI-M7 single board computer is equipped with up to 32GB RAM and 128GB eMMC flash, and features an M.2 2280 socket for one NVMe SSD, three display interfaces (HDMI, USB-C, MIPI DSI), two camera connectors, dual 2.5GbE, WiFi 6 and Bluetooth 5.2, a few USB ports, and a 40-pin GPIO header for expansion.
What if you really hate the fact that The RPi foundation is being hostile against people nowadays with proprietary PCIe connectors, telemetry, requiring a custom flash tool to get SSH and whatnot?
Yes you can, but then without a display and keyboard you won’t be able to SSH into the thing right away. They’re using small tricks like that to push people into their tool and you’ll be seeing more of that crap in the future.
The workarounds are either using their tool or doing what you suggested. Other SBCs do the reasonable thing and have it enabled by default like the Pi did in the past. This change simply pushes less-proficient users into using their tool.
Having it enabled by default is a pretty massive security hole. I preordered the raspberry pi 1 when it launched and I don’t remember SSH ever being enabled be default in their images. Where did you hear it was enabled by default?
I preordered the raspberry pi 1 when it launched and I don’t remember SSH ever being enabled be default in their image
I was, I remember it being that way. They later on made it so you would be required to change the password after the first login.
Having it enabled by default is a pretty massive security hole.
Most people are running those in a home network that is isolated either way. Most people even share their entire hard drives on the network with little to no security and you’re telling me a Pi with SSH access enabled by default is a risk? Professional deployments will be done by people who know how to change the passwords, port and use keys. There’s no reason to consider that an issue because of those reasons.
They later on made it so you would be required to change the password after the first login.
That’s just good password security and reasonable.
Most people are running those in a home network that is isolated either way. Most people even share their entire hard drives on the network with little to no security and you’re telling me a Pi with SSH access enabled by default is a risk?
See that qualifying word there? “Most”? That’s why they force SSH to be disabled and password changes. If you PERSONALLY can guarantee that no one will EVER put a freshly imaged RPi directly on the internet backed by a 10 million dollar/pound/euro guarantee per incident it still doesn’t matter; there’s still a need to change these defaults. I’ve seen the RPi’s deployed in a business environment and I 10000% know that vendors are fscking stupid and would leave default permissions enabled because they’re the lowest bidder.
It’s people like you why we have massive botnets due to default security measures being ignored by major manufacturers.
On Raspberry Pi OS, ssh is disabled by default, so you’ll have to find a way to enable ssh + find the IP address + connect to it.
The workarounds are either using their tool and/or fiddling on the SD card. Other SBCs do the reasonable thing and have it enabled by default. This simply pushes people into using their tool.
The extra menu in the flasher does the magic on the sd-card. I’ve been setting up headless pi’s since before 3b came out, and the same options are available today.
The idea that ssh being enabled by default is reasonable is just like your opinion. Did you know you have to enable it during installation on both Debian and canonicals derivative? Maybe it’s still on by default on fedora (with root login enabled to help you!)
If editing your config is fiddling then I struggle to see your use of an sbc.
Did you know you have to enable it during installation on both Debian and canonicals derivative?
The difference is that Debian requires you to install with a screen/keyboard and/or use something generic like cloud-init not a proprietary tool that pushes people into telemetry and whatnot. Also a Pi is a lot less critical than a full system and almost always used by hobbyists. Professional users would change passwords / use keys so, yes, it makes absolutely no sense.
How is a pi (or other single-board computers) less critical than “a full system”? Do you have any idea how many pi’s are out there running serious stuff? Where I work I bump into them all over - including in security systems and door-access.
This one has two 2.5gb ports, 8 to 32gb ram. This is serious stuff for an sbc, clearly overkill for your pihole install. What’s not equally serious with banana pi is support. I went to their wiki, it lists Android and Debian (previous version) “images” but no download links, so it’s hard for me to verify that this board boots with sshd running or not. Like I said Debian does not, and for a good reason. Raspberry pi os pulls from raspbian, and they pull from Debian.
You can run Ubuntu LTS, fedora or others on your pi.
The telemetry is bad news - soon we will be out of food because someone knows what size of sd-cards you use, and the number of installs you do. So better go buys a silly board, track down some ancient image of an install someone did at some point where they managed to compile the nic drivers and include the binary blob. Because nobody gets to force you to add an empty file to your sd-card!
The Debian installer can be pre-seeded and be automated.
You can use cloud-init for non cloud installs but why would you?
Preseed or use fai and let your config system handle the rest.
I get that you love this board and think that “the establishment” is evil. But you come off as someone not having the knowledge to back your assumptions.
Sometimes this will be the right board, sometimes a Pi is better. And sometimes 2-3 microcontrollers are a better fit. But the choice should not be based on telemetry in an optional imager, or the fact that your headless setup requires editing of config files.
There’s definitely an argument for not supporting the Pi Foundation with their anti-consumer practices over the last few years. They’ve sold out to corporate interests and don’t give a shit about the educational/hobbyist mission of the original Raspberry Pi.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
What if you really hate support and ease of finding images online?
What if you really hate the fact that The RPi foundation is being hostile against people nowadays with proprietary PCIe connectors, telemetry, requiring a custom flash tool to get SSH and whatnot?
You can dd the iso without any problems.
Yes you can, but then without a display and keyboard you won’t be able to SSH into the thing right away. They’re using small tricks like that to push people into their tool and you’ll be seeing more of that crap in the future.
Don’t you just touch SSH in the /boot dir after you flash, then you can SSH in as pi and password raspberry?
The workarounds are either using their tool or doing what you suggested. Other SBCs do the reasonable thing and have it enabled by default like the Pi did in the past. This change simply pushes less-proficient users into using their tool.
Having it enabled by default is a pretty massive security hole. I preordered the raspberry pi 1 when it launched and I don’t remember SSH ever being enabled be default in their images. Where did you hear it was enabled by default?
I was, I remember it being that way. They later on made it so you would be required to change the password after the first login.
Most people are running those in a home network that is isolated either way. Most people even share their entire hard drives on the network with little to no security and you’re telling me a Pi with SSH access enabled by default is a risk? Professional deployments will be done by people who know how to change the passwords, port and use keys. There’s no reason to consider that an issue because of those reasons.
That’s just good password security and reasonable.
See that qualifying word there? “Most”? That’s why they force SSH to be disabled and password changes. If you PERSONALLY can guarantee that no one will EVER put a freshly imaged RPi directly on the internet backed by a 10 million dollar/pound/euro guarantee per incident it still doesn’t matter; there’s still a need to change these defaults. I’ve seen the RPi’s deployed in a business environment and I 10000% know that vendors are fscking stupid and would leave default permissions enabled because they’re the lowest bidder.
It’s people like you why we have massive botnets due to default security measures being ignored by major manufacturers.
Good day sir.
This is not true
https://roboticsbackend.com/enable-ssh-on-raspberry-pi-raspbian/
The workarounds are either using their tool and/or fiddling on the SD card. Other SBCs do the reasonable thing and have it enabled by default. This simply pushes people into using their tool.
The extra menu in the flasher does the magic on the sd-card. I’ve been setting up headless pi’s since before 3b came out, and the same options are available today.
The idea that ssh being enabled by default is reasonable is just like your opinion. Did you know you have to enable it during installation on both Debian and canonicals derivative? Maybe it’s still on by default on fedora (with root login enabled to help you!)
If editing your config is fiddling then I struggle to see your use of an sbc.
The difference is that Debian requires you to install with a screen/keyboard and/or use something generic like cloud-init not a proprietary tool that pushes people into telemetry and whatnot. Also a Pi is a lot less critical than a full system and almost always used by hobbyists. Professional users would change passwords / use keys so, yes, it makes absolutely no sense.
How is a pi (or other single-board computers) less critical than “a full system”? Do you have any idea how many pi’s are out there running serious stuff? Where I work I bump into them all over - including in security systems and door-access.
This one has two 2.5gb ports, 8 to 32gb ram. This is serious stuff for an sbc, clearly overkill for your pihole install. What’s not equally serious with banana pi is support. I went to their wiki, it lists Android and Debian (previous version) “images” but no download links, so it’s hard for me to verify that this board boots with sshd running or not. Like I said Debian does not, and for a good reason. Raspberry pi os pulls from raspbian, and they pull from Debian.
You can run Ubuntu LTS, fedora or others on your pi.
The telemetry is bad news - soon we will be out of food because someone knows what size of sd-cards you use, and the number of installs you do. So better go buys a silly board, track down some ancient image of an install someone did at some point where they managed to compile the nic drivers and include the binary blob. Because nobody gets to force you to add an empty file to your sd-card!
The Debian installer can be pre-seeded and be automated. You can use cloud-init for non cloud installs but why would you? Preseed or use fai and let your config system handle the rest.
I get that you love this board and think that “the establishment” is evil. But you come off as someone not having the knowledge to back your assumptions.
Sometimes this will be the right board, sometimes a Pi is better. And sometimes 2-3 microcontrollers are a better fit. But the choice should not be based on telemetry in an optional imager, or the fact that your headless setup requires editing of config files.
There’s definitely an argument for not supporting the Pi Foundation with their anti-consumer practices over the last few years. They’ve sold out to corporate interests and don’t give a shit about the educational/hobbyist mission of the original Raspberry Pi.