[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]

λ - programming

/lam/bda /lam/bda duck
Name
Email
Subject
Comment
File
Password (For file deletion.)

BUY LAINCHAN STICKERS HERE

STREAM » LainTV « STREAM

[Return][Go to bottom]

File: 1435373031905.gif (498.22 KB, 500x281, tumblr_mxhwchMD6k1skyf48o1….gif) ImgOps iqdb

 No.7062

So, I've been working on developing my own i686 kernel, and I thought I would see if anyone else has had a go at operating system development. If not, who is insane enough to want to try?

My main issue at the moment is getting interrupts, well, working. Fun stuff! I would like to see what the rest of /λ/ thinks.
>>

 No.7063

>>7062
That's very interesting. What are you writing this in?
FORTH?
C?
Assembler language?
Something else?

>>

 No.7064

>>7063
I'm writing it in a mix of C and NASM style assembler.

It's quite fun, NASMs macros make a few things much simpler than they would be, like interrupt handlers for instance.

>>

 No.7066

Can you share the source?

>>

 No.7068

File: 1435416799788.png (9.45 KB, 720x416, QEMU_001.png) ImgOps iqdb

>>7066
If people are really that interested I could, I would like to get it to a proper state of completion though. But if /λ/ wants to see it sooner than I can do that.

(Image Related)

>>

 No.7139

>>7062
What kind of kernel is it? Monolithic? Modoular? Micro? Exo?

>>

 No.7144

>>7139
It is planned to be a monolithic kernel, at least initially.

>>

 No.7145

File: 1435556607717.png (16.99 KB, 720x423, telos.png) ImgOps iqdb

I started mine a couple years ago after finishing an operating systems course. It has a really basic, read-only ext2 implementation (and a read-write tmpfs-like FS as well), a bunch of POSIX stuff like signals, timers, etc. and I recently ported binutils+gcc+newlib so I have a proper user space dev environment now. My next goal is to get enough of POSIX implemented to port a real shell.

>>

 No.8243

Bump

I would like to see more on this topic

>>

 No.8251

I've been interested in the front-end of OS development for a while. Bump.

>>

 No.8263

My current project is a simple OS.
The thing about it is that it won't use the usual C ABI, but something a bit different.
bump.
as a side discussion, would you agree that M$ windex is an evolutionary dead end in OS design?

>>

 No.8264

>>7062
What specific problem are you having OP?

>>

 No.8272

>>7145
Ha, nice, The Talos Principle OS :P

>>

 No.8838

>>8263
>would you agree that M$ windex is an evolutionary dead end in OS design?
Yes. And I would also agree that POSIX is a dead end too. I never understood why so many people who start creating their OSs try to implement POSIX. That's been done. If we want to innovate we need to step away from that. So many of the POSIX designs are extremely crusty. Android does some things more modernly than POSIX (hell, even Windows does); Such as running each program as its own user so as to isolate programs from each other. One can set this up, but most distros don't, for instance, run the web browser as its own user which belongs to the "internet" group (along with only the programs that can connect to the net). The principal of least privilege has been around for decades, but few if anyone is using it in such a unilateral fashion. Imagine if every program could run in a BSD Jail. If the OS was built from the outset with a permission / capability system rather than every terminal having a full suite of commands available then one wouldn't have to suffer them breaking and configuration headaches when you take the commands away. Programs could specify which commands / features they need at install time (see: groups), but /usr/bin was never designed to be used that way.

Also Consider STDIN / STDOUT / STDERR. Here we have "standard" streams of unstructured data, typically of the textual variety. Windows drops these in favor of other IPC functionality. However, even AmigaOS had a more rich IPC functionality built in where programs could attach to "ports" on each others memory spaces directly. Android has "Intents" which is an interface to standardize interprocess communications and give rich structured IO and RPC between applications. A next gen OS could take all these ideas and implement them down at the lower level (rather than up in a VM). Rather than the C mindfuckery of not knowing how big an int is, the language could instead provide standardization via explicit type sizes (like uint32_t, etc) and byte orders such that IPC could occur transparently across a network. That same IPC mechanism could also be used in the OS threading model instead of the rather cumbersome pthreads single result system. My point is: POSIX is ancient.

Furthermore, there are some great design ideas such as in MULTICS which are being "rediscovered" such as how to build out distributed storage and computing, processing as a service. The MULTICS system could hotswap in nodes, to upgrade one took a chunk of nodes offline, built the new system, then rejoined the rest to it. Unix is literally a "joke", named to thumbed ones nose at the "over-engineered" MULTICS system... meanwhile people are trying to shoehorn POSIX into the design of MULTICS without even realizing it.

Those who don't understand MULTICS will emulate it, poorly. Don't believe me? Just look at IoT (Internet of Things) -- on POSIX? All of my why?

Not that it matters, just gets old hearing people rag on Windows when *nix isn't really any better of a design. Both designs are monolithic legacy crap OSs not even built for the way we use tech today. I should be able to stop right here, push a button and continue typing on my tablet where I left off. All of my idle devices should be able to give the device I'm using cycles. But noooo, that would be too much like MULTICS.

>>

 No.8839

>>8838
Yes

> I should be able to stop right here, push a button and continue typing on my tablet where I left off

http://www.loper-os.org/

>>

 No.8841

>>8838
Look into Common Lisp. A Common Lisp process starts off with several standard streams open, which can be used for querying the user, sending Lisp objects elsewhere, network services, etc.

