Building a fake bat­tery, adding a USB-C port, boot­ing from SD card, and giv­ing a new life to a clas­sic Linux smart­phone.

My friend Dima sent me his old-school clas­sic Nokia N900. The bat­tery is very old, and it does not boot as-is. So nat­u­rally, I wanted to see if I can res­ur­rect it.

Step 0: Is such a thing even pos­si­ble?

Yes it is! (Unless there are other hard­ware is­sues)

I did look at BL-5J bat­ter­ies for sale. Many list­ings say “Genuine” and “OEM”, but what does that even mean for a bat­tery for a de­vice that is at least 10 years old? (Some later Nokia Lumia phones used the same bat­tery) And list­ings with newer-look­ing bat­ter­ies do not list the man­u­fac­ture date. I don’t need an­other old bat­tery or a “spicy pil­low”.

Also, where’s the fun in that?

Cut and sol­dered a quick pro­to­type to con­nect in­stead of the bat­tery. Resistors are to em­u­late the “normal” tem­per­a­ture by pro­vid­ing ex­pected re­sis­tance be­tween the third pin and ground. See link above for de­tails.

Hooked up a large su­per­ca­pac­i­tor to the bat­tery pins and to a +5V source. If I re­call cor­rectly, us­ing a ca­pac­i­tor with­out ad­di­tional power did not work.

Now, let’s make some­thing that can fit into the bat­tery com­part­ment.

These su­per­ca­pac­i­tors are nice, but way too large. After search­ing on Mouser, I found FM0H473ZF, 47000 mF (0.047F) ca­pac­i­tors in a rec­tan­gu­lar case that is only 5mm thick.

Ten of these (~0.5F) is enough to run the smart­phone with­out dy­ing.

Capacitor con­trap­tion (TM) arranged (using a 3D-printed tem­plate) and sol­dered to­gether.

And they all fit nicely into the bat­tery com­part­ment. The power is pro­vided by a wire routed through the hole for the carry loop.

Running fine! One no­tice­able is­sue is that ca­pac­i­tors are get­ting pretty warm. Probably my sloppy sol­der­ing, but no shorts that I could find.

This is where I should have stopped. At some point while mess­ing with the “battery” and power, I man­aged to cor­rupt the in­ter­nal par­ti­tion and the in­stalled OS. Not sure if this was from the sud­den bat­tery pull or from sup­ply­ing +5V in­stead of the ex­pected +4.2V to the bat­tery pins. Luckily, newer Maemo Leste is in­tended to run from the SD card any­way, and in­ter­nal stor­age still works, so I was able to over­write it with the boot­loader.

I thought it might be prac­ti­cal to power the “battery” through the ex­ist­ing USB port. Just run the +5V wire from USB to the “battery”, and avoid ad­di­tional wires. (If you think this is kinda stu­pid, you are right)

Yooo… What is hap­pen­ing here? Dima says “oh yeah, the USB port was re-sol­dered. Twice”. A quick glance at the fo­rums also con­firms that USB port was poorly de­signed and is prone to break­ing.

Just one wire from the +5V pad to the “battery”. The ground is the same as the bat­tery pin.

Assembled every­thing back, routed and sol­dered the +5V wire, and added a diode to pre­vent the bat­tery from feed­ing the USB port, and to drop the volt­age to more ac­cept­able ~4.3V.

The setup works, but the smart­phone con­stantly shows ei­ther “Charging”, or “Device us­ing more power than it is re­ceiv­ing from the PC. Charging with a com­pat­i­ble charger is rec­om­mended”, with bat­tery gauge go­ing crazy.

And then, the power just cut out.

Yeah, this was not a great idea. Let’s see what hap­pened.

USB +5V wire de­tached it­self from the port. I pre­sume this is from ei­ther the high cur­rent, age, stress, or cor­ro­sion.

However, when I opened the smart­phone up, I… ripped off the +5V pad. (dark cir­cle in lower right on the photo)

After read­ing some N900 fo­rums, that +5V pad is a com­mon place to con­nect the re­place­ment USB port to (which was done here), but… that is the ONLY +5V con­nec­tion on the board be­sides the pads un­der the USB port it­self.

RIP Nokia N900. I tried to res­ur­rect you, but in­stead, I killed your OS and ripped out the USB port wires.

To be fair, N900 is far from dead. I al­ready flashed u-boot, was able to boot from SD card, and do not plan to use in­ter­nal stor­age oth­er­wise. Power can be sup­plied en­tirely through the new “battery”. So tech­ni­cally, I do not need the USB func­tion­al­ity for the smart­phone it­self, just to power the “battery”. At this point, I might as well re­place the port with USB-C. Because why not.

Approximate place­ment of the new USB port.

The lo­ca­tion of the orig­i­nal port is not very con­ve­nient. It is sand­wiched be­tween the main board and the SD card reader (lower left on the photo). SD card reader is also at­tached by a per­ma­nently-at­tached rib­bon (i.e. nearly ir­re­place­able).

