NASA/Commander Reid Wiseman, (original)

On Scientific Progress

NASA/Commander Reid Wiseman, (original)

This view from inside the Orion spacecraft certainly evokes a special feeling. This is the Earth, this is our home – but we’ve (at least my generation) never seen it like this, not out of a spacecraft. In my opinion, it represents the pinnacle of human endeavour, taking flight again after a 50-odd year break.

I certainly hope that this launch creates the same influx of kids into STEM as the Apollo and Saturn launches did decades ago. It’s easy to question the cost and necessity of these things, especially with all that’s happening back home, but I don’t think we can put a price on scientific progress. Reid Wiseman, Victor Glover, Christina Koch, Jeremy Hansen, along with everybody else who worked on this program, are pushing us closer towards the Moon than we’ve been in the past 5 decades: that’s certainly a feat of humanity worth admiring.

NASA/Eric Bordelon, (original)

In this world of almost blink-and-you-miss-it startups touting their products as definitely the future one second and wiped off the map the next, 50 years sure is a long time.

But that’s where Apple shines the most – try as you might, you really can’t imitate your way to maturity. Technology moves at a rapid pace, but people with the tenacity to think of what that technology can do for regular human beings are few and far between. In the past fifty years, computers have gone from being niche hobby build-it-yourself kits to being mass manufactured in giant factories and put into nearly everything, including perhaps your microwave and washing machine. The ubiquity of these devices, however, doesn’t really negate what makes a product truly wonderful. Maybe I’m idealistic, but I still believe that technology serves as the great equalizer.

