How To Deal With Your Raspberry Spy — Part IV: Doing The Task

Posted in BSD, GNU/Linux, Hardware, Kernel at 7:59 pm by Guest Editorial Team

By Gavin L. Rebeiro




1 Acknowledgements

2 Introduction

2.1 Prerequisite Knowledge
2.2 Apparatus

3 Fundamentals

3.1 Communication
3.2 Kernel Ring Buffer
3.3 Drivers
3.4 Operating Systems
3.5 Special Files

4 YOU ARE HERE ☞ Doing The Task

4.1 Preparing The Boot Media
4.2 Connecting Physical Components
4.3 Using Picocom
4.4 OS Installation

5 Thanks

6 OpenPGP Key

A Malicious Hardware

B Linux Kernel Source Tree Analysis

C Digital Multimeter Tests

Summary: We now spell out the steps taken to actually replace the Raspberry Pi OS with something more trustworthy (for background see Part I, Part II, and Part III)

We’ve now covered enough ground to make the installation of
NetBSD on our Raspberry Spy (over our UTUB) a relatively painless matter.

Let’s go through the process in little steps.

4.1 Preparing The Boot Media

I’m going to grab the appropriate NetBSD image by taking hints from the following:

NetBSD/evbarm on Raspberry Pi tells us everything we need to know to pick the right image. All the sections here related to booting are worth reading at least once. Also read sections about consoles and serial consoles at least once.

Raspberry Pi boot modes is useful if you want to dig deeper into the booting mechanisms of the Raspberry Spy. USB mass storage boot is particularly useful for booting off USB. Trust me, you don’t want to muck around with SD cards; they’re a nightmare.

NetBSD/evbarm can be referenced for general information about NetBSD on ARM boards.

The above links should give you a good idea of what’s going on and what needs to be done with regards to putting a NetBSD on a boot media that goes into a Raspberry Spy.

Let’s go through a concrete example.

My Raspberry Spy is of the model “3 B+” variety so I’m dealing with an ARM64 CPU architecture. We’ll follow along the instructions outlined in Installation procedure for NetBSD/evbarm; pay close attention to the section “NetBSD/evbarm subdirectory structure”; I follow these instructions as I explore Index of pub/NetBSD/NetBSD-9.1/evbarm-aarch64/.

I grab the appropriate image like so:

$ mkdir ~/Downloads/netbsd
$ cd ~/Downloads/minted
$ wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/evb c
 → arm-aarch64/binary/gzimg/arm64.img.gz

Now that we’ve got the image, we can write it to our boot media. I’m going to assume you have an appropriate reader already plugged into your GNU/Linux box. I’ve got my USB thumb drive as “/dev/sdg” on my system. Use the right block device file on your system1. We base our procedure along the lines of “Installation for ARMv7 and AArch64 devices with U-Boot” section from Installation procedure for NetBSD/evbarm:

$ gzip --decompress --keep arm64.img.gz
# dd if=arm64.img of=/dev/sdg bs=1M conv=sync
 → status=progress
$ lsblk -f | grep sdg

We’re going to ignore the minutiae of writing to block devices, bootloaders, and other adjacent topics related to the utilities we just used; that’s left for another time. We care about learning how to use a serial console in this project so we must stay focused on our primary target.

We’re going to have a look at how to make a serial install possible via some editing of the “cmdline.txt” file that now resides in the boot media (on the boot partition which is of type “vfat”):

# mkdir /media/netbsd_image
# mount /dev/sdg1 /media/netbsd_image
# grep "console" < cmdline.txt
# root=ld0a console=fb
# grep "enable_uart" < config.txt
# enable_uart=1

The “console=fb” part is to get out OS image to use the HDMI output. We will get rid of that string from the file “cmdline.txt”. Who needs that anyway? One way to do it2:

# ed cmdline.txt
root=ld0a console=fb
root=ld0a console=fb
# echo ",p" | ed cmdline.txt

Remember to check your edits!

We also ensure that “enable_uart=1” is set in the file “config.txt”:

# echo ",p" | ed config.txt

Everything looks good! Additional useful information on the Raspberry Spy UART can be found in UART configuration. Pretty self-explanatory. That wasn’t so hard. Was it? Note that the following links document the files we’ve been messing around with:

