I loved Nokia's Linux phones, and bought several of them. I drove to New York (from Boston) twice to get an N900 as early as possible. But I wonder what they would have had to do to make that line of phones a mass-market success. Users of the N900 had root privilege. Can you imagine a support nightmare that would have been for T-Mobile et al.? To sell Linux phones to the general public, I think they would have had to lock down the OS to the point that it resembled what Android is today.
Most of the Windows CE phones of that era (pre-Windows Phone 7) were also basically "rooted" - i.e. you could install any .CAB and there was nothing stopping you. But Linux is a real operating system and Windows CE is basically on the same level as Windows 95 from an architecture standpoint.
A friend of mine worked at a cell phone repair shop and it was fairly common for someone to bring in their bulky keyboard-slideout HTC PDA that had frozen and typically the only recourse was a "hard reset" - reverting the phone to factory settings and removing all stored data (which was in the MB those days). Of course WinMo on most PDAs of the time was quite capable of keeling over all by itself without the aid of third-party programs, so the user couldn't always be blamed.
Got forbid the user of a device they have bought is in control!
That woul be the end of the world, you could not push downgrades, like Samsung remotely disabling bootloader unlock or Bamboolab forcing all your 3D models through their cloud service.
The horror! They could even remove all your unskippable adds and disable all the spying, gross!
Don't forget the N950! It was an aluminum body successor to the N900, with a glorious slide-out keyboard. Built like a tank. They were never released for sale to the public, perhaps because Nokia's leadership had already decided to kill its line of Linux phones. But I've got one.
reads an instruction from x, increments the PC to x+2, then decrements the PC back to x and reads the same instruction, then decrements it again to x-2 and writes it, then it executes from x-2 ......
I've read this paper several times, over the years, and I've never understood why its considered such a landmark. I think it could be losslessly compressed to one paragraph of modest length.
Many people (e.g., Daniel Dennett, myself) think it's a terrible paper that has done a huge amount of damage. Unfortunately, that too makes it a landmark. Likewise for Searle's Chinese Room argument and Chalmers' "hard problem" as discussed in "The Conscious Mind" and elsewhere.
I had an old astronomy app I wrote for pre-iPhone app store era Nokia phones (N900 etc.). I decided to get Claude code recreate it as an Android app. The old app produced several display pages for things like the positions of the planets. I was having Claude code recreate the app display page by display page, describing the display that should be produced, with no reference at all to the original app's code (or even its existence). After having it reproduce several pages, it added another one unprompted. The page it added was in the original app, but I had not gotten around to adding it to the Android app. The Nokia app's code is still on github, and somehow Claude must have made a connection between what I was asking it to code (without ever mentioning the Nokia app) and my github repository's Nokia code. It correctly implemented the page without me even mentioning the missing page. My jaw hit the floor.
It's not an automated process (at least in my case). I primarily use Codex so I will do the initial pass with 5.3 or 5.4 xhigh and then cleanup with spark on medium or low.
Spark is great for this kind of cleanup work because the feedback loop is so tight compared to just about anything else. It's quite hampered by a very small context window but in the context of cleanup/refactoring that's more of a feature than a bug IMHO.
My suggestion for folks that want to do this is make sure you keep reasoning low. The cleanup should be very much human directed and derived from your "taste", at that point you don't want the model to think at all and just blindly do what you tell it to. You want reasoning to be just high enough so it doesn't eff up the code in the process.
Testing wasn't really the issue with the loss of the two shuttles. In both cases, it was mostly a management issue. For Challenger NASA had seen o-ring erosion in earlier launches, and decided it was not a big risk to the crew. Then they launched Challenger against the recommendations of the engineers in charge of o-ring seals. For Columbia, they has seen foam strikes in earlier launches, but since they had not caused catastrophe in the past, they decided that foam strikes were acceptable. Even when it was clear that a large foam strike had occurred on the launch of Columbia, management wasn't concerned enough to try to get ground-based images of the shuttle to check for damage. Could Columbia's crew have been saved had they known the extent of the damage? No one can say of course, but not even trying to do everything possible was inexcusable.
This probably signals the beginning of the end for OpenAI. Eventually all of the AI chatbots will have Ads at least on the free and low-cost tiers. But there's a strong incentive not to begin enshitification until the number of competitors has dwindled, and an oligarchy has been established. Google, Meta et al. can afford to lose money on AI for a long time, because they have real revenue from other business products; they can stay Ad free until the small-fry go bust.
Also, if your Android phone is a Pixel, you can run the recently added Terminal app, which runs a plain vanilla Debian distribution within a VM. So you then have a pocketable Linux machine to develop code on. Not only does Python run on it, you can install the entire Anaconda Python suite.
I tried this a while back with. NET and Blazor. With split screen I was able to add some code and preview live in the browser and build and 'install' a simple pwa.
Presumably with an external monitor and the desktop mode it would be better.
Code from tiny llms such as Gemma are a waste of time but it "worked". It was neat to generate a working app completely offline.
The main problem was that the VM crashed on my pixel fairly frequently. Might be better by now.
Because, wonderful as Termux is, it has a very nonstandard filesystem layout, so installation scripts for something like Anaconda will not run without extensive modifications. And Termux has no access to /proc, /dev etc., so lots of utilities fail. Since Terminal provides a full Linux VM, all programs that will run on Linux just work as expected.
I haven't noticed anything like that. Some more obscure tools have trouble with the file system but that happens in ordinary Linux too. Though I have no experience with Anaconda specifically so you likely know better whether it'll need adaptations to work under Termux.
I run htop just fine on my handhelds and I'm pretty sure it sources directly from /proc, /sys or something.
Termux can access the full file system if you have root access, which is how I play around with it; however, running a VM is a safer and easier route, especially as smartphone manufacturers are making it tougher to root the device you own.
Wow, that’s cool! I wonder whether one day Apple is going to allow something like this with headless “macOS” VM on iPadOS to make it a viable local development platform.
