More than 4 years since my latest update... how time flies.
No new beta build for Windows, but on the experimental2 branch of the tilibs repository, among other things, libti* now have initial support for a currently undetermined subset of the CX II series (at least OS 5.0.0.1509 and 5.2.0.771 work)
That was after receiving a report ( https://github.com/debrouxl/tilp_and_gfm/issues/33#issuecomment-1712845038 ) that the CX II can speak the NavNet protocol ("NSP", in libticalcs parlance) used by all older Nspire models, after switching it to the alternate USB configuration. In the default configuration, it speaks NNSE, which is a variant of NavNet wrapped with new headers and using UDP checksums. NNSE remains unimplemented in libticalcs.

There have been efforts porting the NumWorks firmware to other platforms, e.g. the HP Prime, by none other than Jean-Baptiste Boric

The NumWorks series uses XIP on NOR Flash memory, like the TI-Z80, TI-68k, TI-eZ80 series and other models I'm less familiar with. The N0100 and N0110 models both have only 256 KB of RAM, while NumWorks' Epsilon firmware is ~900 KB nowadays (the N0100's meager 1 MB Flash is close to be full, and even though it's possible, few users attempt to solder an external 8 or 16 MB NOR Flash chip onto the appropriate area of the N0100's PCB), and the Omega fork containing xcas (khicas) is probably like 3-4 MB.
Larger Flash memories are NAND, and NAND Flash needs to be read on a page basis, which makes it unsuitable for direct code execution.
Unlike the TI-Z80, TI-68k and TI-eZ80 series (at least), the NOR Flash of the N0100 (internal + external if that is populated) / N0110 (both internal and external are populated and used out of the box) is accessible at a high rate, ~100 MHz. No speed-destroying wait states necessary on the N0100, possibly one on the N0110 whose CPU is clocked at a rate twice higher.

The TI-Z80, TI-68k and TI-eZ80 series simply weren't designed with security in mind. The Nspire series' design is more security-oriented, but it fails time and again to prevent users from executing arbitrary native code on the whole series (including the CX II, this has been public knowledge for months at this point). The only graphing calculator which could be locked down fairly strongly (secure boot scheme) by the manufacturer, but currently isn't locked down, is the HP Prime G2. Even that could technically fall to vulnerabilities in the firmware, but people don't try to attack it that way, precisely because HP's not trying to prevent users from doing whatever they want with the calculators they own.
You're right about TI-eZ80 user rage, which will end badly for TI - they have far more to lose than users

QuoteIn TI-BASIC, ASM and C you can create games that takes up to 3 MB of memory and I believe with ICE it's 64 KB. Does python even come close?

Nah, with that ~16 KB Python heap, you're limited to the ridiculously tiny value of several KB of source code. It varies somewhat depending on what the source code contains, since the internal representation of some entities is smaller than others.
TI's proprietary, non-portable functions can fetch image data from files, but that doesn't fix the heap size limitations.

Due to the architecture used by the 83PCE EP and undoubtedly the upcoming 84+CE PE, namely an underpowered processor and a very underpowered coprocessor communicating through a slow link, some types of programs are ridiculously slow on TI's models: https://ti-pla.net/t23812 .
However, the usage of line and sprite functions makes it possible to create faster, if non-portable programs: https://ti-pla.net/t23824 .

Working a bit on libti*/gfm/tilp once in a while, I need to spend more time on the matter, but at the moment, I'm dealing with a set of 1990s or early 2000s PCs. I've had these motherboards lying around for nearly a decade, ever since I picked them up while cleaning up my previous job's work place and brought them home several months later.
I knew most of these motherboards were broken, indeed they are, but I've found 6 computers in working state so far. There could probably have been at least 7 if I had taken care of the leaking RTC batteries in 2010-2011: in the summer of 2010, one of the computers used to work.

BTW, is the domain name paid for another year / couple years ?

I have produced another build, available from https://tiplanet.org/beta/tilp2-setup.exe as usual. The main change from the previous build is the initial support for CBL / CBR / CBR2 / CBL2 / LabPro (/ TI-Presenter, hopefully) probing; also, I have greatly expanded the functionality and scriptability of the test_ticalcs_2 CLI tool, which is helping me a lot making tests, and packaged it in the TILP installer.
Not that in itself, the lab equipment support will be useful to many people, especially in this state, but it would be great if other people could help check that the support for other models has not regressed

The implementation of even this reduced support for older lab equipment was much more complex and time-consuming than I originally imagined. The newest of those lab equipments implement the version DBUS command, so it's easy to detect them, but the CBL, CBR and CBR2 don't. For those, and for meaningfully communicating with the CBL2 and LabPro as well anyway, an equivalent of the Send and Get TI-Basic commands is required. On the wire, those use an area of the DBUS protocol which was basically undocumented in the linkguide (which I've read for the first time in years, and I don't maintain), and unimplemented in libticalcs, so I'm not sure it was reverse-engineered before. TIEmu and TilEm's support for communicating with real calculators through cables, thanks to the libti* stack, were invaluable in gathering traces of the emulated calc <-> lab equipment communication

The commit adding lab equipment communication and expanding test_ticalcs_2 currently makes the code base grow by over 3K raw lines of code + test scripts (see https://github.com/debrouxl/tilibs/tree/experimental2/libticalcs/trunk/tests for those) + build definitions. Yet, I only implemented support for the computer faking a TI-68k calculator; depending on the calculator model, the TI-Z80 series probably uses at least two variants of another protocol, as I saw two different formats for floating-point numbers. Also, I only implemented support for exchanging lists, wheras scalar expressions, indexed access in lists and matrices, sometimes strings and even pictures are supported for Get in most or some conditions... and even the list parser is simplistic: no support for spaces around '{', ',' and '}', no support for '.' (effectively restricting lists to integer values).
The fact that there's no portable, thread-safe way to parse strings containing floating-point numbers with a decimal point hard-coded to '.' - that's what the lab equipment sends to TI-68k calculators - is very annoying. At work, for that same purpose, I used a non-portable and probably thread-safe solution based on creating a new instance of the C locale and using strtod_l(), because it's in a code base which only targets Linux... but I can't do that here. The function names are different on Windows, which can be worked around, but then there are all of the other *nix that libti* support...

Uh, looks like I missed your reply here... sorry. I need to check whether I'm subscribed to the topic.
* yup, TILP can communicate with the TI-85 through SilverLink and transfer variables in a non-silent way. Not much else, the 82/85 protocol is the oldest and most limited implementation of DBUS;
* in the GTK+ runtime installer, did you check the "install compatibility DLLs" (or somesuch message) checkbox ? I always do, as IIRC, it's required.

I've just produced a new version of the Windows installer, https://tiplanet.org/beta/tilp2-setup.exe . I haven't tested it on a real Windows install. The aforementioned changes, and more, are available

It's been a looong time since I posted in the various forums' TILP beta-testing topics... In the meantime, a number of things occurred, even if as usual, few are really user-visible
I'll have to produce a Windows build when the CX II series' handling is usable.

Among the changes:

• Adriweb added the definitions necessary for building libti* with CMake, I merged those, and the same for TILP, which I haven't merged because I'm focusing mostly on libti* ^^;
• the TI-eZ80 ROM dumper was improved, then fixed, by jacobly;
• I worked a lot on the TI-68k ROM dumper:
• fixing huge bugs in the 92 / 92 II handling code: not only I broke dirlist during a refactor, but most of all, the 92 / 92 II ROM dumper has been corrupting dumped data since 2005 at best (the code was already wrong at the time of the libticalcs 1 -> 2 switch) by destroying 8 KB of data in order to get coherent dumps on the certificate memory are... yeah, but it doesn't exist on these models ;
• multiple optimisation rounds in C, before switching to pure ASM in order to optimize more, of course, but most of all be able to get rid of the dependency on a C compiler targeting the m68k. Indeed, GCC4TI's old, heavily patched m68k-coff, which doesn't work correctly when compiled with newer compilers, isn't a future-proof solution at all, and neither is Debian's standard m68k-elf, which proves to be way too buggy to be usable... One of the end results of that work will be to make the TI-68k ROM dumper unconditionally buildable by Debian, since Debian packages all of the build dependencies. In order to achieve this, I had to be creative for producing a binary in the quite peculiar Fargo II format.
• I implemented an event system in libticables and libticalcs, which, combined with the packet dissectors I rewrote / need to finish for libticalcs, will yield much better packet dissection functionality, but also new functionality;
• in order to benefit from stricter typing and later from a better standard library, I switched libti*'s code to C++, even though of course, I kept the external API pure C;
• I fixed quite a bit more issues reported by the Coverity static analyzer, I had previously made other fixing rounds;
• I added the initial support for two additional models:
• Nspire Lab Cradle / Datatracker Cradle: untested, but we know that these behave largely like Nspires;
• Nspire CX II: they are detected at a USB level, but for now, handled like Nspire, which is very wrong. The protocol they're using is very different from that of other Nspires (there's a wrapper on top of a modified NavNet version), but seemingly the same as the NWB's, i.e. classroom equipment for handling multiple calculators remotely. This protocol had never been reverse-engineered.
• TI-eZ80 calculators featuring "Python On Board" capability are now reported by libticalcs - i.e. the 83PCE EP. Thanks Adriweb for giving me information

Also, I used previous packaging work on OBS by Fabian "Vogtinator" Vogt for development versions of libti*/gfm/tilp, the result (completely untested !) is available from https://build.opensuse.org/project/show/home:debrouxl:TILP .

Next up:

• proper handling of the CX II family, using their "new" protocol. I had started the RE work, but I hadn't found the exact checksum algorithm - which Fabian, who now has a CX II, found this week, using other methods. We're going to be able to make forward progress.
  
• modifying several existing commits (for instance, the DBUS dissector, which is relatively early in the stack of commits on the experimental2 branch, isn't filled in yet), and making additional tests;
• later: initial CBL2 handling, at least detecting and reflashing the OS. We've bought one, it reached home yesterday;
• the TILP II 1.19 + associated libs release, between two and three years after TILP II 1.18 - all these changes make there's ample reason for a release;
• unofficial Debian/Ubuntu packaging on OBS: for now, there's only openSUSE and Fedora.

The entire content at https://symbolibre.org/ , be it the about summary https://symbolibre.org/en/the-project/ or the news items, has now been translated to English

Over the past few days, the word has started spreading about a ~university project of a team of 25 French students working part-time for several months, which yielded the Symbolibre graphing calculator effort, based on modern, cheap hardware components and
open source / libre software
I'm not involved in that project, I'm just relaying news. To date, most information about the Symbolibre remains written in French, AFAICT.

It's based on a $5 RPi Zero module without networking capabilities (not a "W" model), which brings hardware characteristics previously unheard of on a graphing calculator: 1 GHz ARM CPU, 512 MB of RAM + e.g. 8 GB of Flash (well, whatever one puts inside the internal SD card slot). Only the Prime G2 isn't completely dwarfed by this. The screen is 320x240, like all other graphing calculators with ""high-resolution"" screens.
On the software front, unsurprisingly, it's running Linux, and therefore, it enjoys the widest collection of user-space programs, including giac/xcas, a full-blown Python implementation with a full-featured IDE, etc. There's a screenshot taken on a computer, so it looks like there's a computer version of the software.
They used 3D printing for the case and also keyboard buttons, though their pictures don't show the keyboard buttons.

The best aspect, and it's not surprising, is that the Bill of Materials, detailed in at least one of the topics linked below, amounts to around 80€ in the current setup, and can be decreased by using other power circuits... yes, 80€ is just about the (commercial) price tag of a TI-83 Premium CE or a NumWorks calculator, both of which have immensely weaker hardware characteristics.
Technically, the Symbolibre has much more raw power than needed to run the cores of CEmu, the NumWorks simulator, TilEm and TIEmu, though the input (keyboard...) and UI might be less obvious. Firebird should work, but I'm not sure about full speed emulation of a CX, let alone a CX II in the future.

In France, there's (fortunately) no official list of calculators allowed for the main standardized tests, and as long as the SD card slot is not user-accessible during an exam without opening the case (it isn't), such a calculator probably wouldn't run afoul of stupid standardized testing constraints, especially if a blinking LED is added. This requirement of an exam mode with blinking LED was supposed to be enacted last year, after a 3-year notification period, but it wasn't, because unsurprisingly, many pupils still only had working, but older, models without exam mode.

One of the students is an administrator at Planète Casio; two of the TI-Planet admins (critor and Bisam) met the team and saw the calculators for themselves on April 3rd and 4th. The project was publicly showcased at the ~university on April 4th.
The students' plan is to keep developing the project as time permits, of course. And judging by the interest the project is generating, they might receive external contributors, like NumWorks

Official site: https://symbolibre.org/
Forum topics in other calculator communities: https://www.planet-casio.com/Fr/forums/lecture_sujet.php?id=15667 , https://ti-pla.net/t22470 , http://www.hpmuseum.org/forum/thread-12726.html .

Yeah, a filesystem would be a must.
ELF, not so much, however. It's inefficient for embedded platforms, that's why Ndless-based programs have never switched to it after the initial phase of a custom, lightweight program format which required manual relocation.

Simply put, if you want to run a 84+ program, get yourself a 84+, or use an emulator on your computer: TilEm-NG is usually considered one of the most accurate ones

The monochrome 84+ and the color 84+CE are very different platforms: different processor, different memory layout, etc. Assembly programs and FlashApps written for one of these platforms will simply not work for the other platform. Nobody wrote a monochrome 84+ emulator for the 83PCE / 84+CE(-T). It's not that nobody knows how to emulate a 84+, but the thing is, making an emulator is a lot of work, and making it work on such a relatively underpowered platform as the 84+CE is even more work. The 84+CE is not much more powerful than the 84+.

Nope, installing Ndless is clearly not known to void the warranty
And yes, it's hard to conceive that such misbehaviour can be produced purely by software.

Switching Android from Linux to Fuchsia is apparently far from trivial, according to Kees Cook this summer (2018/07/28) on ##linux-hardened. I'm not aware of a no-logs policy on that chan, so straight from my logs:

Quote[18:48:21 CEST] <xtrWrithe>   hello, im using this kernel, it comes with grsec? or i will need to patch it manually?
[20:04:37 CEST] <Lionel_Debroux>   linux-hardened does not come with PaX/grsecurity.
[20:05:24 CEST] <Lionel_Debroux>   There used to be minipli's unofficial forward port of grsecurity to newer Linux 4.9 stable versions, but that stopped when KPTI was integrated to mainline: mixing the broad KPTI changes with MEMORY_UDEREF and KERNEXEC was too much, too hard work, IIUC.
[20:22:57 CEST] <xtrWrithe>   Lionel_Debroux: ty for reply, yes i saw that the other port is dapper's one, but as you say KPTI made it very hard to keep working and the 4.13 versiom doesnt work yet
[20:23:38 CEST] <xtrWrithe>   what should i focus on to prevent kernel exploits or at least mitiagte them a bit?
[20:37:45 CEST] <Lionel_Debroux>   smeso reimplemented something like MPROTECT, and several other protections, in the SARA LSM... but LSMs still aren't stackable, and on the anti-exploitation front, nothing comes remotely close to grsecurity.
[20:37:59 CEST] <Lionel_Debroux>   Individuals are out of luck, they can't buy grsecurity subscriptions on their own.
[20:39:55 CEST] <Lionel_Debroux>   If you're part of a small company, and can convince those who decide (or are one of the deciders and it doesn't cost too much), maybe you can become a customer of Open Source Security, Inc.
[20:41:54 CEST] <Lionel_Debroux>   If you're part of a large company... you're probably out of luck as well, as the subscription probably won't be very cheap, and making those who have the power to decide on such bills - and are usually of the dumb financial type - understand the value of grsecurity, no matter how huge it is, is usually a hopeless task.
[20:51:01 CEST] <Lionel_Debroux>   In the longer term... IIUC, Android's going to switch to a completely different kernel implementation with a Linux compatibility layer. Microsoft used the same approach for Win10's WSL.
[21:49:16 CEST] <kees>   Lionel_Debroux: Android leaving Linux is somewhere between "never" and "in decades maybe"
[21:49:44 CEST] <kees>   xtrWrithe: I recommend the latest upstream kernel, and the recommended settings linked from the /topic
[21:49:51 CEST] <kees>   (if you can't find a way to use grsecurity)
[21:53:26 CEST] <Lionel_Debroux>   You know the topic better than I do, but... that far in the future, really ? Why ?
[21:53:54 CEST] <kees>   Lionel_Debroux: because changing a kernel is hard.
[21:54:03 CEST] <Lionel_Debroux>   AFAIK, many Android apps, especially those written in higher-level languages, do not have strong dependencies on Linux.
[21:54:32 CEST] <kees>   Lionel_Debroux: true, but the system integrity is tightly bound to Linux (e.g. SELinux)
[21:55:05 CEST] <kees>   Lionel_Debroux: now, what I'd expect is for that kind of thing to happen in VERY small devices where memory and CPU resources are the tight spot
[21:55:29 CEST] <kees>   but on phones... multi-core CPUs, gigs of RAM, I really think it'll stay Linux for a long long time
[21:57:56 CEST] <Lionel_Debroux>   Yeah, Linux on very small devices is a lost cause. The tinification efforts weren't deemed useful enough (by the powers that be) to offset the (sometimes small, IIUC) maintenance increase.
[21:58:32 CEST] <Lionel_Debroux>   Higher performance and better compatibility are deemed more important than smaller footprint... or better security.
[22:00:29 CEST] <Lionel_Debroux>   It's the first time I'm reading "the system integrity is tightly bound to Linux (e.g. SELinux)" argument, which is indeed a good technical reason why moving away from the Linux kernel for some usages can be hard.

And agreed, Fuchsia should be able to manage to be part of our world for a while.