First, I used a small file to make the mi­cro-USB-shaped hole on the smart­phone body fit the USB-C shape. Then, I took a small 6-pin USB-C port, cut and sanded down its plas­tic parts to make it fit in the orig­i­nal spot. It is still slightly (~0.25mm) taller than the orig­i­nal, but I can­not make it any slim­mer.

I tried to at­tach the USB-C port to the board in the cor­rect place by care­fully as­sem­bling the board, port and SD card reader into the body, and us­ing small drops of glue to lightly af­fix the edge of the USB port (that I could reach) to the main board. The in­tent was to wait for glue to cure, take every­thing back apart and glue the port in its now-cor­rect po­si­tion for good. This took sev­eral tries but did not re­ally work, as the port got de­tached while re­mov­ing the main board every time, and the the su­per­glue I used left lots of residue but did not ad­here. Luckily, the tight fit and the shape of the USB-C port hold it in place me­chan­i­cally quite well.

Originally, I planned to sol­der all 6 pins and add 5.1 Ohm pull-down re­sis­tors to CC1 and CC2 pins (for full power de­liv­ery func­tion­al­ity). But there is sim­ply not enough space to route the wires, the nar­row val­ley be­tween the chips (in the lower right of the photo) barely fits 3, and I did not have any­thing thin­ner on hand.

Since I did not sol­der the pull-down re­sis­tors, this USB-C port could only be pow­ered by a “dumb” USB-A-to-USB-C ca­ble, at de­fault 0.5A. Chargers with power de­liv­ery func­tion­al­ity can­not iden­tify such USB-C ports, and will not pro­vide power at all. (This is also an is­sue with some hand­held con­soles such as RGB30)

The two wires are routed to the bat­tery com­part­ment through a very con­ve­nient open­ing in the metal frame, crimped and in­serted into a DuPont con­nec­tor.

Back to the bat­tery. The ca­pac­i­tor con­trap­tion I built be­fore works, but was kind of flimsy, and does not have any more space for a DuPont con­nec­tor. Also, I would rather use a sin­gle ca­pac­i­tor, but it still has to fit. Since the orig­i­nal bat­tery is un­us­able, I might as well try to sal­vage it, too.

Take off the sticker (that tells you not to do so :). The top BCM piece is held to the main bat­tery body by two tiny screws (hidden un­der some crumbly com­pound) on each end, dou­ble-sided sticker, and a sin­gle lead in the mid­dle.

Battery Control Module. Interestingly, for this bat­tery, the body is the pos­i­tive ter­mi­nal. So the pos­i­tive lead con­nects the bat­tery body and the pos­i­tive pin di­rectly, while the neg­a­tive lead goes thor­ough some con­trol cir­cuitry. Attaching a ca­pac­i­tor to these bat­tery ter­mi­nals should be suf­fi­cient.

Since I have a 3D printer, and once you have one, every prob­lem can be solved by print­ing stuff, I printed the new “battery” to ac­com­mo­date a large ca­pac­i­tor, diode (for volt­age drop), wires, DuPont con­nec­tors, and the orig­i­nal bat­tery’s BCM.

N900 with a new “battery”. Fits re­ally tight, and only 0.25-0.5mm too tall, so the cover still snaps closed.

Boots with­out prob­lems. Since the at­tached ca­pac­i­tor is pretty large, it can take a minute or two to charge it to an ac­cept­able level (~4.0V) with a 0.5A cur­rent.

Nokia N900 en­joy­ing its new life as an on­line ra­dio de­vice us­ing Open Media Player.

Preamble: The whole af­fair is Google’s fault and not Bear Blog’s. Huge thanks to Herman—Bear Blog’s founder and dev—for his pa­tience and help.

A month af­ter I started my first Bear blog at blog.james-zhan.com, my blog was en­tirely de-in­dexed by Google for no ap­par­ent rea­son:

I have since mi­grated to jour­nal.james-zhan.com (you are on it right now) and redi­rected all links from blog.james-zhan.com ac­cord­ingly, but to this day, I don’t un­der­stand what hap­pened, and so I’m putting this post out there to see if per­haps any­one could shed some light—you are wel­come to email me or leave a com­ment at the bot­tom of the post.

Let me back­track and show you how it all went down.

My blog went live on Oct 4 and I pub­lished a lengthy, well-re­search opin­ion piece com­ment­ing on a re­cent event.

Because of that, I wanted the ar­ti­cle to show up on Google ASAP so that when peo­ple searched about the event, maybe my ar­ti­cle would come up. I knew that it could take a while for Google to nat­u­rally crawl and in­dex a new site, so to ac­cel­er­ate the process, I went on Google Search Console (GSC), sub­mit­ted the sitemap and re­quested in­dex­ing on my ar­ti­cle.

And it worked—the next day, my blog and ar­ti­cles were in­dexed and showed up on Google if you put in the right search terms.

