“A tiny 32 bit kernel written in Rust. I was inspired to download Rust and try to do this after seeing zero.rs – a stub that lets Rust programs run almost freestanding. It paints the screen bright red and then hangs. That’s it.”
“A tiny 32 bit kernel written in Rust. I was inspired to download Rust and try to do this after seeing zero.rs – a stub that lets Rust programs run almost freestanding. It paints the screen bright red and then hangs. That’s it.”
That makes wonder where to draw a line between osnews and osdev :/
The github was setup just 5 hours ago, is this news here to provide traffic to the project ?
Kochise
… how long will it take before the first pull request to make the screen blue appears
That had better be configurable. I’ve already engineered my workflow around a red screen.
You just can’t please everyone. One day it’s old news, now it’s too new…
Maybe if it was something to be excited about. In any way. At all.
It paints the screen red and stops. Wow. Stop the presses, we got a scoop.
It is, it is another baby step to show the geek community another OS done in safe systems programming languages.
When it does something more useful than painting the screen red I’ll agree that it’s exciting. Until then it’s really not and I don’t see why it would warrant a news item.
The irony being that two of the three functions in main.rs are marked unsafe.
Thanks to them being marked unsafe, it is easy to locate and validate what the code is allowed to do.
In C every line in the source code is unsafe.
Thanks to them being marked unsafe, it is easy to locate and validate what the code is allowed to do. [/q]
Holy Roman Empire!
I could be wrong, but I assume that refers to disabling the garbage collector (a la Modula-3).
No, it’s not that: http://static.rust-lang.org/doc/rust.html#unsafe-functions
So basically, not much different to raw pointer operations in C.
Correct, but it makes possible to forbid pointer trick modules in security risk scenarios.
For example, you cannot run unsafe .NET code in IIS, or unsafe Go code in Google App Engine.
Similar unsafe blocks are available in D, Ada, Modula-3 and the Oberon language family.
The whole point is that unsafe operations are only allowed for code that needs to deal directly with the hardware, everywhere else you can you use type safe language constructs.
This allows an increase in the security of the generated code via compiler switches or OS rules.
Of course, this relies on the fact that you cannot change the generated Assembly code, by having the appropriate security access in place.
The basic point I’m getting at is that in a kernel, I’d be surprised if at least 50% of all the code isn’t unsafe (or even just raw assembly). Because the nature of the beast is that you’re manipulating raw memory and hardware at its very lowest level.
Checked & safe languages like Rust are nice, but the idea that using such a language for a kernel suddenly makes the kernel less liable to errors is largely unfounded. They can eliminate certain types of errors, but not the errors that are the most likely to bite you in the ass when you’re in ring 0.
Having said all that I’d love to see someone expand on the concept and perhaps write a proper kernel in Rust.
Edited 2013-05-28 15:31 UTC
I advise you to inform yourself of operating systems done in such languages, in case you find the subject interesting.
Lilith was done in Modula-2. AS/400 also had a part of Modula-2 on its kernel on the first versions, but it has been replaced by C++ in more recent versions.
A very good reading about such systems is the book Niklaus Wirth wrote about how Native Oberon was designed, freely available from Zurich’s university:
http://www.ethoberon.ethz.ch/WirthPublProjectOberon.pdf
It was quite usable system back in the late 90’s.
Or the Mirage OS done by Citrix and the Xen Project,
http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/mirage.html
Back when C appeared, kernel safe languages were already starting to be explored, but like everything in computing, many concepts take decades before they become accepted in the industry.
Granted, others never managed to mostly due to the famous “Worse is Better” axiom.
This is exactly the kind of thing I like to see on here amongst all the other articles. Sure the results aren’t ground breaking, but hearing about someone doing something like this in a language i”ve never heard of is definitely of interest.
Hi,
Agreed (in theory).
I’m not sure what they’re doing in Rust; but the boot loader and the code to paint the screen red is all written in assembly.
– Brendan
Ah I didn’t dig through the source yet, but I have been reading up on Rust as a result of it.
The clearing to red seems to be written in Rust: https://github.com/charliesome/rustboot/blob/master/main.rs
Edited 2013-05-27 05:26 UTC
Hi,
You’re right – the assembly I saw ( https://github.com/charliesome/rustboot/blob/master/runtime.asm ) fills the screen with blue smiley faces on a black background(character 0x01) before the Rust code fills the screen with black null characters (character 0x00) on either a light pink or flashing red background (depending on how the video card felt like handling the attribute, as this isn’t setup properly).
Of course this assumes that the firmware left the direction flag clear – the assembly “fill the screen” code may clear nothing and simply trash the EBDA instead, as there’s no “CLD” instruction anywhere. It also assumes that the video mode actually is 80*25 text mode (I’ve seen cases where it’s not).
– Brendan
Only the boot loader is written in Assembly, like in any OS.
Have you read the code at all?!
Hi,
Except for https://github.com/charliesome/rustboot/blob/master/runtime.asm . Have you read the code at all?!
– Brendan
That can be considered as part of the boot loading process, just clearing the screen before calling the real OS, like any other boot loader.
Do you understand Assembly?!
You two enjoying yourselves?!
Well, I am used to flamewars since the BBS days, so I can carry on for a while still.
Hi,
Yes. See those labels (abort, memcmp, memcpy, etc)? They’re unimplemented run-time support that Rust probably needs to compile. If the Rust code wasn’t trivial I’d expect that these would need to be implemented.
While we’re on the subject of “if the Rust code wasn’t trivial” and “real OS”..
For a real OS you’d want to setup the video mode properly, which would require assembly. You’d also need to get a memory map from the BIOS, which would require assembly. You’d need to remap the PIC chips, which would require assembly. You’d need to enable A20, which would require assembly. You’d need to scan physical memory for things (e.g. ACPI tables, etc), which would require assembly.
Then; you’d start the other CPUs, which would require assembly. Next comes memory management and scheduling, which typically involves atomic operations and/or lock-free/block-free algorithms, which would require assembly. Then there’s the task switching code, which would require assembly. Of course there’s also exception handling, IRQ handling, etc; which would require assembly.
Can you see a pattern here? If the “kernel” wasn’t a trivial joke, you’d find Rust being used for glue and not being used for anything that’s actually important; especially once you start micro-benchmarking and trying to get performance/scalability close to other OSs.
So; what does this trivial example, with its ~20 lines of Rust and its ~100 lines of assembly, actually show? It shows that assembly is so awesome that it can make Rust “sort of usable”.
– Brendan
I disagree with that conclusion. What OSs mainly written in C or C++ show is that it is possible to write most of an OS’ logic in another programming language, and only keep Assembly for the few operations that actually access hardware directly. Sure, these Assembly parts are vital, but so is the logic code: it is where all the interesting stuff is decided, and what differentiates one OS project from another one.
Of course, we can argue that some languages are better-suited for OS development than others. As an example, any language with heavy runtime requirements, or nondeterministic performance due to garbage collection, is probably a very poor fit unless such mechanisms are optional as in C++.
That may be the case or not in Rust, but you have not actually proven this point so far. In fact, the author of this code hasn’t either, he has only shown that Rust code which does something trivial like moving memory around may have little actual runtime requirements, which is already something but not enough to showcase it as a good language for OSdeving.
Also, the fact that he has to define abort, memcmp, memcpy, malloc and free for the code to compile worries me. It means that some part of the OS binary somewhere requires these primitives, and will cause a random crash if it ever attempts to run them. But perhaps that’s a result of someone not properly reading his compiler’s manual…
So in summary, I agree with you regarding the feeling that this code does little to prove Rust’s suitability for OS development, but I disagree with the arguments you use to prove your point.
Edited 2013-05-28 06:28 UTC
And Object Pascal, Modula-2, Ada, …
10 years ago no one would believe you could do something like Unreal in JavaScript.
I think it is also a question how much the industry is willing to invest in such topics.
I think he just had them as stubs, because it was just a proof of concept. Of course in a real kernel similar functions need to be defined.
Indeed, many languages are potentially suitable for OS development although some are more suitable than others.
From my short look at it, Ada in particular could be a very interesting choice for OSdeving. Too bad so little Ada OS projects have survived to this day…
Then again, gamers have also come to expect quite a bit more than Unreal from games these days.
The industry seems to be satisfied with kernels from the 80s and the 90s and to focus on higher layers of the OS stack these days.
So if innovation is to come in the realm of low-level OS design in the next decades, it will probably be either from academia, hobbyists, or companies’ fundamental research departments. Not from a team of people which actually have the goal of producing a product that can be sold.
Sure, but is there a subset of Rust which is formally guaranteed in writing to work forever without calling these functions ? Otherwise, these functions cannot safely be implemented in Rust, which noticeably means that the whole memory manager has to be written in another language like Assembly or C.
That would be a serious blow to Rust’s suitability as an OS development language.
I fully agree. My point is that technology improves when there are people willing to invest research on them.
Actually the industry is happy using OS that they can get for free, instead of investing in OS research.
This is the main reason why outside academia, Microsoft Research seems to be the only visible OS vendor R&D department doing OS research.
It is no different than C in that regard.
You cannot do an OS in ANSI/ISO C without Assembly.
So I don’t see any issue if you really need to implement a few tiny functions in Assembly, just like you need in C anyway.
I do think that there is such a thing as fundamental design flaws, which will always make a language like Javascript suck at performance-constrained tasks as compared to languages which have actually been designed for performance.
Of course, not every task requires state of the art throughput, which is why there nevertheless is a place for such languages. If this weren’t the case, one has to hope that Python and Javascript wouldn’t be where they are today.
Of course, but there is a limit to what can be done this way. If your business requires spreading or selling an OS in and of itself, then you better try to give that OS some advantage above others. My point was, at this point in time, the battle seems to happen on higher-level functionality rather than low-level one.
Perhaps this balance is to change at some point, though, when someone will figure out that phones with laggy input and piss poor battery life are annoying and look up past research on embedded operating systems.
I agree with what you say in principle. However, a memory manager that is worth something isn’t just a few tiny Assembly functions. It takes a couple thousand lines of C++ code to implement it. You don’t want that kind of large library to be written in Assembly unless you are forced to.
C, C++ and Ada are three examples of languages which allow you to do implement memory management in a controlled subset of your code, without making assumptions about what your compiler is doing and will be doing in the future. It remains to be seen if Rust is part of that family too.
Edited 2013-05-30 06:06 UTC
You mean like C?
Last time I checked you are doing exactly the same, glue between Assembly code that interacts with the hardware.
It shows that Rust also provides a very thin runtime requirements and with a bit of Assembly it is possible to produce executables that execute directly on hardware.
This is no different from many systems that execute directly on embedded hardware without an underlying OS, for example.
It can also be considered the starting point of any OS, if the next Linus now would pick this example and developed it further.
Do a story on Temple OS! http://www.templeos.org
Since we’re speaking of other OS, let’s remind everyone about open-source and really usable incarnations :
http://visopsys.org/
http://monaos.org/
https://www.haiku-os.org/
…
Spot the differences ?
Kochise
ã¨ã‚ã‚‹OS ( http://toaruos.org ) might belong on that list too.
Edited 2013-05-27 11:18 UTC
I mean no offense by this, but it’s hard to take the project seriously with all the religious stuff. I know it’s your prerogative, but it just doesn’t belong in a basic system tool. Sorry.
Linux is for atheists, openly.
At least Linux doesn’t lose all your files and does unspeakable things to child processes and excuses that with “Linux works in mysterious ways”.
Root is God.
libbible.so
Kochise
No, that’s Eric Clapton. Or was it Lemmy?
Yes, I know that there are a lot of cool niche operating system, and yes I know that TempleOS has some rather… unusual religious content, but it’s still a very impressive undertaking for a single person project.
Stop criticizing TempleOS’s comments, and instead take a look at the actual project. It’s a pretty neat little OS, with real, interesting ideas. I for one would gladly welcome an OSNews story on TempleOS. The fact that it’s written by an OSNews member is another plus.
Whatever you may feel about TempleOS’s religious views, TempleOS is several orders of magnitude more impressive than this snippet of code that paints the screen red. TempleOS is a real, functional, and unique simple OS.
Agreed.
If he wants us to take a look at his project rather than his comments, he can submit an article.
He chooses to make ridiculous comments, and given the ability to comment on comments (called replies), the subject of a comment is thus open to comment as well.
If his submitted article then continues to reference the subject of his comments, then people rightly have a right to comment on those too.
Either that, OR he has to make absolutely clear that no one is allowed to comment on his nuttiness and that he is beyond question and infallible.
Won’t that be fun?
Blatant self-promotion and religious craziness aside, sure why not? At least it does more than paint the screen red and hang.
TempleOS http://www.templeos.org has been 64-bit since 2007. Haiku is still 32-bit.
God said 640×480. Mine has no networking. It is not a primary operating system–no point being redundant. It is not trying to be like windows or Linux but a modern souped-up 64-bit C64.
Mine has a new language. Mine is very different and innovative.
Linus did not make a compiler. Haiku did not make a compiler. Only I have made a 64-bit compiler. I made an awesome new language — Holy C.
http://www.templeos.org/Wb/Doc/HolyC.html
If your OS is not radically different, for a niche or purpose, it’s pointless.
Different drivers for all hardware is a losing strategy. It is pointless to make 5 GPU drivers when there are 30 GPU drivers you need and more coming all the time. Without GPU support, only 640×480 is good. See my video of my FPS and flight simulator. I’ve spent ten years writing 130,000 lines of code.
http://www.templeos.org/Wb/Accts/TS/Wb2/Games.html
Edited 2013-05-27 11:09 UTC
No, God said 1200×1600 but is willing to forgive other resolutions as long as the screen is in portrait mode. God also specified a GUI with context menus, red function keys on the keyboard and a trackball or joystick to move the cursor (users of TrackPoints are perverts and there’s a special hell reserved for those nipple twiddlers). The CPU must be pure 32-bit (which some interpret as not offering any alternative “modes”) and memory limitations must be overcome using bank switching only. The use of a swap file/partition is unclean.
Regarding the OS, it must have been programmed entirely in assembly language and/or Pascal (or blessed derivatives) and the video driver must not have any support for square or landscape screens.
God said all of this.
You can pretend as much as you want “God said this, God said that…” remember what have been made/done in the name of God. You can name whatever to be Holy, but since you have no legitimation (not a priest or anything else of that kind) you have specifically not right to do so.
http://www.nbcmiami.com/news/Anna-Pierre-North-Miami-Mayoral-Candid…
Kochise
Edited 2013-05-27 12:58 UTC
Oh, please! You atheists love evolution. USSR and China are atheist and starved lots of people. “Thou shall not covet” comes from God. Communism comes from atheists.
God said war was “Servicemen Competing”.
Love neighbor as self means you can kill if you are willing to die. Jesus said, “live by the sword, die by the sword.”
What would teen-age male video games be like if there had never been war? Praise the Creator that we are not bored.
Randomly crack-open the nearest book after praising the Creator and God will talk.
Edited 2013-05-27 14:11 UTC
Can’t tell if sarcastic
or just crazy.
I seriously can’t tell if you are truly deranged or just pulling our legs.
The former. I recall this loon plaguing the osdev forums a few years ago, when his incarnation was still called LoseThos (I guess God hasn’t ordained a proper name). His code is as messy as his thinking, and the design of his OS is, as I recall, quite bad. He seemed harmless though, if not terribly annoying.
He wrote an OS just to troll us, give the guy an award.
If the FSF and other fundamentalists could get their hands on this guy though…
Jesus was such a commie-hippy…
(and actually, most places which had any problems with “communism” are “old Christian” …probably not a coincidence; most party members were closet Christians, anyway; and there’s no phenomena of unbaptised generation)
That’s not entirely true…
http://haiku-files.org/unsupported-builds/x86_64/
I think He did say that, in 1987.
But now God says 640×480 looks like butt on his 27″ wide screen monitor.
😉
1) The OS doesn’t need GPU drivers, which makes it possible and open.
2) No gore. A return to innocence.
3) There is not an ART arms race for developers. Games can be made by tiny-companies with programmer art. A modern game is like a movie, normally.
—-
God just said I’m Moses and you are grumbling like this story in the Bible after liberated from slavery and wandering in the desert:
http://www.biblegateway.com/passage/?search=numbers%2011&versio…
Edited 2013-05-27 20:08 UTC
Kudo this, but there is open GPU around, so it’s not much of a trouble. You decided to stick to 640 mainly because of the performance boost of having so little video memory to update.
Let’s return to punch cards and LED matrix display.
An OPERATING system is made to OPERATE the system. If it’s just running some demos and having little to no usage, then why investing time into this ? For fun ? Then don’t misname it an OPERATING system.
Even though the Commodore 64 had only really little power, it featured an embedded basic interpreter that inherently made it a full fledged OPERATING system because you could do almost everything you wanted from scratch, even without downloaded/runnable applications, you would just have to code them.
Nowadays, with a bare iOS, Android or Windows 8 “OPERATING” system ? Naaaaahhh…
In that your OS is an OS, but with so many limitations hardware wise that a VESA 386 based computer in protected mode would be far enough. The x86_64 is absolutely unuseful in your case.
Your remaining sentences : Blablablahhhh…
Kochise
In a way, that’s what OLED displays are
…but maybe someone can explain to me how this code
https://github.com/charliesome/rustboot/blob/master/main.rs
constitutes an operating system?
Well, looks like there’s a few asm files there that basically bootstrap an environment that can load/run the rust runtime – at which point the contents of the .rs files are executed.
It’s really not an operating system so much as it’s proof that you can boot directly into a rust runtime environment without another OS… whether that rust runtime can then actually utilize all the hardware present on the machine is perhaps a more important question.
I know nothing about Rust… so <shrug>
I checked the Github page. Nowhere did it say that it is an operating system.
Think of that as the init process, the only “userspace” component of this project. Instead of forking new processes to run system services like a real OS, it just paints the framebuffer red.
The actual “kernel” is defined in runtime.asm, where you can see the syscalls declared, although the only even remotely meaty part of this project is loader.asm, which loads a rust executable into a virtual address space.
DOS was horrible. Every minute we had to press a reset button when it hung. We could only type for 30 seconds before some virus got us. The Commodore 64 was even worse.
Edited 2013-05-27 17:13 UTC
The Commodore 64 was the most sold personal computer ever. There’s probably so many wrong people around the globe, who knows…
Kochise
That depends on what you meant by “computer,” “personal,” “sold,” and “ever.”
I dunno, perhaps not the same definitions as yours. Let’s compare our respective dick-tionaries…
http://www.omg-facts.com/Technology/The-Commodore-64-Is-The-Best-Se…
http://www.retrothing.com/2008/10/commodore-64-th.html
http://www.pcworld.com/article/152528/comm64.html
…
Kochise
I was one of those, but I can’t remember having to reset it every 30 seconds (games used to take 30 minutes to load from cassette!) or having problems with a virus.
It sure had better flight simulators than TempleOS.
I have bad news for you. This is not a failure with DOS, it’s a PEBCAK.
PEBKAC
Sr71 speed check story:
http://www.econrates.com/reality/schul.html
Here’s My MemSet 🙂 It’s built into my compiler!
http://www.templeos.org/Wb/Compiler/BackEnd.html#l4889
Seriously, WTF is it about OSNews that attracts so many fanatical/fundamentalist, mentally-unbalanced and/or semi-coherent nutjobs?
First there was Moulineuf:
http://www.osnews.com/user/uid:266/comments
Then Mapou:
http://www.osnews.com/user/uid:7318/comments
Then ParadoxUncreated:
http://www.osnews.com/user/uid:20890/comments
And now Mr. TempleOS. Even if you strip out all of the religious kookery, his posts are the equivalent of going to a car enthusiast forum and endlessly bragging about how your homemade unicycle is vastly superior to all automobiles.
Is it really that many, compared to all the other blogs or forums?
Maybe they’re just visible here a bit more because we don’t have that much traffic going on.