UNIX is not only a horrible design, but it has worked to actively destroy several interesting aspects of computing. We have RISC because it was discovered that C compilers didn't use most of the instructions given to them. Now hardware gets increasingly less intelligent to bend to UNIX better, even though UNIX still can't take good advantage of it.

We can also thank UNIX for contributing to the death of most operating systems and alternative hardware that used to exist.

Have you ever read the UNIX Hater's Handbook? It goes into more detail and is a great read. Funnily enough, UNIX zealots haven't changed much over the decades.

>>

 No.8856

File: 1440712647737-0.png (7.38 KB, 800x600, samuraiBL.png) ImgOps iqdb

File: 1440712647737-1.png (18.13 KB, 800x600, samuraiBLservices.png) ImgOps iqdb

>>7062
I've been writing this shell~mod for an old machine I bought, so it's spanning a modern pc while being writable from floppy. Check out more here v i r t u a l m e c h dot i n f o

>>

 No.8858

>>8856
oh you're that guy from /cyber/, hello!!

>>

 No.8859

>>8856
Those colors makes my eyes bleed....

>samuraiBL.png


I'm not gonna lie, I thought `Boys Love` at first.

Other than that soykaf color scheme, it looks nifty, what's it written in? (because lain knows I'm not going to your site)

>>

 No.8863

>>8838
> I should be able to stop right here, push a button and continue typing on my tablet where I left off
>>8839
> http://www.loper-os.org/

You can do that with Skullcode, including:
> idle devices should be able to give the device I'm using cycles.

Accessing a node with a browser should detect the HTTP and emit a VM in HTML/JS with a clone of the current environment that's running on the remote .exe. For the the tablet it would probably be better to install the .apk then point it at your nodes.

>>

 No.8869

>>8858
ayy
>>8859
T5100 Orange Pulp

>>

 No.8880

>>8838
> However, even AmigaOS had a more rich IPC functionality built in where programs could attach to "ports" on each others memory spaces directly.

It appears some FreeBSD folks agree:
http://www.nextbsd.org/jordan-hubbard-visits-bafug/

> The talk also briefly covers why mach ports are extremely useful in some cases and no UNIX IPC primitive is an adequate substitute.


What's old is new again!

>>

 No.8888

>>8880
>What's old is new again!
Rediscovering older systems and research to discuss current inadequacies is a UNIX tradition.

>>

 No.8891

https://news.ycombinator.com/item?id=10138447

So what is a better (in terms of design) alternative to Unix and Windows?

Minix? HURD? Some Lisp Machine from Stanislav? And even then, x86 is very complex, and has warts too. What will replace x86?

>>

 No.8895

>>8891
>Minix
dead
>HURD
soykaf and gnu infested
>What will replace x86?
ARM, not that the hardware designers aren't doing their best to make it just as crusty as x86 as fast as possible

everything is shit, you just have to pick the soykaf that stinks the least

>>

 No.8896

>>8891
I don't feel like reading the ycombinator link.

>So what is a better (in terms of design) alternative to Unix and Windows?

Well, there's a plethora of now dead systems to look at. There are also new systems being developed, such as templeos.
There are still people making simple Forth environments.

>Minix? HURD?

Both UNIX. HURD may be nice once it's finished. So much time and money goes into stupid soykaf like docker to poorly tack functionality onto the Linux kernel. You would get better encapsulation with HURD, which works at the kernel level and can run itself recursively.
Despite this, you have people talking about docker like it's some great innovative milestone. From what I've seen, it's stale shit.

>Some Lisp Machine from Stanislav?

You can still buy older Lisp machines. A Lisp machine would be nice.

>And even then, x86 is very complex, and has warts too. What will replace x86?

MIPS, ARM, and RISC-V are decent contenders.

You're forgetting calculators:
http://www.loper-os.org/?p=384

HP calculators were elegant little machines.

>>

 No.8969

>>8856
This thing looks sickk!

>>

 No.9230

File: 1441683309215.jpg (52.37 KB, 215x320, os3ep.jpg) ImgOps Exif iqdb

Want more inspiration?

http://pages.cs.wisc.edu/~remzi/OSTEP/

Operating Systems: Three Easy Pieces

>>

 No.9241

>>8895
> everything is shit, you just have to pick the soykaf that stinks most alike you own shit, so your nose would adapt faster.
ftfy

>>

 No.9507

For those looking to start playing with OS dev, I started reading this and it looks good so far for beginner.

http://littleosbook.github.io

>>

 No.9618

>>9507
I've read that, it's okay as far as beginner books go, thanks for sharing.

>>

 No.10579

File: 1444968384006.jpg (21.07 KB, 480x360, 1435892680484.jpg) ImgOps Exif iqdb

I'm currently reading Modern Operating Systems by Tanenbaum and it's been really fun. Kinda makes me want to read more about this when I finish it.

>>

 No.11416

I've been working on my os for a little over a month and have reached the point that I am ready to make a mmaped heap for allocation.

I have decided to use a linked list of bins. These bins will hold the free memory for the system and be ordered by sizes. (i.e. bin1=1B-4B, bin2=5-8B, etc...) These bins will consist of a doublylinked linst of the free memory in address increasing order. I am wondering if this sounds sane or even plausible. Any thoughts?

>>

 No.11418

>>10579
This stuff is excellent
http://www.projectoberon.com/
I disliked the way that Tanenbaum handwaves early on in the book making OS's with languages that have GC



Delete Post [ ]
[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]