In GSC, you can even see that I was get­ting some im­pres­sions and clicks at the time from the ex­act topic that my opin­ion piece was about. Great!

From then on, every time I pub­lished a new post, I would go to GSC and re­quest in­dex­ing for the post URL, and my post would be on Google search re­sults shortly af­ter, as ex­pected.

On Oct 14, as I was dig­ging around GSC, I no­ticed that it was telling me that one of the URLs weren’t in­dexed. I thought that was weird, and not be­ing very fa­mil­iar with GSC, I went ahead and clicked the “Validate” but­ton.

Only af­ter did I re­al­ized that URL was the RSS feed sub­scribe link, https://​blog.james-zhan.com/​feed/?​type=rss, which was­n’t even a page so it made sense that it had­n’t been in­dexed, but it was too late and there was no way for me to stop the val­i­da­tion.

I re­ceived an email from GSC telling me it was val­i­dat­ing that 1 page with in­dex­ing is­sues:

Four days later, on Oct 20, I re­ceived an email from GSC say­ing “Some fixes failed for Page in­dex­ing is­sues on site https://​blog.james-zhan.com/” and when I searched “site:blog.james-zhan.com,” I saw that all but one of my blog posts had been de-in­dexed:

All of them showed the same rea­son:

“Page is not in­dexed: Crawled — cur­rently not in­dexed”

Confused, I poked around GSC to see if it showed me why, and I could­n’t find any­thing use­ful, so I re­sub­mit­ted the sitemap for good mea­sure, and clicked “Validate” again.

I even re­quested in­dex­ing for all the in­di­vid­ual blog post URLs and that did­n’t do any­thing.

As of the pub­lish­ing of this post, the val­i­da­tion sta­tus is still “Started” (it’s been nearly 20 days).

As I was trou­bleshoot­ing, I no­ticed that the day that I ini­ti­ated the val­i­da­tion for the first time (Oct 14) was the same day that all but one of my blog posts got de-in­dexed:

Did my ac­ci­den­tal at­tempt to make GSC in­dex https://​blog.james-zhan.com/​feed/?​type=rss cause some kind of glitch, thereby de-in­dex­ing the rest of the blog?

I don’t get why it would, but it’s weird that the two events hap­pened on the same day.

While this was go­ing on, I con­tin­ued to post a few ar­ti­cles, and you can see that all the new posts faced the “Page is not in­dexed: Crawled — cur­rently not in­dexed” er­ror:

And then on Nov 3, I dis­cov­ered that the re­main­ing, sin­gle blog post that had been in­dexed just got de-in­dexed as well:

So ba­si­cally, no one could find my blog on Google.

I’m not a web dev or pro­gram­mer, but I tried my best to cover as much ground as pos­si­ble in my trou­bleshoot­ing to nar­row down the cause.

The root do­main, james-zhan.com, was from GoDaddy. I’ve had this do­main for many years and I’ve used it on dif­fer­ent sites and never had an is­sue with Google’s in­dex­ing.

For ex­am­ple, just this year, I cre­ated a new sub­do­main with it and that’s been in­dexed by Google.

I also don’t touch any ad­vanced con­fig­u­ra­tion with DNS records or what have you—I don’t have knowl­edge in that stuff, so it’s un­likely I some­how screwed up some­thing in GoDaddy.

But just to be sure it was­n’t some wonky thing go­ing on specif­i­cally with the Bear blog + GoDaddy combo, I cre­ated an­other Bear blog with the sub­do­main www.james-zhan.com.

This one shows up on Google no prob­lem.

Whenever peo­ple dis­cuss the in­dex­ing of their web­site in on­line fo­rums, they al­ways talk about the qual­ity of the con­tent be­ing a huge fac­tor. They say that your site is­n’t in­dexed or is­n’t ranked highly be­cause your site does­n’t have much con­tent, your con­tent is low ef­fort, or some­thing like that.

First, I’m not wor­ried about rank­ing—I just want my blog to be prop­erly in­dexed.

Second, the is­sue could­n’t be the qual­ity or the quan­tity of the con­tent. I came across some other pretty bare­bones Bear blogs that don’t have much con­tent, and looked them up on Google, and they showed up in the re­sults just fine.

An ex­am­ple: Phong’s blog. It’s a very min­i­mal­ist blog with only 6 posts (of great qual­ity) and it shows up on Google search.

Conclusion: Quality or quan­tity of con­tent was­n’t the cause.

I read about how the struc­ture of a site can play a role in Google’s in­dex­ing.

Some say that if your blog posts’ URLs are all “orphaned,” like:

Allegedly, that might cause Google to not in­dex your posts. By de­fault, when you pub­lish a post on Bear Blog, the blog post’s path is­n’t pre­ceded by “blog/.”

