mrlambchop

Hear hear. I've explored the old USSR via youtubers like bald and bankrupt and various urban explorer channels (and of course, the amazing HBO/Sky show, chernobyl) but I would love something as digestible based on older computing systems from Russia and beyond. Just yesterday, an urban exploration channel found a bunch of abandoned computers in a bunker that I could not find a single reference to on the internet (and that looked fairly intact).

Well, this just listed out my concerns pretty well and I spent the last hour installing this on my devices. Specifically, how do I explain to a fortune 500 IT department how this is secure in a few simple sentences?

Love the write up. OSHPark PCBs - wondering how many revisions it took to get that keyboard layout working! I'd love an 8bit era keyboard and case that you can plug your own PCB into - I'm itching to design something from scratch but I know what will happen if I need to do a full cycle design process - eventual apathy :(

I am legitimately curious to see if you believe that the PI is suited to actual industrial applications in terms of its reliability (filesystem etc...) and low cost design? Maybe I'm defining industrial as something a lot more PLC based vs something akin to 'monitor the temperature in the warehouse' of course - when I hear industrial, I immediately think steel mills or manufacturing plants.

I would strongly hesitate to recommend the Pi for anything situation where 99% reliability (or above) was required unless I understood the domain back to front and could cover all the failure cases such as the expected operating environment ranges (temperature, power quality, EMI etc...).

From experimentation with recent Mercedes and BMW, its encrypted, although I do recall that early X5's were not protected.

I assume it (a) actually functions as a cable that can charge a phone (b) can enumerate on the USB A connection as various types of slave (such as network adapter or storage device) and use this to bridge into the computer (c) enabled connections to the cable Wi-Fi from a phone as a means to control or monitor the cables activities.

I initially thought this might be used to hack into phones via the lightening or USB ports, but the security on these devices is pretty good. It seems less likely that an exploit of this value would be put into cables like this. I still worry about plugging my phone into random hotel or transport USB charge ports however... I should pick up a USB condom I guess!

@ryanmarsh - any chance of a link for this? in the market and I can't tell the wheat from the chaff on Amazon.

There are a lot of interns working at the company! IDK much about Norway - is that the name for a graduate?

I assume the micro itself is not developed by them given the team size - even with 1 guy looking after this, we're looking at a factor of 30+ in terms of effort to develop, test and certify this type of IC

"a sinking ship raises all boats"

Humor aside, I prefer to subscribe to the Harry Potter ear worm and make sure everyone is aware of it and is comfortable to reach out at any time:

"Help will always be given at Hogwarts, Harry, to those who ask for it"

The fact that the windows and doors were compared against bullets and sledge hammers seems a marketing stunt. The specs for the materials are no doubt from the requirement "make trucks extremely rugged".

As a "coastal techie" (I completely stole this from another thread, but so apt...), I put down 100$ to be part of the ride. Somewhat because I skipped the model S and 3 reservations but also, damn, even to be in the first 10k delivery of this truck will be a wild ride - my young kids would never forget the experience if Tesla pulls this off and Telsa manages such a brutal design but casually delivered as one of the production vehicles.

Oh, I'm sending it back to be looked at. The hat that comes with the picade doesn't have space for a heatsink or fan under it (as the instructions are put together to assemble it) so I'm also suspecting that its early doors for the Pi4 and picade still.

Having recently built a picade with a Pi4 and ran it in a cool room for around 2 hours, the device kept crashing when playing various emulators. After the final crash, it didn't start up again. Opening up the back was like opening the door to an oven and the Pi4 was just steaming. Nothing was obviously melted, but it didn't work again :(

Yubikey's use the standard keyboard USB driver so they should be hot pluggable on any linux system that is configured to enable hotplug.

A great read. For those interested in NBC News Documentary "The Tunnel" that filmed the escape, it can be found here:

https://archives.nbclearn.com/portal/site/k-12/browse/?cueca...

Satire or not, I spent all day debugging very similar FCM issues, but under React Native. What looks like rate limiting can also be attributable to a wonky application lifecycle integration between RN/Android. What times we live in!

Guilty as charged. A program that did a <delay,print "RESET",delay> was enough (with a bit of execution timing) to show the examiner on the way into the hall that all was good.

The attention to detail really got to me however over time - the normal reset message was in lower case, but all the custom programs could print was in UPPER case. I was always "its sooo obvious - they'll find me out", when I saw RESET, but nobody ever clocked.

I never did use these notes or solvers in an exam - once I knew I had them, I would remember them anyway.

I'm looking forward to the tags. I hope they make something super small that can be snapped into a range of accessories such as dog collars or suitcase name tags (some first party, no doubt a ton third party to follow including some wonderful and crazy things like a message in a bottle). Once other peoples phones can find my things reliably, a lot of anxiety I have about things I tend to loose will go away (for a small price).

(I used to love Tile, but as a product we hit its technological peak several years ago and the network effect does not seem to improving this incrementally as much as it used to)

The Pi people are good folk - all that is needed is to run the USB 3 conformance tests and report back the results (both as USB PD sink and source). Better to know the knowns than have a enthusiastic fan base find them and we get into discussions like this!

I'd also recommend they put up a compatibility table of power supplies on their website in time - probably cables as well! Its a good opportunity to collaborate with the Google engineer who has been spending his non-core hours on the USB-C madness.

Expo released their support web (still in beta) at the start of the month, bringing react native + API extensions to iOS/Android + web.

https://blog.expo.io/expo-sdk-v33-0-0-is-now-available-52d1c...

Ignoring the user interface, having a single JS codebase for APIs, business logic and unit tests is pretty darn exciting IMO, especially with typescript support.

I believe fast boot relies on having a stable, on PCB storage device (eMMC or NAND) to ensure that the recovery method doesn't have any opportunity to get wiped / trashed. Using an SDCard doesn't ensure this and thus something in hardware would be needed instead.

A major product challenge of eMMC in a design is the requirement to supply a means of flashing data onto the storage device when the CPU can't boot from the eMMC (or the disk is corrupted).

The SDCard solves this problem fairly well (although the solution requires a reasonable level of computer literacy due to the filesystems and raw block device access needed, however its a good fit for the Pi user demographic).

Other systems solve this chicken/egg problem by having a tool that runs on a PC that can perform the programming of attached storage, often by downloading code and data into a CPUs RAM and then having it flash to the disk. Exposing JTAG to Pi customers however is a step too far and would require more expensive external JTAG hardware to be needed per customer as well.

If I was Pi, I'd put a 10cent USB stick IC onto the board that connects in parallel to the eMMC and enable the board to be plugged into any USB host and mounted as external storage. Some programmable logic (get one of the Silego 10cent programmable logic ICs) would be needed to prevent the USB from being mounted when the system was running - I'd probably add in a button or switch that is read at power on and determines which interface gets to see the eMMC. It would need to hold either the Pi chip or the USB IC in reset depending on which function was selected.

A second option would be to put an USB eMMC protocol stack into the BootROM, but this would need LittleKernel or something similar in the BootROM and its non-trivial to get right!

Its an incorrect statement - I think James on the Pi forum was confusing NAND vs eMMC.

eMMC has (with exception of some high grade SDCards) better write cycles and is considerably more durable than the average SDCard.

IIRC, there was a giant ruby backend and a web app that were both deployed in unison - made for a super janky app experience when it would require you to refresh the mobile app if a deploy occurred whilst you were in the middle of booking a moped (which BTW, I still love riding)

A totally naive point of view, but it would be awesome if some players in the maker space that are profitable (Adafruit, R-Pi, Arduino etc..) could band together and form a non-profit to keep this effort going. The maker community is generally so very non-corporate that I'd hope a partisan organization would be easy to form and run with out individual agendas or products getting involved in any overwhelming way.

The HVS was a cool design - the only real issue if I recall was its limited line buffers meaning it was hard to determine what could be composited in real time, so we ended up always rendering to a triple buffer. It also did some amazing scaling in realtime, but this came with some crazy artifacts that were super painful to triage. The occasional "flash of bad pixels" in a live composition screen was really painful. I just remember I wrote the DPI and CPI peripherals that we brought up the HVS with - on a 4MHz FPGA complex, we had YUV camera input scaling up to a WVGA DPI screen running at 60fps on a distributed FPGA platform through the HVS. Fun times.

I checked out Eric's work just - he's doing an amazing job! Much more thought put into the subject (security for GLSL being a huge topic on its own). The lack of MMU in the VC4 architecture is a huge pain point that probably sucks up most engineering cycles when it comes to arbitrary application environments using GPU resources like X11 or Wayland - when memory runs out, what to do? You can throw engineering resources at it, but engineering talent really needs access to VMCS on the VideoCore side todo any worth while work.

When we ported Android to the VC4 architecture the first time (~2010), the low memory killer in Linux was subverted to understand to kill Android applications based on their use of the VideoCore GPU memory and it worked pretty well, yet it would still close the primary running app once in a while. Run monkey over Android and all hell broke loose - really tough situations to defensively code fore. For example, for CX reasons, you had to ignore some GLES errors in the primary client due to low memory, then the system had to kill another application that was using the memory, then it would kill the EGL context for the primary application so it would refresh the entire app lifecycle using an almost suspect code path inside Android. Good times! Imagine Wayload has very similar challenges for normal desktop use.

Woah - a huge flash to the past when I read this.

I ported Wayland to VideoCore4 (the multimedia engine in first Pi chip) back in 2011 - it was part of the Meltemi Nokia project that got cancelled the follow year - shame as it was pretty cool and had half a chance IMO. We worked with the team in Oslo on QT acceleration over GL ES and used EGL below Wayland (coupled with some magic APIs to get the VideoCore HVS to work well). Ported this to an ARM combo chip that had just the VideoCore GPU in it as well (no HVS) - it worked pretty well.

Prior to this however, I made a VideoCore demo that used a PCI bridge chip (from Broadcom) and you could plug it into a Dell laptop running Ubuntu and get accelerated video decode and also X11 window scaling working at 60fps. We nearly sold this into Apple for accelerating their macbook's but IIRC, getting the macbook into low power mode whilst the video was playing on the external chip was going to be soo much work that they gave up.

A even further back, I remember validating the HVS hardware block and writing the initial scaler driver for it (IIRC, scaler.c...) and made a dispman2 port for the driver. Circa 2006!

Great team - one of the most enjoyable set of people to work with I've ever come across.

On the surface, this looks more positive to QCOM. However, I feel a good long term play for APPL would be to negotiate a cap on royalties for all LTE shipments through litigation like this, then fade in their own silicon in some developing markets whilst keeping their eye on 5G deployments using modems from the best vendor(s).

My 2 cents.

This was an amazing sunday night rabbit hole to go down - thanks!