Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boot Naked Linux

nick.zoic.org

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Boot Naked Linux

#51

Post by a96 »

mschuster91 wrote: post #14
M95D wrote: post #3

I... fail to see the point of running just one process. If it's just a PoC, then: 1) I remember seeing a linux firewall/gateway set up to run with just the kernel, without any userspace at all. Completely unhackable. 2) To print some text or run a simple program, I belive DOS without a memory manager would be even faster. 3) It takes 1s to boot linux, but an ordinary PC takes 10s to get to that linux. Even U-boot on…

> I... fail to see the point of running just one process. It makes sense if you got some legacy piece of hardware that has extremely limited resources, both in terms of RAM and storage. Write your code in Go and you don't even need libc any more.

> extremely limited resources, both in terms of RAM and storage

> Write your code in Go

Re: Boot Naked Linux

#52

Post by a96 »

abrowne wrote: post #36
jorvi wrote: post #32

> .. There was a brief moment in the early 2000s where the newly introduced SSDs made booting quick .. Anyone else reading this and getting the feeling someone is reminiscing about a past they didn't live and thus are seeing it through rose-colored glasses because it didn't exist? In the early 2000s, SSDs had an obscene price tag of ~$1000 per gigabyte, so even an 8GB drive would cost you about $8000. There was nothi…

Or they meant 2010s?

Yes. That's closer to the time mortals started to be able to afford SATA SSD's.

Though there were some disk-on-chip things before, but they were sized in megabytes. I think I might still have a PATA one somewhere. (And you could boot various memory sticks and cards for an even slower experience.)

Re: Boot Naked Linux

#54

Post by M95D »

yjftsjthsd-h wrote: post #13
M95D wrote: post #11

Earlier quoted context omitted.

IIRC, it ran a script as init process that set up the network cards, set up iptables, etc. and then just exited. Kernel would panic (the "init was killed" panic), but the network would still be functional. Automatic reboot on panic was disabled. To reconfigure, the admin would simply reset it and start the system with "init=/something/else" as kernel parameter that booted to a normal userspace.

Oh, clever; I didn't know you could make Linux panic but keep running.

Configure it with CONFIG_PANIC_TIMEOUT=0, or add "panic=0" to kernel parameters, or "echo 0 > /proc/sys/kernel/panic".

Re: Boot Naked Linux

#55

Post by nottorp »

saghm wrote: post #45
nottorp wrote: post #33

Earlier quoted context omitted.

Hmm LLM hype aside, remember the first writing system (Grafitti) for PalmOS? Change the way you write to obtain much better recognition.

Sadly, I don't remember it. I was born in the early 90s, so although I remember PalmPilots being a thing, I never had one

Back then handwriting recognition of what you scribbled with a stylus was all the rage. But the PDA CPUs weren't good enough to recognize real handwriting predictably.

So Palm came up with a very simplified all caps alphabet that the user learned how to write instead. And had 98% recognition rate because it was designed for what the CPU could do.

https://en.wikipedia.org/wiki/Graffiti_(Palm_OS)#/media/File...

Re: Boot Naked Linux

#56

Post by saghm »

nottorp wrote: post #55
saghm wrote: post #45

Earlier quoted context omitted.

Sadly, I don't remember it. I was born in the early 90s, so although I remember PalmPilots being a thing, I never had one

Back then handwriting recognition of what you scribbled with a stylus was all the rage. But the PDA CPUs weren't good enough to recognize real handwriting predictably. So Palm came up with a very simplified all caps alphabet that the user learned how to write instead. And had 98% recognition rate because it was designed for what the CPU could do. https://en.wikipedia.org/wiki/Graffiti_(Palm_OS)#/media/File...

Interesting! I can sort of see the value of that as a short-term solution to the hardware not being ready for something more robust.

I guess my main objection to having to change the way we write for LLMs is that the writing isn't just an input method that we use to generate the "real" thing we want (like the handwriting system that you describe, where it sounds like the intermediate handwriting was basically thrown away once it was properly read into text), and more importantly, the goal wasn't to write text for other humans but for CPUs; no one else was reading the intermediate input coming from the stylus. My concern is that if we change the way we write for other humans because we're concerned about whether LLMs will understand it properly, we're essentially saying that the LLM audience is more important than the human audience, or that we'd prefer to make the human audience adapt than improve the technology to be more human-friendly. I don't think either of those would be good things.

Re: Boot Naked Linux

#58

Post by mschuster91 »

a96 wrote: post #51
mschuster91 wrote: post #14

Earlier quoted context omitted.

> I... fail to see the point of running just one process. It makes sense if you got some legacy piece of hardware that has extremely limited resources, both in terms of RAM and storage. Write your code in Go and you don't even need libc any more.

> extremely limited resources, both in terms of RAM and storage > Write your code in Go

When you ship containers or to ultra-embedded, that one actually matters. If done right you can ship a container that only contains your application's binary, not a single byte more.

Re: Boot Naked Linux

#59

Post by bizzletk »

mschuster91 wrote: post #58
a96 wrote: post #51

Earlier quoted context omitted.

> extremely limited resources, both in terms of RAM and storage > Write your code in Go

When you ship containers or to ultra-embedded, that one actually matters. If done right you can ship a container that only contains your application's binary, not a single byte more.

> Write your code in Go

Container not even needed, there's projects like Tamago [0] that let you run your golang application without even needing an OS

[0] https://github.com/usbarmory/tamago

Post reply on HN