So I went around and checked the post URLs of other Bear blogs and saw that none of them had “/blog/” in them, and those blogs were in­dexed just fine. I also highly doubt it’s a real is­sue; oth­er­wise, it would­n’t be the de­fault be­hav­iour on Bear Blog.

Conclusion: Lack of in­ter­nal link­ing was­n’t the cause.

I reached out to Herman with all the de­tails and asked him for help. Of course, he re­sponded promptly and helped me trou­bleshoot to iden­tify the cause.

He was able to con­firm and the fol­low­ing:

* GoDaddy and DNS weren’t the cause

* My bear blog had noth­ing that would pre­vent Google from in­dex­ing

* HTML/CSS does­n’t af­fect SEO/indexing

I had the fol­low­ing CSS code to put the tags above the blog post ti­tle, but Herman said this was fine

/* –- Move tags above the ti­tle –- */

main {

dis­play: flex;

flex-di­rec­tion: col­umn;

/* Style and repo­si­tion the tags */

main > p.tags {

or­der: -1;                /* Moves tags above the ti­tle */

mar­gin: 0 0 0.6rem 0;

font-size: 0.9em;

let­ter-spac­ing: 0.02em;

color: var(–head­ing-color);

opac­ity: 0.8;

/* Keep the ti­tle be­low tags */

main > h1 {

or­der: 0;

* I had the fol­low­ing CSS code to put the tags above the blog post ti­tle, but Herman said this was fine

I just wanted to take a mo­ment to ex­press my grat­i­tude to Herman for in­ves­ti­gat­ing this with me. My emails to him were pretty elab­o­rate with trou­bleshoot­ing steps I had taken along with many screen­shots. He took the time to fully un­der­stand the whole is­sue and even triple-checked my site to make sure every­thing was sound.

It was a re­fresh­ing tech sup­port ex­pe­ri­ence, and made me love Bear Blog as a plat­form just that much more.

I don’t even have to use “site:”—just by search­ing “James Zhan blog,” both my blog and my www.james-zhan.com site show up in other search en­gines:

So there’s def­i­nitely noth­ing wrong on a tech­ni­cal level with my blog that would pre­vent Google from in­dex­ing it.

I copied my blog over to a dif­fer­ent sub­do­main (you are on it right now), moved my do­main from GoDaddy to Porkbun for URL for­ward­ing, and set up URL for­ward­ing with paths so any blog post URLs I posted on­line will au­to­mat­i­cally be redi­rected to the cor­re­spond­ing blog post on this new blog.

I also avoided sub­mit­ting the sitemap of the new blog to GSC. I’m just gonna let Google nat­u­rally in­dex the blog this time. Hopefully, this new blog won’t run into the same is­sue.

At this point, I’m no longer try­ing to re­solve the is­sue, but just out of cu­rios­ity, I do want to know what the hell hap­pened there. I’d had a pre­vi­ous site on GSC to track traf­fic for many years and never had such an is­sue.

If any of you have any guesses, I’d love to hear them (email me or leave a com­ment be­low)!

Subscribe to my blog via email or RSS feed.

The Tor Project has been busy with the rus­ti­fi­ca­tion of their of­fer­ing for quite some time now.

If you have used Tor Browser, you know what it does. Anonymous brows­ing through en­crypted re­lay chains. The net­work it­self has been run­ning since the early 2000s. All of it is built on C.

But that C code­base is an is­sue. It is known to have buffer over­flows, use-af­ter-free bugs, and mem­ory cor­rup­tion vul­ner­a­bil­i­ties. That is why they in­tro­duced Arti, a Rust rewrite of Tor that tack­les these flaws by lever­ag­ing the mem­ory safety of the pro­gram­ming lan­guage.

A new re­lease of Arti just dropped last week, so let’s check it out!

We be­gin with the main high­light of this re­lease, the roll­out of the cir­cuit time­out re­work that was laid out in pro­posal 368. Tor cur­rently uses some­thing called Circuit Dirty Timeout (CDT). It is a sin­gle timer that con­trols when your con­nec­tion cir­cuits be­come un­avail­able and when they close down.

Unfortunately, it is pre­dictable. Someone mon­i­tor­ing traf­fic can spot these pat­terns and po­ten­tially track your ac­tiv­ity. Arti 1.8.0 fixes this by im­ple­ment­ing us­age-based time­outs with sep­a­rate timers. One han­dles when cir­cuits ac­cept new con­nec­tions. Another closes idle cir­cuits at ran­dom times in­stead of fixed in­ter­vals.

This should re­duce the risk of fin­ger­print­ing from pre­dictable time­out be­hav­ior.

Next up is the new ex­per­i­men­tal arti hsc ctor-mi­grate com­mand that lets onion ser­vice op­er­a­tors mi­grate their re­stricted dis­cov­ery keys from the C-based Tor to Arti’s key­store.

These keys han­dle client au­tho­riza­tion for onion ser­vices. The com­mand trans­fers them over with­out re­quir­ing op­er­a­tors to do the man­ual leg­work. The re­lease also de­liv­ers im­prove­ments for rout­ing ar­chi­tec­ture, pro­to­col im­ple­men­ta­tion, di­rec­tory cache sup­port, and OR port lis­tener con­fig­u­ra­tion.

You can go through the changelog to learn more about the Arti 1.8.0 re­lease.

Suggested Read 📖: Is Helium the Browser Brave Was Meant to Be?

Apple loses its ap­peal of a scathing con­tempt rul­ing in iOS pay­ments case

But Sweeney warns iOS devs are still afraid of “totally il­le­gal” re­tal­i­a­tion by Apple.

A rare “total eclipse” of Apple by Epic Games, cap­tured on cam­era.

A rare “total eclipse” of Apple by Epic Games, cap­tured on cam­era.

Back in April, District Court Judge Yvonne Gonzalez Rogers de­liv­ered a scathing judg­ment find­ing that Apple was in “willful vi­o­la­tion” of her 2021 in­junc­tion in­tended to open up iOS App Store pay­ments. That con­tempt of court find­ing has now been al­most en­tirely up­held by the Ninth Circuit Court of Appeals, a de­vel­op­ment that Epic Games’ Tim Sweeney tells Ars he hopes will “do a lot of good for de­vel­op­ers and start to re­ally change the App Store sit­u­a­tion world­wide, I think.”

The rul­ing, signed by a panel of three ap­pel­late court judges, af­firmed that Apple’s ini­tial at­tempts to charge a 27 per­cent fee to iOS de­vel­op­ers us­ing out­side pay­ment op­tions “had a pro­hib­i­tive ef­fect, in vi­o­la­tion of the in­junc­tion.” Similarly, Apple’s re­stric­tions on how those out­side links had to be de­signed were overly broad; the ap­peals court sug­gests that Apple can only en­sure that in­ter­nal and ex­ter­nal pay­ment op­tions are pre­sented in a sim­i­lar fash­ion.

The ap­peals court also agreed that Apple acted in “bad faith” by re­fus­ing to com­ply with the in­junc­tion, re­ject­ing vi­able, com­pli­ant al­ter­na­tives in in­ter­nal dis­cus­sions. And the ap­peals court was also not con­vinced by Apple’s process-fo­cused ar­gu­ments, say­ing the dis­trict court prop­erly eval­u­ated ma­te­ri­als Apple ar­gued were pro­tected by at­tor­ney-client priv­i­lege.

While the dis­trict court barred Apple from charg­ing any fees for pay­ments made out­side of its App Store, the ap­peals court now sug­gests that Apple should still be able to charge a “reasonable fee” based on its “actual costs to en­sure user se­cu­rity and pri­vacy.” It will be up to Apple and the dis­trict court to de­ter­mine what that kind of “reasonable fee” should look like go­ing for­ward.

Speaking to re­porters Thursday night, though, Epic founder and CEO Tim Sweeney said he be­lieves those should be “super su­per mi­nor fees,” on the or­der of “tens or hun­dreds of dol­lars” every time an iOS app up­date goes through Apple for re­view. That should be more than enough to com­pen­sate the em­ploy­ees re­view­ing the apps to make sure out­side pay­ment links are not scams and lead to a sys­tem of “normal fees for nor­mal busi­nesses that sell nor­mal things to nor­mal cus­tomers,” Sweeney said.

“The 9th Circuit Court has con­firmed: The Apple Tax is dead in the USA,” Sweeney wrote on so­cial me­dia. “This is the be­gin­ning of true, un­taxed com­pe­ti­tion in pay­ments world­wide on iOS.”

An Apple spokesper­son has not yet re­sponded to a re­quest for com­ment from Ars Technica.

While some app de­vel­op­ers have made the move to their own pay­ment proces­sors in the wake of April’s rul­ing, Sweeney said he thinks many were wait­ing to see if the de­ci­sion would be over­turned on ap­peal. With that fear now mooted, he said we’ll prob­a­bly see “rapid adop­tion” of out­side pay­ment proces­sors, in­clud­ing the Epic Web Shops that the com­pany rolled out in October. Sweeney pre­dicted that these kinds of web pay­ments for iOS apps “will just be­come the norm” by the end of next year and that “after years of Apple ob­struc­tion, we’re fi­nally go­ing to see large-scale change hap­pen­ing.”

Sweeney also pointed to an al­leged wide­spread “fear of re­tal­i­a­tion” that has led many iOS de­vel­op­ers to keep pay­ing 30 per­cent fees to use Apple’s de­fault in-app pay­ments. Sweeney said that Apple has “infinite power to re­tal­i­ate” against apps that add out­side pay­ment op­tions by in­def­i­nitely de­lay­ing their app re­views or bury­ing their prod­ucts in App Store search re­sults. Sweeney called this kind of “ghosting” a “totally il­le­gal” ex­er­cise of “soft power” by Apple that reg­u­la­tors will need to look at if it keeps up.

When pitch­ing Epic’s own out­side pay­ment op­tions to ma­jor iOS de­vel­op­ers, Sweeney said he fre­quently has to ad­dress fears that lower pay­ment fees will be over­whelmed by the drop in users caused by this kind of Apple re­tal­i­a­tion. “We’re just too afraid of Apple hurt­ing our busi­ness,” Sweeney said in sum­mary of the com­mon re­sponse from other de­vel­op­ers. “The sad truth is every­body’s afraid of Apple.”

Kyle Orland has been the Senior Gaming Editor at Ars Technica since 2012, writ­ing pri­mar­ily about the busi­ness, tech, and cul­ture be­hind video games. He has jour­nal­ism and com­puter sci­ence de­grees from University of Maryland. He once wrote a whole book about Minesweeper.

After NPR and PBS de­fund­ing, FCC re­ceives call to take away sta­tion li­censes

How to break free from smart TV ads and track­ing

After years of re­sist­ing it, SpaceX now plans to go pub­lic. Why?

Crossing the Koralpe mas­sif more quickly and with more com­fort. That’s what the fu­ture of train travel from Graz to Klagenfurt looks like. With the Koralm Railway, you will ar­rive at your des­ti­na­tion even quicker. The fastest con­nec­tion will shrink from three hours to just 45 min­utes. Western Styria and south­ern Carinthia can be reached even more eas­ily — as can our neigh­bour­ing coun­tries Hungary and Italy.

The econ­omy is also ben­e­fit­ing from the con­struc­tion of the new Koralm Railway. As part of the new Southern Line, it is strength­en­ing the Baltic-Adriatic Corridor in Europe. Transporting goods in Austria by train is be­com­ing more at­trac­tive, which in turn is al­low­ing our op­er­a­tions to re­main com­pet­i­tive in­ter­na­tion­ally. And the en­vi­ron­ment to breathe: Each tonne of freight moved by rail gen­er­ates around 15 times less CO2 emis­sions than trans­port­ing it by lorry.

Researchers have suc­cess­fully used CRISPR gene edit­ing tech­nol­ogy to cre­ate a fungi strain that is highly ef­fi­cient, more nu­tri­tious, and sig­nif­i­cantly more sus­tain­able than its nat­ural coun­ter­part. The fun­gus Fusarium ve­ne­na­tum al­ready stands out for its meat-like fla­vor and tex­ture, lead­ing to its ap­proval for food use in sev­eral coun­tries. This break­through, pub­lished in the jour­nal Trends in Biotechnology, ad­dresses the need for bet­ter, more en­vi­ron­men­tally friendly al­ter­na­tives to con­ven­tional an­i­mal agri­cul­ture, which ac­counts for about 14% of global green­house gas emis­sions.

The sci­en­tists, led by cor­re­spond­ing au­thor Xiao Liu of Jiangnan University, used CRISPR to re­move two spe­cific genes. The first mod­i­fi­ca­tion, elim­i­nat­ing a gene for chitin syn­thase, re­sulted in thin­ner fun­gal cell walls. This change is cru­cial as it makes the fun­gal pro­tein eas­ier for hu­mans to di­gest and in­creases its bioavail­abil­ity. The sec­ond change in­volved re­mov­ing the pyru­vate de­car­boxy­lase gene, which op­ti­mized the fun­gus’s me­tab­o­lism. This fine-tun­ing made the new strain, called FCPD, more pro­duc­tive, re­quir­ing 44% less sugar to pro­duce the same amount of pro­tein and do­ing so 88% faster than the orig­i­nal strain.

When scaled up, FCPD pro­duc­tion showed a lower en­vi­ron­men­tal foot­print re­gard­less of the man­u­fac­tur­ing lo­ca­tion, re­duc­ing green­house gas emis­sions by up to 60% over its life cy­cle com­pared to tra­di­tional fun­gal pro­tein pro­duc­tion. Furthermore, com­pared to chicken pro­duc­tion in China, the new my­opro­tein re­quires 70% less land and re­duces the risk of fresh­wa­ter pol­lu­tion by 78%. According to the re­searchers, this type of gene-edited food can help meet global food de­mands with­out the sub­stan­tial en­vi­ron­men­tal costs as­so­ci­ated with con­ven­tional farm­ing, rep­re­sent­ing a ma­jor ad­vance­ment in the field of sus­tain­able food tech­nol­ogy.

For more de­tails, read this ar­ti­cle or down­load the open-ac­cess pa­per.

We ab­solutely love SQLite here at DB Pro. You’d be hard-pressed to find any­one who ac­tively dis­likes it. Sure, it has lim­i­ta­tions, and I do mean lim­i­ta­tions, not weak­nesses. SQLite can ab­solutely be used in pro­duc­tion when it’s de­ployed prop­erly and tuned with care.

SQLite has also seen some­thing of a resur­gence over the past few years. From be­ing forked into pro­jects like lib­SQL and Turso, to pow­er­ing pop­u­lar back­end frame­works such as PocketBase, it’s clearly hav­ing a mo­ment again.

As I said though, we love it. It even pow­ers the lo­cal data­base in­side DB Pro it­self. For our use case, there re­ally is­n’t a bet­ter al­ter­na­tive.

Because we’ve been us­ing SQLite in anger over the past three months, we’ve learnt a huge amount about it, in­clud­ing plenty of things we did­n’t know be­fore.

So I’m plan­ning to write a short se­ries of blog posts cov­er­ing some of the cooler, more in­ter­est­ing fea­tures and nu­ances of SQLite that we’ve dis­cov­ered along the way. This is the first of those posts.

First of all. Did you know SQLite has JSON func­tions and op­er­a­tors? I did­n’t un­til re­cently! I came across this Hacker News com­ment when re­search­ing SQLite’s JSON op­er­a­tors.

I read that, then read it again, then again un­til I un­der­stood what bam­bax was say­ing. I was sort of in dis­be­lief.

So I had to give it a try to see if it works. We’ve got an em­bed­ded SQLite-in-the-browser com­po­nent on our blog and so I wanted to throw to­gether some work­ing ex­am­ples for you guys (but mostly for me).

Let’s break down what bam­bax is say­ing:

This means you never have to choose your in­dex­ing strat­egy up front. If you later re­alise you need to query on a new JSON field, you sim­ply add an­other gen­er­ated col­umn, add an in­dex, and you’re done.

No data mi­gra­tion. No schema rewrite. No ETL. Just pure flex­i­bil­ity.

Your JSON doc­u­ments are stored nat­u­rally, ex­actly as they ar­rive. No schema gym­nas­tics re­quired ei­ther!

Here’s where bam­bax is say­ing the magic hap­pens. Let’s add vir­tual gen­er­ated columns. Generated columns com­pute val­ues on de­mand. They don’t ac­tu­ally store data:

I be­lieve that no writes oc­cur. There’s no back­fill­ing. It’s in­stant. The vir­tual columns are com­puted on-the-fly from your JSON data when­ever you query them.

Now is the ic­ing on the cake. We add in­dexes to make these vir­tual columns blaz­ing fast:

Suddenly your JSON be­haves like nor­mal re­la­tional columns with full in­dex sup­port.

Now your queries are blaz­ing fast. So let’s give it a go with some ex­am­ples:

I be­lieve this is one of the strongest points to this pat­tern. If at a later date your JSON shape changes (expected), you can just add an­other col­umn and cre­ate an­other in­dex.

For ex­am­ple, you re­alise you need to query by user_id:

This pat­tern com­pletely changed how I think about work­ing with JSON in SQLite. You get the flex­i­bil­ity of schema­less data, com­bined with the per­for­mance and er­gonom­ics of a re­la­tional data­base, with­out com­mit­ting your­self too early or paint­ing your­self into a cor­ner.

There are plenty more of these lit­tle SQLite su­per­pow­ers hid­ing in plain sight. This is just the first one I wanted to share.

Doom and Quake stu­dio id Software are now home to a “wall-to-wall” union ac­cord­ing to the Communications Workers of America (CWA). The or­gan­i­sa­tion have an­nounced that a group of 165 id work­ers have just voted to unionise, adding to the ranks of the 300 ZeniMax qual­ity as­sur­ance staff who unionised back in 2023.

According to the CWA’s press re­lease, Microsoft have al­ready recog­nised this lat­est union - which is made up of “developers, artists, pro­gram­mers, and more” - in ac­cor­dance with the labour neu­tral­ity agree­ment the two par­ties agreed in 2022.

“The wall-to-wall or­ga­niz­ing ef­fort at id Software was much needed; it’s in­cred­i­bly im­por­tant that de­vel­op­ers across the in­dus­try unite to push back on all the uni­lat­eral work­place changes that are be­ing handed down from in­dus­try ex­ec­u­tives,” said id Software pro­ducer and CWA or­gan­is­ing com­mit­tee mem­ber Andrew Willis.

Meanwhile, id lead ser­vices pro­gram­mer and CWA com­mit­tee mem­ber Chris Hays specif­i­cally cited re­mote staff not be­ing dragged into the of­fice as a rea­son be­hind the push for rep­re­sen­ta­tion. “Remote work is­n’t a perk,” he said. “It’s a ne­ces­sity for our health, our fam­i­lies, and our ac­cess needs. RTO poli­cies should not be handed down from ex­ec­u­tives with no con­sid­er­a­tion for ac­ces­si­bil­ity or our well-be­ing.”

The CWA re­lease also cited “mass in­dus­try lay­offs, sud­den pe­ri­ods of crunch time, and un­fair pay” as part of the im­pe­tus be­hind a wider push to­wards union­i­sa­tion among devs across the in­dus­try this year, adding that the to­tal of unionised work­ers across Microsoft’s fief­dom is now “nearly 4,000″ strong.

CWA pres­i­dent Ron Swaggerty added that the union “look for­ward to sit­ting across the table from Microsoft to ne­go­ti­ate a con­tract that re­flects the skill, cre­ativ­ity, and ded­i­ca­tion these work­ers bring to every pro­ject.”

If you want to learn more about the CWA’s union­i­sa­tion ef­forts as the games in­dus­try’s suits and mon­ey­folk con­tinue to lob de­vel­op­ers out of win­dows with de­press­ing reg­u­lar­ity, give this in­ter­view Nic did a read.

Meanwhile, mem­bers of the “industry-wide union” the CWA an­nounced ear­lier this year held a protest out­side of The Game Awards yes­ter­day, with their aim be­ing to “to ac­knowl­edge the video games and stu­dios that have been closed and to also con­demn the cre­ativ­ity that’s been crushed by cor­po­rate greed and stu­dio ex­ec­u­tives”.

A “relaxation” pro­ject, mostly drawn on planes to and from Norway this month, where I had to travel to setup a dig­i­tal art in­stal­la­tion in Kristiansand with friends from the dig­i­tal art col­lec­tive Lab212. It has been drawn with one ma­jor con­straint: it must fit in the in­ner pocket of my jacket (well, one spe­cific jacket), ex­cept for the rods.

This is a 3D-printed dob­son­ian tele­scope built around a 76mm/300mm par­a­bolic mir­ror kit. While there are plenty of mini-scope mod­els on the in­ter­net, I wanted some­thing that looked like a dob­son that went a bit too hard through the clothes dryer, but with­out com­pro­mise on what mat­ters:

* Nylon screws to col­li­mate both the pri­mary and sec­ondary mir­rors

* A bit of paraf­fin to lu­bri­cate the fo­cuser

* A ly­cra light shroud that also helps with de­lay­ing dew form­ing on the mir­rors

The fo­cuser fol­lows Analog Sky’s recipe: the tube that re­ceives the eye­piece is also the move­ment it­self, with a rounded thread that prints ex­tremely smoothly with very lit­tle play. No ad­di­tional hard­ware needed - the eye­piece is self-held by the flex­ion of plas­tic fins.

All the holes for the rods are straight, which forces them to arch, which “locks” the struc­ture in place.

The alt/​az move­ments use “teflon pads” (actually gray HDPE or UHMW for fur­ni­ture feet) with rub­ber back­ing, scalped and glued.

Download the 3D files on Printables • Discussion on Astrosurf

If you build it, the real trick for ease of mount­ing is to cham­fer the car­bon rods with a 1mm cham­fer at both ends and seal it with CA glue. See the cham­fer pic in the gallery.

Sadly, the re­sults aren’t great. We were used to very good λ/​6 or bet­ter re­cent buys from Aliexpress, but this one is very over­cor­rected. It was very smooth, with a rather good edge at the fou­cault, but is over­cor­rected by 70%. With the eye­piece I se­lected, putting it at 30x power, this does not show too much, and it re­tains its “real tele­scope” sta­tus. But this mir­ror is so small that I will not re­fig­ure it — the re­a­lu­miniz­ing costs would out­weigh the en­tire pro­ject.

Edit dec. 12th The λ/​6 aliex­press mir­rors men­tioned were spher­i­cal. So, great start­ing points to fig­ure them, but un­us­able as-is. I did not yet stum­ble on a great parabola at a low price, and this is to be ex­pected.

Edit as of dec. 11th : of course I did not re­sist re-fig­ur­ing it. It now hov­ers around 0.9 strehl. The star test with the se­lected eye­piece shows nice sym­met­ric de­fo­cused stars and I can now count in­di­vid­ual spi­der web strands and dis­tin­guish the dew droplets it car­ries, on a nearby elec­tri­cal pole, whereas I did not even see the spi­der web with the mir­ror as it was from the fac­tory. I still need to do a proper “showable” Bath re­port with enough in­ter­fer­o­grams, my last test was 4 in­ter­fer­o­grams and car­ries a ton of noise. So it is great but I now have to get it coated, and work­ing a mir­ror this small did raise a few chal­lenges in han­dling it.

All test pic­tures be­low are be­fore re­fig­ur­ing

Michael Larabel is the prin­ci­pal au­thor of Phoronix.com and founded the site in 2004 with a fo­cus on en­rich­ing the Linux hard­ware ex­pe­ri­ence. Michael has writ­ten more than 20,000 ar­ti­cles cov­er­ing the state of Linux hard­ware sup­port, Linux per­for­mance, graph­ics dri­vers, and other top­ics. Michael is also the lead de­vel­oper of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org au­to­mated bench­mark­ing soft­ware. He can be fol­lowed via Twitter, LinkedIn, or con­tacted via MichaelLarabel.com.