The Kernel Command Line

It’s a good idea to back up the state of your image, at this point3. We can now safely unmount our boot media and get on with the project:

# cd ~
# umount /media/netbsd_image

We change directory, before we unmount, so that we don’t get any “device busy” errors.

We’ve now got our boot media ready. Onwards!

4.2 Connecting Physical Components

Before you power up your UTUB, you should really check that the pins are working properly. The very basic test you should do is to check that the right voltage is being supplied. Check out Appendix C.

The pins on our UTUB and Raspberry Spy that we’re interested are the following:

• Raspberry Spy: Pin6 (Ground), Pin8 (GPIO14, TXD), Pin10 (GPIO15, RXD). You can find the layout in the official GPIO page.

• UTUB: I’ve got a CP2104 UTUB so I’ve got to only worry about the pins marked TX, RX, and GND. I have other pins on the module but they’re not relevant for this task.

We won’t be using any of the voltage pins on the boards because it’s more prone to errors. Just use the USB power supply that comes with your Raspberry Spy.

Don’t plug anything into power for the following sequence. Connect the jump-wires like so:

• Ground on UTUB to Ground (Pin6) on Raspberry Spy.

• TX on UTUB to RX (Pin10) on Raspbery Spy.

• RX on UTUB to TX on (Pin8) Raspberry Spy.

“We won’t be using any of the voltage pins on the boards because it’s more prone to errors.”Don’t make the rookie mistake of matching TX with TX and RX with RX; TX always goes to RX and RX always goes to TX. Keep this in mind, always, when working with UARTs. Colour-coding your jump-wires helps.

We’ll just go over the order of attaching the stuff to do with power on our devices:

• Attach the USB power adapter to the Raspberry Pi without plugging the adapter into the power outlet.

• Attach the UTUB to your GNU/Linux box.

• Attach your USB power adapter to your power outlet.

The logic for the above procedure is that you can ensure that your serial interface is up and running before you start getting input from your Raspberry Spy.

4.3 Using Picocom

Using picocom(1) is simple. All we need to do is select the correct baud rate and give the right device file as a parameter to picocom(1).

I’ll give you an extract from the manual page to enlighten you:

