luke8086

OP here, I just paraphrased the announcement:

> To ease the transition for new users, #NetBSD -current now includes an alternative editor to vi(1) and xedit(1) in its base system, atto(1). https://man.netbsd.org/atto.1

> It is a modeless screen-based editor similar to nano, pico, xedit, or emacs. It is only 48 kilobytes, making it suitable for inclusion in the rescue system.

I think it's fair to call it beginner-friendly, in context of BSD and vi, but maybe indeed it shouldn't be a part of the title.

Yep, possibly.

In case you have DOS installed on the hard drive, you can also use GRUB4DOS [1] - just put gentleos.elf on C:\, run grub.exe, then `kernel /gentleos.elf`. You may first need to comment out any upper memory managers from config.sys. A bit of an academic exercise since the kernel still won't fit into memory.

Btw. feel free to reach out to me on my profile email. I'll be busy with work for the rest of the week, but later I may look for some workarounds to get it running on 2 megs.

[1] https://sourceforge.net/projects/grub4dos/

Thanks, so glad people like the code! I keep looking for ways to make it simpler and more obvious.

> - noticed krn_main() ends with `while (1);` [1]. I would've expected a "schedule" call or something. I assume there's no real busy loop burning CPU, maybe it's never meant to reach this code?

Yeah, `gui_main()` takes over and is not supposed to return, so the code is unreachable. The loop is just an old idiom used in such places (e.g. [1]), though I've now replaced it with a comment and a call to `halt()` to better convey the intention.

> - I'm reminded of the "bare metal OS" when I see one of the apps call `krn_*` functions directly [2].

Yeah... but at least the kernel doesn't call the apps... which it could ;^)

[1] https://github.com/freebsd/freebsd-src/blob/main/sys/x86/x86...

The only AI-generated artifact is the cyberpunk wallpaper from the last photo, I'll admit that :)

Btw. the QEMU screenshots are still in the repo in https://github.com/luke8086/gentleos32/tree/main/doc/appimg

All the photos are real, though it took me *lots* of time to get them somewhat right. The display on T1800 is indeed "challenging". What helped was:

- Letting it warm for a while

- Putting windows in the right places, because each one generates its own artifacts

- Setting background to dark with the white pattern

- Fiddling with the contrast knob and matching it with the right viewing angle

- Using 2x zoom

To be fair, the default photo app of iPhone 16 automatically reduced some of the artifacts. The only post-processing done myself in GIMP was very basic stuff like adjusting white balance, exposure and contrast.

Here you can see a few very quick-n-dirty photos I just took for comparison - https://imgur.com/a/6Xz6vc8

Oh sorry, a quick google check told me PS/1 had 286. 386SX itself should be supported, the monochrome Toshiba on the photo has 386SX/20 with 10MB RAM.

Even on 2MB, you should be able to at least see GRUB, which would tell you that it can't load the kernel. Does it go blank before that? This could mean an issue with either GRUB or the floppy.

Thank you so much! Somehow I haven't heard about Uxn before, but it seems very cool and I'll definitely look into it.

In this context, 32-bit means the minimal requirement. You can absolutely run even the 16-bit version on a 64-bit PC, provided it has BIOS/legacy-boot mode.

It only won't work on modern pure-UEFI systems because that would require writing full stack of USB drivers for keyboard and mouse, and that would be a huge task.

Good catch, the yellow and blue colors are totally inspired by BeOS :D I'm even adjusting the default VGA palette to get the right tints in 16-color mode.

For PS/1 you'll need the 16-bit version from https://github.com/luke8086/gentleos. A floppy image is provided in releases. Note you only need to copy the first 64KB, the rest is just padding for emulators.

Bootloader developers used to be particularly fond of Forth.

For example, for many years the FreeBSD's 3rd-stage loader used FICL (Forth Inspired Command Language) for scripting [1]. It's still supported, although in the recent years it was deprecated in favor of Lua [2].

[1] https://github.com/freebsd/freebsd-src/tree/main/stand/forth

[2] https://github.com/freebsd/freebsd-src/tree/main/stand/lua

This was also my first thought, but looks like it's already designed to be toolkit-agnostic, like NetSurf. So it should be easy to port to fltk or anything else.

  $ ls -1 fixgui_\*.c
  fixgui_cocoa.c
  fixgui_gtk.c
  fixgui_haiku.c
  fixgui_win32.c

Yeah, you're right, sorry for the confusion! I've just rewritten this part to make it more clear.

> Isn't powerd off by default

Sometimes it's on, see https://ftp.netbsd.org/pub/NetBSD/NetBSD-release-10/src/etc/...

> By default only one tty is enabled

Ah, but the rest is getting enabled by the installer, see https://github.com/NetBSD/src/blob/netbsd-10/usr.sbin/sysins...

> NetBSD might have some "bloatware" but _the user must enable it_ first

> Everything is off by default. That is one of the things that makes NetBSD great IMHO

I mean, it gets pretty close to that, and I don't even mind syslogd and powerd, but I'm confused why they enable stuff like postfix, inetd and makemandb without asking. Especially makemandb is pretty intensive on slow machines.

> "I was able to fix it by adding usermod disable wss to the bootloader line."

> Does he mean userconf

Whoopsie, that's on me, good catch!

> Also curious, what is that file manager in the print ?

XFile - https://fastestcode.org/xfile.html

On the other hand, note it only shows 133MB of total mem, rather than 160MB that is installed. I believe the missing 27MB is used by the kernel (the kernel file itself is 23MB) and its data structures.

That being said, I suspect 64MB could be enough for console-mode work, and if you recompiled the kernel without any unused drivers, perhaps you could make it under 32MB.

Yeah, I suspect so!

To be honest, I wouldn't notice this issue at all, if it wasn't for FreeBSD which refused to boot right off the bat. It has a more advanced bootloader though, so perhaps it does some extra sanity checks.

Interesting, I never noticed that 80x24 resolution. Apparently it's been inherited from VT100.

Now 80x25 was the standard text mode of IBM PC, which I'm much more familiar with. I used it because I was testing (over telnet) on some retro ones.

Actually one of the reasons for writing the app was to reduce my compulsive browsing of social media. A feature like this would go in the opposite direction :) But if you really want it, feel free to tinker with the code, it should be pretty straightforward.

Eh, to do it properly, 40 cols and less would require adjusting the whole layout and I just want to keep the code simple. I'm also not sure if the code would be fast enough to run on so old machines, I mean it's Python and not optimized at all. But feel free to fork and tinker if you're interested, at this point it's not really far off.

To be precise, it only assumed 80x25 terminals with 16 colors, which I think fits into some definitions of retro, but I see your point :)

I've just added support for ascii & monochrome modes, and reduced the required screen size to 80x12, which I think is a reasonable minimum for readability.

Would you mind sharing what kind of hardware did you try it on?

Sure, that's how I use it.

In every message you can see its URL in the Content-Location header.

You can press 'o' to select it and open in a browser, and you can select the browser with the BROWSER env var.

Although many terminals have built-in support for simply clicking on URLs, and that's what I usually do.