Technology for me is a tool for thought. A bicycle for the mind, as Jobs might’ve put it. But since the days of the Apple ][, technology has become the most powerful tool we have. Whether it’s how the original Lisa and Macintosh changed how we thought about interfaces, or how the iPod and iTunes changed how we listened to music, or how the MacBook Air changed what we expected out of laptops, or how the iPhone changed how we communicate with each other – each of these devices was simply a new way to augment our own thinking. Apple’s real impact has never been these devices, but rather what they’ve made impossible to ignore. The greatest trick has always been restraint, hiding just enough to make everything feel like magic.

It’s impossible to predict what the next 50 years will look like for Apple, or even for the tech world in general. But if Apple’s last 50 are anything to go by, I’m more than certain they’ll continue making wonderful tools for thought.

I’ve always been really into computers, and I’ve loved writing code and making computers do things since I was a kid. This infatuation started off innocently enough, with MSWLOGO.

When I was 9 I taught myself BASIC, and a few years later moved on to Scratch. The computer I had at the time, an old Lenovo, wasn’t really equipped to run Scratch, with its whole three gigabytes of RAM and a spinning hard disk. This was still a time when Scratch relied on Flash to work – but I pressed on.

A couple years later I got my first Mac.

My 2017 MacBook Air

Sure, I started with Scratch, but the amount of things I’ve done on this little computer is insane. Nobody really finds the best tool on the first try. Neither does anyone serious about their work use their first set of tools particularly well. No no, obsession doesn’t work like that. Obsession does not make you neatly write down some requirements and use the correct tools for the job, obsession makes you work with whatever’s available, no matter how absurd the gap between theory and reality might be. Of course I knew it was the wrong computer for what I wanted to do with it, but when is this really going to stop an overly ambitious kid?

I should know this, because on this computer, in no particular order, I: ran Blender, edited videos with Final Cut Pro, made music with GarageBand, ran a whole bunch of VMs with VirtualBox, made a bunch of software with a whole catalog’s worth of tools and frameworks and languages, designed useless things with Fusion 360, made schematics with EAGLE, wrote silly apps with Xcode… basically whatever I could get my hands on. I even wrote software to teach kids how to code.¹ I’ve probably forgotten a lot of what I did, really, but you get the idea.

I think it’s worth noting that on multiple occasions this machine was cooled by ice packs placed underneath it. I’ve also probably used it as a space heater on cold winter days.² A friend and I joked often about “Flying Laptop-shaped UFO Sighted: Local Residents Worried”.

Granted, I still think it’s a great laptop. Probably more than it had any right to be.

Sidenote: My original iPad

This was my first “real” Apple device, after the iPod Nano 3G. It was the first time I’d ever interacted with a touch screen, and I still love how iOS 5 looks today.

But arguably what’s more important to me than what I did on these devices is what I learnt from pushing them beyond their limits. Even today, my sense of design, my preference for simple technology, my interest in human-computer interaction, my love for the UNIX philosophy, and rather more important my love for computer science – all stem at least in some way from my using these devices.

It’s hard to understate how much Apple devices have impacted me. I’ve had the privilege to enjoy using a whole bunch of Apple devices: the iPod Nano I slung around as a kid, the first-generation iPad, the iPad Air I used through school (and still do today), the woefully underpowered late-2017 13-inch MacBook Air, its M2 successor (coincidentally the one this post is being written on), my iPhone… certainly more than my fair share of them, to be honest.

So happy birthday, Apple! Here’s to another 50.

TextMate has been a mainstay of my development tool belt for a while now, and it’s one of the last truly native macOS editors still around. But development stalled, and with no updates since 2021, I figured – “How hard could it be to compile it myself?”

The Case of the Missing Gutter

Last time, we arrived at this compiled product:

One glaring issue here was the gutter… or lack thereof. In the previous post in this series, I said:

… but notice how the gutter is completely missing? And how the file browser’s background isn’t quite right? I’m not sure what’s causing that, but I want to assume it’s some NSColor deprecation thing that’s causing it to behave this way. Although, it’s just a hunch, and I’m not sure what to think yet. Some… creative… debugging with Apple’s Quartz Debug tool and its “Flash screen updates” toggle tells me that whatever’s rendering the gutter, is, in fact, updating the right bits on screen at the right time – it’s just completely invisible for some reason.

Gutter aside, some more digging led me to line 72 in the FileBrowser framework:

Frameworks/FileBrowser/src/FileBrowserView.mm : 72

_outlineView.backgroundColor = NSColor.clearColor;

Changing clearColor to something like redColor showed up immediately, and using windowBackgroundColor fixed the issue. But I’m not sure if this is the fix – I figure that it was set to clearColor to let the window background show through, but for some reason the window itself is stuck in this gray color. Although, I could be completely wrong here and the issue could be something else entirely.

But why would changing the background colour fix the issue at all? And why were bits on screen being updated, even though the updates weren’t really visual?

Some more debugging later, where I changed the themes around, I realised that that the gutter’s divider was being rendered across the entire window, instead of within its own bounds. After changing that to redColor instead of having it pick it up from the theme, this bug was caught red handed. (pun intended)

So, to clip this to bounds, it was quite simple: `

Frameworks/OakTextView/src/OakDocumentView.mm

    87: gutterDividerView = OakCreateVerticalLine(OakBackgroundFillViewStyleNone);

(+) 88: gutterDividerView.clipsToBounds = YES;

… and here’s the result:

And changing it back to pick up the theme’s settings, this issue is completely fixed:

^{This was solved in fed17e9 fixed gutter not showing up}

Fixing the tabs

Look closely at the tabs in the last image – the text seems to be hugging the bottom of the tabs. This somehow wasn’t the case last time, so I assume this is because macOS Tahoe increases the height of NSTitlebarAccessoryView.

This was quite simple to fix, I just had to change the hard-coded constraints…

Frameworks/OakTabBarView/src/OakTabBarView.mm

[self addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:[close]-(4)-|" 
options:0 metrics:nil views:views]];
[self addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:[title]-(3)-|" 
options:0 metrics:nil views:views]];
[self addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:|[overflow]|" 
options:0 metrics:nil views:views]];

… to automatic ones:

Frameworks/OakTabBarView/src/OakTabBarView.mm


[self addConstraint:[NSLayoutConstraint constraintWithItem:self.closeButton
                                                 attribute:NSLayoutAttributeCenterY
                                                 relatedBy:NSLayoutRelationEqual
                                                    toItem:self
                                                 attribute:NSLayoutAttributeCenterY
                                                multiplier:1
                                                  constant:0]];

[self addConstraint:[NSLayoutConstraint constraintWithItem:self.textField
                                                 attribute:NSLayoutAttributeCenterY
                                                 relatedBy:NSLayoutRelationEqual
                                                    toItem:self
                                                 attribute:NSLayoutAttributeCenterY
                                                multiplier:1
                                                  constant:0]];

[self addConstraint:[NSLayoutConstraint constraintWithItem:self.overflowButton
                                                 attribute:NSLayoutAttributeCenterY
                                                 relatedBy:NSLayoutRelationEqual
                                                    toItem:self
                                                 attribute:NSLayoutAttributeCenterY
                                                multiplier:1
                                                  constant:0]];

Et voila, fixed.

^{This was solved in ba00428 fixed OakTabView constraints to visually center tab bar content on macOS Tahoe}

What next then?

Honestly… no clue. There’s a few aesthetic changes I want to make in certain places, but that’s about it. TextMate is fully working and completely functional on macOS Tahoe, newly compiled.

This is a blog-ified version of this technical document.

You have to be all kinds of crazy to build a kernel from scratch. Much less build a kernel, a bootloader, a filesystem, a libc implementation, and a text pager and an image viewer for that kernel, from scratch.

No, for that you have to be both stupid and stupidly naive.

Why?

Technology today is layers and layers of software all folded in on itself. Not really simple, and not really easy to understand the entire stack, top to bottom. So I decided to build my own everything, from bootloader to C Standard Library, just to understand how things work.

What?

BoinkOS, or more formally the Boink Kernel Project, aims to provide a reasonable abstraction for every single layer between user and bare metal –

• filesystem (GLFS)
• bootloader (Boink Interactive Bootloader)
• kernel (BoinkOS)
• text pager (with Included Search Function (tm))
• image viewer
• syscall interface
• custom libc

“Allegedly Good Features” I added that definitely did not start as dumb ideas

Of course, starting from scratch gives you ideas for features that you don’t see often, and Boink has two such features:

• kernel scratchpad
  provides 16kb of “scratchpad” space for the kernel to use — avoids page management where it may not be needed.
• panic debug shell
  provides a way to easily debug programs when a panic state is entered. really helpful when you don’t have gdb.

Milestones

Some (overkill) milestones were (slowly and tediously) achieved on this platform.

• custom 32-bit protected mode bootloader with VESA graphics
• paging and frame allocation
• syscalls + userland mode (ring3) context switching
• ELF binary loading and execution
• basic shell with file viewing, image viewing, and app execution
• interrupt handling with IRQs, ISRs, PIT, and keyboard input
• simple framebuffer-based graphics output
• GLFS — a simple loadable filesystem baked into the boot process

A Wild Filesystem Appears

GLFS (good little (luck) file system) is an extremely simple filesystem spec that Boink uses.

[sector 0] GLFS SUPERBLOCK
----------
- magic GLFS+version identifier

[sector 1+] DIRECTORY TABLE
-----------
     [entry 0] filename: string
               start sector: int
	       size: int (bytes)

     [entry 1] filename: string
               start sector: int
	       size: int (bytes)
     (...)

[end of table marker]
----------
[file data]
(...)

Yes, that’s it. Just a superblock, a directory table, and files. No folders, no journaling, no metadata, no permissions… just data.

Coda

OS dev is one of those weird hobbies where you can go weeks without your system doing anything at all, end up backtracking days of work just to implement everything again, and then you fix a random paging bug and it suddenly boots a shell and you feel like god. I definitely did not spend a day debugging the VESA graphics after writing VESA info to one location and trying to read it from a completely different location. Definitely.

Next up at some unspecified date in the vague future: Boink 2: UNIX Boogaloo

“How did you do it?”
“It’s very simple — you read the protocol and write the code.” — Bill Joy, definitely forgetting the mental spiraling bit

Screenshots

First Steps — printing to the screen in VGA text mode

GLFS disk reads

VGA framebuffer graphics

Less-inspired Text Pager

Panic diagnostic shell

Boink Interactive Bootloader

Bitmap Image Viewer

ring3 context switching

Custom libc with basic I/O support

Unfortunately though, pancreatic cancer has taken from us yet another pioneer.

Rest in peace.

It seems we think of the future as a place, a destination to get to and stop, an end to something. To me, though, it isn’t a place – it’s more a feeling. A question without punctuation, a blank page on which to write with tomorrow’s ink, a door with no handle.

It’s quite strange how something so abstract, that doesn’t exist yet, can feel so heavy. So present. It manages to sit on our shoulders like an invisible valise of sorts – a valise with the size of a pea and the weight of an elephant. A white elephant, perhaps. Indisposable, unavoidable, yet an inescapable burden.

Still, we carry it willingly. We obsess over it. We let go of the past because we know it’s unchangeable – and we hold tight the future we know is unwritten. Why do we place hope in the unwritten? Why do we use the unwritten to measure the present? Measuring by not what it is, but what it is not yet?

We’re all just standing at the edge of now, peering keenly into an abyss we call the future, trying to make out the shapes we surely see in the fog. When those shapes come true, we rename them. We call them “now.” And yet again they aren’t enough – we search for more. And when it doesn’t, we stumble through time like children playing dress-up in grown-up dreams.

Still, we dream anyway. Because there’s comfort in the unwritten. It can’t disappoint me yet. It hasn’t failed me yet. It hasn’t come undone. And maybe that’s why we romanticize it so hard — not because of what it is, but because of what it isn’t. But the thing is… we never really get to the future. We only ever get to now. And then another now. And another.

Maybe that’s why we romanticize it so much. Hoping that we can write the unwritten, even when it’s writing itself. We like to pretend like the future is waiting – patient, polite – sitting cross-legged just across the bridge of time. It feels so close, we can almost reach out to her, but she’s impatient, really. She crashes in through the windows, scribbling over my plans. And tomorrow she’ll wear yesterday’s clothes and a new name.

What’s unwritten holds every possibility – and that’s terrifying. Freeing, too. It’s the part of the book where anything can still happen. The lines flow, page to page, but there’s nothing on them yet. Yet. We can imagine what the words will be, but they’ll write themselves in due time.

But also… nothing’s happened yet. And that’s what makes it enticing to sit and ponder about. Not the expectation, not the hope – but rather the way we stand in the present, imagining what those words might be.

Over the years I’ve added many books to my arsenal – but never kept track of them. I fully blame child-me for lack of foresight. :/

In any case, I wanted to have a list of what books I had. But cataloging 4 shelves worth of books wouldn’t be easy.

Enter ISBN

ISBN stands for International Standard Book Number, and is what’s represented by the barcodes you’ll find on the backs of most books. Here’s what a standard 13-digit ISBN is comprised of –

ISBN 978-93-5333-371-3
      a   b   c   d  e

a - GS1 prefix
b - registration group
c - registrant
d - publication
e - check digit

Right, but… ???

What I did with this number was this – I had a script look it up on Google Books.

• Most (~100) books were already there on Google Books – only took around 45 minutes.
• Some (~20) books, that were from smaller publishers or, this was annoying, that had other stickers stuck on top of the barcode, I had to find the information manually. This took nearly an hour and a half.

I added a way for me to select what camera I wanted to use, and I turned over my iPhone and used Continuity Camera to use it as a webcam. There, then I was able to just hover books over my table and have them be scanned in.

Should you do this?

Here’s what actually went down behind the scenes: the script uses pyzbar and opencv to extract the ISBN from the camera feed. Then it pipes that ISBN into a function that calls the Google Books API, grabs all the metadata (title, author, publisher, dates), and dumps it all into a CSV file. End result? A searchable, sortable catalog of all my books. Hey, I even found some books I thought I’d lost along the way!

Frankly, you should do this. If you have any amount of books that you want to keep track of, you absolutely should do this. It’s just so much cleaner and easier to refer to a spreadsheet to search for things than to go digging in the wrong shelf twice.

Get the code >

Creating your own online presence is a tough job. When you’re both client and designer, the highest standards apply. It has to be top notch, unique and inspiring on every level.

— Jorn van Dijk, Made by Sofa

This was the basis for me redesigning this website. The old one was sleek and clean, sure, but it lacked the charm I wanted it to have. I’ve always loved those old-web blogs that seem to have some character to them, like Daring Fireball, The Blogess, Michael Tsai and a whole host of others — so I wanted to have some of that charm shine here as well.

Georgia on my mind (… and Verdana too, maybe)

One of the first things I did was to take out the Lato, Source Serif, and IBM Plex Mono fonts in favour of Georgia, Verdana, and Courier New. I have nothing against those fonts, heck, they’re still my favourite fonts to use on other projects — but I wanted to keep this site “classic,” so to speak. They scream “old web” but in a warm, unpretentious way — these fonts are web-safe and will still render beautifully on basically everything.

Theme color

Now there’s a theme colored body that replaces the white nothingness of yore. It’s subtle, but it serves to emphasize the 640px content width and also makes it feel a lot more cozier and less like a printout.

Pagination

This one’s purely for technical reasons, end of reasons. I am not interested in an unmanagable list of links.

Dates before titles

Purely for the aesthetic. Again, charm is what I’m going for. Also I don’t know, it just feels more blog-ish to me for some reason.

At the end of the day, it’s not beautiful that I’m after — I want a place on the web that feels like me and not a prim-ified me.

Cybersecurity 101: Never trust your users.

How many times have we heard that phrase? Well, to be honest, far too many times to count. But that doesn’t stop some people from trusting their users with their most sensitive secrets.

TL;DR: Someone Just Taped Their Keys to the Front Door

Taping your keys to your door when you leave your house might be a great way for you to remember where you put them – they’re literally taped to your door!

But that’s not exactly secure, is it? So if a billion dollar giant did exactly that while storing data about people under the age of 18 in the house… would you trust them?

What’s wrong here?

Allen’s iOS app bundle reveals multiple sensitive credentials found in plain-text within .plist files. A simple right-click>Show Package Contents leads to more than 10 sensitive API keys and other sensitive secrets from CleverTap, Google Cloud, DataDog and others.

Here’s what’s exposed:

• CLIENT_ID
• REVERSED_CLIENT_ID
• ANDROID_CLIENT_ID
• API_KEY
• GCM_SENDER_ID
• STORAGE_BUCKET
• PROJECT_ID
• BUNDLE_ID
• GOOGLE_APP_ID
• CleverTapToken
• APPSFLYER_KEY
• DATADOG_KEY
• MIXPANEL_API_KEY
• CleverTapAccountID

It is, once again, important to note that no reverse engineering, decryption, or tampering was performed to obtain these credentials. Only a right click and a quick perusal of the .plist files in the app bundle’s root directory. While not all of these are sensitive on their own, e.g., BUNDLE_ID, they are dangerous to have lying around in the context of everything else that’s also accessible. While no active attempts were made to exploit these keys due to ethical reasons, based on security best practices, their exposure represents a serious risk.

Timeline

• prior to 19th March
  • keys discovered and report prepared
• 19th March
  • email notifications sent to info@allen.in, allendigital@allen.ac.in, bengaluru@allen.in; physical copy of report handed over to Allen Jayanagar, Bangalore; 15-day notice is provided before public disclosure

• 23rd March
  • report sent via WhatsApp on request of Mr. Rajat Bhargava after a friendly reminder was provided

• 3rd April
  • proceed to public disclosure as stated on the report

Allen was given a fair warning – they chose to ignore it.

Allen was given 15 days’ time to fix this – and they have done nothing. Not even an acknowledgement.

Coda

Allen prides itself on academic excellence, but when it comes to security, they’ve failed their own test.

What should I do now?

• Students: be aware that your data may not be secure. Ask Allen how they plan to protect it.
• Parents: ask Allen why a billion-dollar coaching empire can’t follow basic security practices.
• Everyone else: this is a serious data security issue affecting minors. Spread the word.

To the best of my knowledge, Allen has not taken action to remediate this issue as of the time of publishing. If they have done so without acknowledgment, I welcome updates and will note them accordingly.

Read the full report (PDF) (redacted)
or
Read my personal opinion on this