In effect, picocom is not an "emulator" per-se. It is a
simple program that opens, configures, manages a serial
port (tty device) and its settings, and connects to it
the terminal emulator you are, most likely, already
→ using
(the terminal window application, xterm, rxvt, system
console, etc).
When picocom starts it opens the tty (serial port)
given as its non-option argument. Unless the
--noinit option is given, it configures the port to
the settings specified by the option-arguments (or
to some default settings), and sets it to "raw"
mode. If --noinit is given, the initialization and
configuration is skipped; the port is just opened.
Following this, if standard input is a tty, picocom
sets the tty to raw mode. Then it goes in a loop
where it listens for input from stdin, or from the
serial port. Input from the serial port is copied
to the standard output while input from the standard
input is copied to the serial port. Picocom also
scans its input stream for a user-specified control
character, called the escape character (being by
default C-a). If the escape character is seen, then
instead of sending it to the serial-device, the
program enters "command mode" and waits for the next
character (which is called the "function
character"). Depending on the value of the function
character, picocom performs one of the operations
described in the COMMANDS section below.

We use “C-a C-x” (Ctrl+a followed by Ctrl+x)4 to tell picocom(1) to exit; for more, RTFM; in particular, pay close attention to the “COMMANDS” section.

Make sure you’ve set up all the physical connections, as advised. It’s time to attach our UTUB to our GNU/Linux box and then make sure we invoke picocom(1) correctly:

# picocom --baud 115200 /dev/ttyUSB0
picocom v3.1

port is         : /dev/ttyUSB0
flowcontrol     : none
baudrate is     : 115200
parity is       : none
databits are    : 8
stopbits are    : 1
escape is       : C-a
local echo is   : no
noinit is       : no
noreset is      : no
hangup is       : no
nolock is       : no
send_cmd is     : sz -vv
receive_cmd is  : rz -vv -E
imap is         : 
omap is         :
emap is         : crcrlf,delbs
logfile is      : none
initstring      : none
exit_after is   : not set
exit is         : no

Type [C-a] [C-h] to see available commands
Terminal ready

It really is that simple. You’ve now got a serial terminal ready and listening.

4.4 OS Installation

Now that you’ve got a serial terminal operational, all we have to do to install NetBSD on the Raspberry Spy is to plug the USB power adapter into the power outlet. Keep a close eye on what goes on in the output of your serial terminal:

[   7.4246937] root device:
[  11.6252523] use one of: mue0 sd0[a-p] ddb halt reboot
[  11.6252523] root device: sd0
[  13.9755661] dump device (default sd0b):
[  15.7257992] file system (default generic):

You should be promoted to pick a root device. I pick “sd0” as it’s the first ’disk’ offered by NetBSD (which can only be my boot media)5. I go for the suggested defaults, for everything else. No need to overcomplicate things, at this point.

You will probably see your Raspberry Spy reboot once or twice during the OS install process. Just pass the same parameters for the boot device, and you should be good to go.

Eventually, you should be met with the following:

NetBSD/evbarm (arm64) (constty)


If you login as “root”, you should have a nice login shell presented to you.

And we are done! You’ve successfully done some tinkering over a serial terminal. That wasn’t so hard. Was it? You can shutdown your device (halt the OS) like so:

# shutdown -p now
[   910.5814809] The operating system has halted.
[   910.5814809] Please press any key to reboot.

You can now disconnect the power supply from your Raspberry Spy. Then just send “C-a C-x” to picocom(1); after which, you should see:

Thanks for using picocom

Welcome to the world of serial terminals; hack your heart out!
1 The command lsblk -f should help you out here. Don’t wipe the wrong device by accident.
2 If you use another text editor, that’s fine. You really should learn ed(1) at some point though, especially if you want to get into embedded systems.
3 At least keep track of the files that you tweaked. If you use some sort of version-control-system, you get bonus points.
4 I don’t know why the manual doesn’t bother to explicitly mention that these are GNU-Emacs-style key sequences.
5 See the NetBSD sd(4) manpage for details.


How To Deal With Your Raspberry Spy — Part II: Introduction

Posted in Free/Libre Software, GNU/Linux, Hardware at 9:01 pm by Guest Editorial Team

By Gavin L. Rebeiro




1 Acknowledgements

2 YOU ARE HERE ☞ Introduction

2.1 Prerequisite Knowledge
2.2 Apparatus

3 Fundamentals

3.1 Communication
3.2 Kernel Ring Buffer
3.3 Drivers
3.4 Operating Systems
3.5 Special Files

4 Doing The Task

4.1 Preparing The Boot Media
4.2 Connecting Physical Components
4.3 Using Picocom
4.4 OS Installation

5 Thanks

6 OpenPGP Key

A Malicious Hardware

B Linux Kernel Source Tree Analysis

C Digital Multimeter Tests

Summary: Following Part I, published a few hours ago, let’s examine what happened from a technical perspective and what can be done about it technically

We don’t want to be spied on; what happens when we’re faced with an operating system that spies on people? We throw it in the trash where it belongs! I am boycotting the Raspberry Spy myself (you’re free to join me in doing so) but I don’t want people to waste hardware that they already have. So we’re going to walk through an interesting path of installing a different operating system on the Raspberry Spy; I want to show you a few things that will empower you to take greater control over your computing.

We’ll gently walk through and explore the following: how to install an operating system on an embedded device (a Raspberry Spy, in this case) over a USB-to-UART bridge (UTUB). This is the main project we’ve got on our hands. Don’t worry if you’ve never touched embedded systems before; everything here is accessible to people with a modest set of prerequisite knowledge and some basic apparatus.

We’ll delve into things with more depth as we move forward with our project; if you don’t understand something when you first encounter it, just keep reading.

2.1 Prerequisite Knowledge

There’s not much prerequisite knowledge required. Here’s what you need to know:

• A basic grasp of how to operate a shell on a GNU/Linux system. GNU Bash is an example. You don’t need to know how to write shell scripts. Knowledge of how to use the shell interactively will suffice.

That’s it. Really. Anything else you need you will pick up on the way.

2.2 Apparatus

You will need the following apparatus:

• A Raspberry Spy. I’ve got the Raspberry Spy Model 3 B+ so that’s what I’ll be using in this project.

• A working Internet connection.

• A USB thumb drive (used as boot media) for the Raspberry Spy.1

• A power supply for the Raspberry Spy.

• A USB-to-UART bridge (UTUB). I’ve got a CP2104 from Silicon Labs; this is widely available and you can pick it up from an online retailer. You want a module that has all the necessary pins and peripherals already packaged into one, neat, unit. I believe the specific module I have is by WINGONEER.

• 3 female-to-female jump wires.

• A computer with any recent GNU/Linux installed on it. The computer needs to have a working USB port.

• A generic microSD card reader/writer. I have an Anker AR200.

It’s likely that you already have the apparatus to operate your Raspberry Spy. Just acquire the additional bits that you don’t already have. The list here is just for completeness.

Here’s some extra equipment that will make your life easier:

• When you’re dealing with electronics, you should heed the old idiom of “two is one and one is none”. Get spares of whatever you can, as a rule.

• A digital multimeter (DMM) with spare fuses for the multimeter. Being able to do some quality control (QC) before you hook up your UTUB to your hardware is going to give you peace of mind. Don’t skimp on the spare fuses for the DMM; it’s easy to forget how much current you’ve got flowing through a circuit and fry the DMM’s fuse by accident2.

• A 2M or longer USB extension cable. Male-to-female is what you want here. You plug in the male part to your computer and the female part is open for receiving the UTUB. This makes life a lot easier (and safer).

• Nitrile gloves. Helps keep you safe.

• Safety goggles. Again, doesn’t hurt to be careful.

You should now have everything you need to get started!
1 If you’ve got a Raspberry Spy that can only accept an SD card as boot media, you don’t need to fret too much. The procedure is the same; you just write the OS image to an SD card instead of a USB thumb drive. Fixing quirks of SD card installations are, however, out of scope of this project; you should refer to the relevant documentation, IRC chats, and mailing lists. I will provide links to boot-media-specific information, when we discuss boot media; this should give you a starting point to troubleshoot issues.
2 Real fuses were harmed during the making of this document.


Raspberry Pied in the Face — Part V: Raspberry Bye? The Lost of Trust is Pervasive and the (Un)Official Response Unhelpful

Posted in GNU/Linux, Hardware, Microsoft at 7:59 am by Dr. Roy Schestowitz

Video download link

Summary: The perception that the Raspberry Pi is compromised (by Microsoft) is hurting all the momentum (and reputation) it has built for nearly a decade; we heard from developers close to these affairs

THE media coverage about the blunder has entered its second week (we broke the story more than a week ago) and this morning we found several more articles about it, never mind comments and social control media. The Foundation hoped that the anger would die out just because queries from the community and from customers were being censored. This is a case of bad judgment on top of bad judgment.

Remember that the Foundation works with various GNU/Linux developers and projects, including Debian Developers. One of them wrote about Pi images only hours ago. We too spoke to some developers. They lost faith or lost truth in the Foundation. Much damage has been done by working with Microsoft behind their backs. “Microsoft repos installed on all Raspberry Pis,” one developer told us, asking: “have you seen the news about the Raspberry Pi Foundation forcibly and without notice installing a Microsoft repo in all machines running Raspberry Pi OS? Here’s more context. This implies that at every update you are pinging Microsoft’s servers, and as the repo is PGP-signed by the developers, Raspberry Pi OS users can unadvertedly install Microsoft software, pull it as a dependency or even having it installed in an update. This is a tremendous breach of trust for millions of users and an attack by Microsoft, IMO. Also, in a typical corporate dictatorship style, the critics in the Raspberry Pi forums were quickly censored for “Microsoft bashing”.”

“Remember that the Foundation works with various GNU/Linux developers and projects, including Debian developers.”“I know about this,” I responded, “because we (Techrights) are the ones who actually broke the story.” (We are also being credited at the site raspbian.io … in the front page)

It is clear, based on what we’ve heard, that many developers are pissed off, even partners. They feel betrayed. The breach of trust impacts not only customers (Pi users).

One reader told us that it’s “awesome that TLG [The Linux Gamer] showed Techrights, about that Pi OS maintainer snooping in the Microsoft repo/gpg key… reading a thread about it also, the maintainers said that won’t change, and it’s to make sure life is easy for those wanting to install vscode… sounds like money talking, to me! Wouldn’t be surprised if Microsoft aren’t a major sponsor (similar to Google/Firefox), or a total buyout announcement on the cards.”

They already tried, several years ago in fact, to put Windows on the Pi (we wrote several articles about it back then and again several days ago… in prior parts of this series).

“It is clear, based on what we’ve heard, that many developers are pissed off, even partners.”It’s a travesty because the Foundation betrayed users, customers, media, developers, strategic partners, and even hardware suppliers (there’s a whole chain of extensions for Pi devices). It would likely be the end of the Pi ‘monopoly’ as they have many competitors now (some with the word “Pi” in their name). People would vote with their wallets and we heard of some who started exploring alternatives. Was it worth it for the Foundation? Microsoft has ideas…

We’ve also just received some truly disturbing E-mails related to this. It seems like this series will end up being a lot longer than we first anticipated, so we might split it apart into other (separate) series.

“Trojan horses are not really gifts, even if they come with ribbons and a greeting card that says “Microsoft loves Linux”…”“And with the way this has been mishandled by both Microsoft and RPF,” an associate told us a few days ago, “there is even less reason to trust Microsoft. A question with a very interesting answer would be, why the offending software was not added to the official repositories and in the right category? The category “main” is not the right one.”

Some Debian Developers are really unhappy about this. It damages the reputation of their project/s as well. But Microsoft is of course just trying to interfere with GNU/Linux from the inside (pacifying or demonising opponents by claiming that it “loves” them) — same thing it always did to undermine and kill rivals. Latest target? It seems to be this. Not the first time, either. Trojan horses are not really gifts, even if they come with ribbons and a greeting card that says “Microsoft loves Linux”… (that greeting card is just a gate opener)


Raspberry Pied in the Face — Part IV: Poor Crisis Management by the Raspberry Pi Foundation

Posted in Free/Libre Software, GNU/Linux, Hardware, Microsoft at 7:37 am by Dr. Roy Schestowitz

Video download link

Summary: The Raspberry Pi Foundation did a really awful job handling its so-called ‘community’, which it ended up insulting instead of apologising to

THE thugs from Microsoft (a "cult", according to former insiders) are ruining Raspberry Pis and the Raspberry Pi Foundation. As usual, it’s about money. We know who always ends up on top.

Incredibly damaged hardwareIn Part I, Part II, and in Part III we covered as slowly as possible the known facts, seeing that the media does a really lousy job, unless its sole job is spin and clickbait.

“They (RPT and RPF) can definitely recover from this,” an associate told us (the one who was first to discover and report this blunder), “but only if they put in massive effort to do so. The longer they wait the harder it becomes. If they wait long enough, then at some point it will become impossible.”

“Raspberry Pi OS has turned into spyware for M$,” one developer wrote. “This isn’t the first time that the #RaspberryPi Foundation changed your sources.list without asking…”

Noteworthy is this bit from another person: “Raspbian(.org) was started by Mike Thompson (long gone) and DD ‘plugwash’, who is still maintaining the archive which provides most packages for #RPi, after all these years.”

The incident alluded to is described as follows: “JFC. If you want to have Bluetooth on your #RPi (3B+) device you apparently ‘need’ to install the pi-bluetooth package, which requires the raspberrypi-sys-mods package which rewrites your /etc/apt/sources.list! Without asking.”

“Microsoft trolls and apologists abound,” an associate told us about comment threads such as these and less than a day ago we saw full-time Microsoft propagandists publishing puff pieces in the media (about this incident, but spun completely for marketing purposes).

Whatever others say, even if they’re salaried by Microsoft to say that, all we can do is repeatedly highlight verifiable facts.

$ sudo apt source raspberrypi-sys-mods 
Reading package lists... Done
E: Unable to find a source package for raspberrypi-sys-mods

What was done by the Raspberry Pi employee/s is truly mischievous not just because it’s Microsoft but because of how it was done. They had planned this for a while and we guess there’s a Microsoft deal (of some kind) they don’t wish to talk about. Because they keep totally silent (the Raspberry Pi team has not collectively issued any statement).

“Some people whom we spoke to had started looking into Raspberry Pi alternatives (many exist).”“In case you [are] still looking for how [this] gets on the rpi,” one reader told us the other day, “it comes with “Setting up raspberrypi-sys-mods” package; the corresponding commit can be found here: https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/655cad5aee6457b94fc2336b1ff3c1104ccb4351 [It] Is even worse than you described, because it adds also /etc/apt/trusted.gpg.d/microsoft.gpg and comes back with every update.”

Although it may be device- and region-dependent, it seems like silently the Raspberry Pi team worked to clean up the mess by basically hiding it.

“This is not the outcome we hoped for when breaking this story, but the handling of the blunder was really poor and bodes badly for the Foundation. It resorted to Stalinist censorship in its own forums and it even insulted those whom it had injured (words like “Microsoft bashing” only inflame them).”Mogz was really unhappy about those shady practices. “I agree,” she said, “seeing plenty of people saying about switching distro … the maintainer’s determination, despite that, says a lot; they and Microsoft should urgently and actively be cut off, for sure. At least linuxers are having a strong reminder that Microsoft doesn’t love linux/privacy, so further news should get an even more attentive reception.”

We’re far from done with this series. The Microsoft deal — whatever its nature might be — is still there. There needs to be a statement from the people responsible for it. Microsoft has already collected a lot of data and tarnished the reputation of the Raspberry Pi. Some people whom we spoke to had started looking into Raspberry Pi alternatives (many exist). This is not the outcome we hoped for when breaking this story, but the handling of the blunder was really poor and bodes badly for the Foundation. It resorted to Stalinist censorship in its own forums and it even insulted those whom it had injured (words like “Microsoft bashing” only inflame them).

Techrights Gemini Site (‘Capsule’)

Posted in GNU/Linux, Hardware, Microsoft, Site News at 5:49 am by Dr. Roy Schestowitz

Video download link

Summary: We’ll soon have Techrights available over the Gemini protocol, which is light and elegant (and also enjoys fast-growing support)

THERE are many perfectly legitimate reasons to abandon the Web and the Web browsers that the Web is tied into. The Web is nowadays a chaotic mix of DRM, proprietary JavaScript you’re not allowed to disable (otherwise, you won’t be allowed to access many sites), and endless surveillance that goes beyond JavaScript (e.g. log files sold in retail quantities to so-called “data brokers”, sometimes by ISPs).

“It is understandable that many people won’t want to explore Gemini, having become accustomed to sites and Web browsers that they know, as well as processes they’ve long become familiar with.”We recognise the growing “Web fatigue” because we too share this fatigue. Last year, owing to lock-downs, we had spare time to work towards IPFS (“dweb” and censorship resistance) and now we’re working on a Gemini capsule for this Web site. The aim is to make it as rich an experience as the Web version.

It is understandable that many people won’t want to explore Gemini, having become accustomed to sites and Web browsers that they know, as well as processes they’ve long become familiar with. Gemini is actually not difficult at all to use (or even to set up; I’ve found that a lot simpler than setting up a Web site/server). Below we include the introductory part from Wikipedia and the above video explains what we’ve done so far (not much is left to complete before going “live”).

Gemini in Wikipedia


Raspberry Pied in the Face — Part III: Eben Upton’s Response and Its Significance

Posted in Deception, GNU/Linux, Hardware, Microsoft at 12:32 pm by Dr. Roy Schestowitz

Video download link

Summary: The founder of the “Pi” could tackle (and should have tackled) the issue swiftly and with great determination; sadly, however, his early reaction suggests passivity and a miscalculation of the harm caused

IN Part I and in Part II we explained there was no rush or urgency covering this issue, as new information emerges over time. We put accuracy first. There has been too much speculation, which was exploited by Microsoft apologists to insult the critics (e.g. “Microsoft bashing”).

What we’re planning to do is, we’ll present one chunk of facts each day for at least a week. The following “Twitter RPI thread,” as a reader put it, shows the founder of the whole thing responding to the scandal when it was still rather young (5 days ago). Maybe back then they thought the whole blunder would just go away and “age gracefully” within a day or two, at most (we keep track of some media coverage in this page; it’s still in the news this morning).

The tweet does not show us a worrying/worried Microsoft apologist (the video above says more about that), as we don’t suppose he cares much for Microsoft personally, but judging by context, he underplays the severity of what was done, maybe even behind his own back.

Eben Upton

“Sorry,” he said, “I can’t understand why you think this was a controversial thing to do.”

It doesn’t sound like this troubles him; he’s even defending what they did, even though we thought (or hoped) he’d be the one to get them out of this mess. We broke this story a week ago. Better responses would have been something along the lines of, “we’re going to look into how that happened, investigate, etc etc…”

“I gather he has not made a statement for more than a few days,” an associate of ours noted. “So his position in that statement might (hopefully) be outdated. [Either way,] Twitter is blocked by JavaScript.” (Since December)

“I presume he’s in massive denial about making a mess of things. Whoever was behind the decision to allow microsofters into RPT and RPF set this up and cost him massively in the area of reputation. It will be very, very hard to earn it back especially with the unapologetic denial. It’s to early to say what the economic impact will be for RPT and RPF but it will be felt on top of Brexit. They probably have just lost far more than the paltry >= 500k that Microsoft bribed them with.”

The source of that figure will become more apparent later in this series. We’re still verifying a number of things.

One noteworthy comment:

“£500,000 – £999,999″


I would be very surprised if there was not both a non-disparagement clause and a non-disclosure agreement or other similar limitations attached to the money; didn’t Microsoft Frontpage used to have a license prohibiting its use in making web pages critical of Microsoft?
see: http://www.microsoftvolumelicensing.com/userights/Downloader.aspx?DocumentId=1095 scan for ‘disparage’

“The discussion about Microsoft attack on RPF seems to focus on gathering information for possible advertising purposes,” our associate said, having been scanning a large number of online comments. “That’s lame. Microsoft use to have the EDGI programme to assault institutions that were found to not be using Microsoft products or considering abandoning them. The real danger is that Microsoft uses the geolocation data to identify institutions to attack. Advertising is the least of the worries that the tracking can incur.”

We also don’t know how the inclusion of a repository can extend (as in “E.E.E”) into something yet worse over time.

“After almost a decade of gaining trust,” to quote someone from Hacker News, “Raspbian has now lost a huge amount in a single bad decision. It’s yet even clear they even understand the depth of the mistake.”

We’ve seen people very angry about this, even people who did not themselves buy and use such a device. The change in question can be traced back to someone from XECDesign, who certainly did not follow proper procedures and practices. The way this was done was technically shady and “whoever this microsofter’s supervisor is, plus whoever signed off on the deal itself, all need to go,” one reader told us. If there’s someone who probably has enough clout to do this on the spot, it is Eben Upton. Hence the importance of the otherwise-meaningless tweet. It doesn’t seem he has the courage to address the blunder ‘head-on’.


Raspberry Pied in the Face — Part II: Raspberry Pi Foundation in Violation of GNU/Linux Rules (Because of Microsoft)

Posted in Debian, Free/Libre Software, GNU/Linux, Hardware, Microsoft at 7:26 am by Dr. Roy Schestowitz

Video download link

Summary: The blunder that harms the reputation of the Raspberry Pi (to appease or to serve Microsoft objectives like the ones we saw at Intel) is far from over; some have only just found out about it and they’re as mad as hell

AS WE noted in Part I, which was mostly introductory, we had spent the past week (almost a whole week!) researching verifiable facts rather than hearsay about our findings regarding the relationship between Microsoft and the Raspberry Pi Foundation. We actually broke the story, but almost nobody in the media gives us credit/attribution. Some unknown incognitos even removed links to Techrights (in Wikipedia articles about this very serious scandal), so maybe there’s some large-scale face-saving PR campaign.

“Many of us have Raspberry Pi devices and we can no longer trust system updates.”This morning someone sent us this new Lunduke video (also here) and latest among several stories about it in SoylentNews (a site which, to its credit, respects Techrights and habitually links to Techrights). We reposted (embedded) the Lunduke video because unlike some shallow puff pieces and self-serving Canonical spin it does not seek to underplay the severity of this cautionary tale. It cautions us about trust. Many of us have Raspberry Pi devices and we can no longer trust system updates. The Microsoft “implant” was nefariously packaged as if the clear goal was to hide it, to basically conceal what they had done. We’ll explain the technical details later in this series.

“By not including any source for their packaged attack,” one associate told us, “RPF seems it might have moved in violation of the guidelines / rules for ‘main’…”

“Lunduke and I share the view that the Raspberry Pi Foundation needs to issue a massive apology.”Some Debian developers, we are being told, are already angered by this. There is still no official word (statement or announcement) from the Raspberry Pi Foundation. Nothing. To make matters worse, there were efforts to gag their very own customers. Not cool…

Lunduke and I share the view that the Raspberry Pi Foundation needs to issue a massive apology. Even that alone would be insufficient. In Part III we’ll look at some of the technical aspects and the contractual obligations we suspect to have led to this blunder. This isn’t just some ‘accident’; there’s more to this story than the Raspberry Pi Foundation wants us to believe. They gaslight us. Who are the customers? Us or Microsoft?


Raspberry Pied in the Face — Part I: What is Known About the Relationship Between Microsoft and the Raspberry Pi Foundation

Posted in Deception, GNU/Linux, Hardware, Microsoft at 5:43 pm by Dr. Roy Schestowitz

Last week: Microsoft is Like a Cult, According to Former Microsoft Insider

Bill Gates Pied in the Face

Summary: The backlash against the Raspberry Pi Foundation is growing, not only from customers but also developers and partners; we’ll try to explain what happened and why, based on verifiable information rather than hypotheses, face-saving PR, and mindless gossip

AS PROMISED, we’re still drilling deep into the facts surrounding a scandal that even Microsoft sites now weigh in on. This article is not an extensive or exhaustive list of references (most do not even cite the original source, which is us, and in Wikipedia people keep removing links to Techrights, sometimes replacing those links with links to Microsoft sites). “Microsoft bashing” is the new term for opposing serial abusers.

“Readers are encouraged to send us additional information; the research has thus far been collaborative as it helps get the pertinent facts right…”As a little bit of background, the Raspberry Pi Foundation was already ‘targeted’ by Microsoft several years ago (they tried to shoehorn Windows into the Raspberry Pi, causing backlash if not fury in the Raspberry Pi community; we wrote about this at the time, e.g. [1, 2]). Last year we outlined the Microsoft modus operandi as follows (in relation to many companies, not the Raspberry Pi Foundation). To quote the core part:

a. Partner with a company (“we’ll pay you for every version sold”).

b. Get a close look at their original work.

c. Then bring out a ‘free’ version with Windows (“oh, we were just working on something similar”).

Tomorrow, in part two, we’ll share our findings, which are based on extensive research (including input from readers and people in IRC). There’s quite a lot to say and show, so we’ve decided to turn this into a series, whose length is unknown at this point. We’ll also make use of video, so it’ll take longer to produce. The objective is to produce at least one part per day for at least one week. Readers are encouraged to send us additional information; the research has thus far been collaborative as it helps get the pertinent facts right (there’s some more raw information in our IRC logs). We’re not a fake community, we’re a real community with a strong sense of trust among those who value truth. That’s why we’ve been targeted for years (with threats and smear campaigns). That’s why there have even been attempts to incite RMS against us lately, albeit those attempts fell flat on their face. RMS speaks to Mr. Raspberry Pi about moving further towards software and hardware freedom; Microsoft must really, really hate that.

« Previous entries Next Page » Next Page »

RSS 64x64RSS Feed: subscribe to the RSS feed for regular updates

Home iconSite Wiki: You can improve this site by helping the extension of the site's content

Home iconSite Home: Background about the site and some key features in the front page

Chat iconIRC Channels: Come and chat with us in real time

New to This Site? Here Are Some Introductory Resources




Samba logo

We support

End software patents


GNU project


EFF bloggers

Comcast is Blocktastic? SavetheInternet.com

Recent Posts