Slashdot Mirror
Raspbian Linux OS Gets Major Update, Adds Bluetooth Support to Pi 3 (betanews.com)
An anonymous reader writes: The Raspberry Pi 3 was launched with built-in chip for Bluetooth and Wi-Fi support, however, software support for Bluetooth was lacking until now. The drivers were there, but today's update to the Raspbian Linux distribution adds much-needed GUI tools to help you establish Bluetooth connections. Another cool addition is a new backup tool. There are other improvements as well including the mouse settings, and the ability to empty the wastebasket through right-clicking as seen below (yes, seriously). There is even a new shutdown dialog, something even casual users should notice.Official blog post here.
After reading the summary, Raspberry Pi 3 gets no update at all, it's Raspbian OS that gets the update.
Been using Ubuntu Mate with Bluetooth for my keyboard since I got it months ago.
In other 'news' - Windows 10 can be downloaded for free.......
Self Defense - A Human Right www.a-human-right.com
I thought the RPI was a tiny little ARM computer that you could do embedded stuff with.
The aim was to be a computer that kids could treat as their own and experiment on.
Plently of people used them to do embedded stuff with but that wasn't the primary goal.
Now it's got its own, distinct UI?
Yeah, stock LXDE carried them through the first few years but more recently they have decided to start customising things.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Long explains the refreshingly simplistic "SD Card Copier".
"Long"?
Hey, editors, try reading what gets submitted to make sure context has not been lost.
systemd is Roko's Basilisk.
To be really pedantic it's about the stuff the raspberry pi foundation build on top of raspbian.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Only experimental ones, but here.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
No, Mike and I built Raspbian. The raspberry pi foundation then built their images from raspbian packages and their own customisations on top (just as prior to raspbian they had built images from Debian with their own customisations on top). Gradually the volume of customisations they apply has increased.
This article is entirely about customisations they apply on top of raspbian.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I also hope this is in their future plan, but rebuilding all package for 64bit will propably take a while.
To clarify
The arm cores on the Raspberry Pi 3 are 64-bit capable (it's a quad-core A53 cluster).
The core bus system and memory controller are limited to 1GB (it uses the upper bits as flags).
By default the firmware starts the arm cores in 32-bit mode. There is an option in config.txt to change this.
There is a small peice of arm-side init code that normally runs after the firmware brings the arm out of reset but before the kernel loads. This is 32-bit only but can be disabled by options in config.txt.
Community members have got a 64-bit kernel and u-boot working (u-boot replaces the functionality that was provided by the arm-side init code). AIUI it's still pretty experimental though.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Since the Pi3 only has 1GB of RAM on board, you don't really get a lot of benefit having a 64-bit kernel.
Actually you get quite a bit of advantage. The instruction set for 64 bit mode is quite a bit more efficient even when you're not doing 64 bit arithmetic, not least because there are twice as many registers. Code that can be optimised using the SIMD instructions also gets twice as many SIMD registers, which can make a big difference for many graphics, signal processing and mathematical tasks. Most floating point code will be more efficient in 64 bit mode too.
Furthermore the 64 bit address space is useful even with only 1GB of RAM since it allows you to mmap files that are bigger than 4GB. Programs like MongoDB mmap their database files and when running on 32 bit processors MongoDB actually limits processes to a total of 2GB of data in the database, irrespective of how small the working set is. With a 64 bit address space the limit goes from below typical storage sizes to far beyond any plausible storage you'll ever connect to a Pi.
If intelligent life is too complex to evolve on its own, who designed God?
The ODROID-C2 seems like a better machine.
I still want a RTC. I like having computers that can operate without being attached to the internet's apron strings. I once had a near nightmare situation whereas the clock was wrong on a computer that was sync'ing files. Never again.
I've been wanting a Raspberry Pi class device, but as much as I want one, I don't need one...I think.
https://www.youtube.com/c/BrendaEM
Or a crappy class 4 SD card.
The Debian ARM64 port is very new. When it was initially released, it was still missing several key components, including Mono, libvp8 (which means no node.js), Go, and Rust. Debian unstable is a little better, but still has a number of missing packages that simply don't build or don't run properly on ARM64 yet.
As for faster instruction execution, that's nice, as long as the larger pointer size doesn't cause more cache misses. Which in turn, depends on the sort of data structures your code uses. Vectors and arrays are probably fine; lists and trees may be more problematic.
Bottom line, it's not as bad as OP claimed, but not quite as rosy as you paint it. I'd certainly like to see a 64-bit option, but I'm willing to be patient for a bit while they work out more kinks. Heck ARM64 support in gcc itself is still fairly new; I'm not sure how good the optimization is yet. Probably still has some catching up to do, compared to widely-used architectures like x86-64.
Look, I like Rasbian and have run it since my first Raspberry 2+ years ago. But I had unexpected grief with the RPi3 -- I have an RPi2 that was up and running for months (I use a lipstick charger for UPS) and it takes all sorts of USB wifi dongles automagically. So I figure no trouble for the 3.
WRONG! No end of grief, nevermind the obscure pkg imports to wheezy and BRANCH=next kernel upgrades. Wifi would NOT work. Only when I did a fresh install of jessie was it seamless. This 73 MB apt-get didn't do much -- got me from 4.4.6-v7+ to .9 . Nothing like jessie to xenial or epiphany64 or java[script]64.
The image route may just be a stealth upgrade to jessie for most. Bury the wheezy bugs.
The most common cause is a weak or flaky power supply. MCM Electronics sells a nice 2.4 Amp supply for a 6 dollars.
http://www.mcmelectronics.com/...
I've got 6 of them and I've had zero power problems.
The fact that they run 64 bit doesn't mean it's all rosy. I remeber back when x86 went 64 bit it was quite a while before you could tell any real difference.
Yes, Debian ARM64 has already been released. That's why I said "when it was initially released." It's hard for something to have had its initial release if it hasn't been released. However, it still doesn't have all the packages that are available for most of its supported platforms. It's somewhere in the 96-98% range, last I checked. Plenty for embedded systems, but perhaps not ideal for a general purpose educational system.
For that matter, there's probably a version of Debian ARM64 available for the Pi. There's several OSes available for the Pi. However, the fact that Debian ARM64 is still not 100% may be part of the reason that Raspian isn't yet 64-bit. Or it may be because they want one distribution that will work on both older and newer Pis. I dunno. Just saying, it's not 100% yet.
As for faster instruction execution, that's nice, as long as the larger pointer size doesn't cause more cache misses. Which in turn, depends on the sort of data structures your code uses. Vectors and arrays are probably fine; lists and trees may be more problematic.
It helps if the language implementation is not so stupid as to store unencoded pointers on the heap when there's the option of storing them more efficiently. (Assuming the language itself isn't so stupid that it's the only thing it allows, as is the sad case of C. Then your only option is, e.g., jumping through hoops with DataDraw and the like.)
Ezekiel 23:20
You wouldn't believe what's ben happening with British computers. They have come a long way in the past 30 years. My last British computer was a ZX81 (pronounced "zed-ex-eighty-one"), and now this Raspberry Pi literally has a million times as much RAM. (OK, only 65536 times as much, because I had the 16K cartridge.) You don't need the tape cassette recorder as persistent storage anymore; it uses a microSD card. And yeah, it comes with a wastebasket. With the ZX81 you needed to provide your own wastebasket.
British computers are great for teaching kids to program. The Raspberry Pi pushes Python for development, but the ZX81 taught you BASIC. Then it taught you that you can actually read a BASIC program faster than a ZX81 can run it. As a result, the third thing you learned was Z80 assembly.
Both computers came with huge, detailed manuals. The British are really good at manuals- they're written in perfect English.
Yes. I'm currently using a Pi 3 as my secondary computer, it's as fast as I need. The primary one is a box from a recycler bought in about 2007 running Linux Mint. All this Linux malarkey would be really beneficial to materials use, energy use and recycling if it reached the mainstream. The accelerated product cycles are now part of commerce rather than part of something 'useful'.
On y va, qui mal y pense!
Make the os read only.
For people running Windows, there is no /boot/ directory, it's the root of the microSD card. That would have been useful to state.
Secondly it's a shame this isn't documented in a file on the microSD after you've done the image.
Thirdly and even more annoying, is that there is no sample wpa_supplicant.conf file ready for you to modify and rename.
It's a great idea - pity that wasn't fully thought through :(
Avantslash - View Slashdot cleanly on your mobile phone.
The VPU code is a blob but the arm-side code is open.
However there is indeed an issue, communication between the driver in the kernel and the VPU is broken with the current experimental 64-bit kernels because the system assumes a kernel pointer can fit in 32 bits. It's probablly possible to fix this from the arm side with some tricks though.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register