Linked by Thom Holwerda on Sun 26th May 2013 18:48 UTC
OSNews, Generic OSes "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."
Order by: Score:
The sad kind of news
by Kochise on Sun 26th May 2013 19:35 UTC
Kochise
Member since:
2006-03-03

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

Reply Score: 0

So...
by Valhalla on Sun 26th May 2013 20:01 UTC
Valhalla
Member since:
2006-01-24

... how long will it take before the first pull request to make the screen blue appears ;)

Reply Score: 8

RE: So...
by sparkyERTW on Mon 27th May 2013 11:57 UTC in reply to "So..."
sparkyERTW Member since:
2010-06-09

That had better be configurable. I've already engineered my workflow around a red screen.

Reply Score: 8

Comment by BBAP
by Bringbackanonposting on Mon 27th May 2013 03:15 UTC
Bringbackanonposting
Member since:
2005-11-16

You just can't please everyone. One day it's old news, now it's too new...

Reply Score: 6

RE: Comment by BBAP
by Soulbender on Mon 27th May 2013 03:28 UTC in reply to "Comment by BBAP"
Soulbender Member since:
2005-08-18

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.

Reply Score: 2

RE[2]: Comment by BBAP
by moondevil on Mon 27th May 2013 06:12 UTC in reply to "RE: Comment by BBAP"
moondevil Member since:
2005-07-08

It is, it is another baby step to show the geek community another OS done in safe systems programming languages.

Reply Score: 4

RE[3]: Comment by BBAP
by Soulbender on Mon 27th May 2013 06:44 UTC in reply to "RE[2]: Comment by BBAP"
Soulbender Member since:
2005-08-18

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.

Reply Score: 2

RE[3]: Comment by BBAP
by Vanders on Mon 27th May 2013 16:07 UTC in reply to "RE[2]: Comment by BBAP"
Vanders Member since:
2005-07-06

another OS done in safe systems programming languages.

The irony being that two of the three functions in main.rs are marked unsafe.

Reply Score: 2

RE[4]: Comment by BBAP
by moondevil on Mon 27th May 2013 17:04 UTC in reply to "RE[3]: Comment by BBAP"
moondevil Member since:
2005-07-08

"another OS done in safe systems programming languages.

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.

Reply Score: 2

RE[5]: Comment by BBAP
by kwan_e on Tue 28th May 2013 01:44 UTC in reply to "RE[4]: Comment by BBAP"
kwan_e Member since:
2007-02-18

"[q]another OS done in safe systems programming languages.

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. [/q]

Holy Roman Empire!

Reply Score: 2

RE[4]: Comment by BBAP
by Rugxulo on Mon 27th May 2013 18:56 UTC in reply to "RE[3]: Comment by BBAP"
Rugxulo Member since:
2007-10-09

two of the three functions in main.rs are marked unsafe.


I could be wrong, but I assume that refers to disabling the garbage collector (a la Modula-3).

Reply Score: 1

RE[5]: Comment by BBAP
by Vanders on Tue 28th May 2013 11:45 UTC in reply to "RE[4]: Comment by BBAP"
Vanders Member since:
2005-07-06

No, it's not that: http://static.rust-lang.org/doc/rust.html#unsafe-functions

Unsafe operations are those that potentially violate the memory-safety guarantees of Rust's static semantics. Specifically, the following operations are considered unsafe:

Dereferencing a raw pointer.
Casting a raw pointer to a safe pointer type.
Calling an unsafe function.


So basically, not much different to raw pointer operations in C.

Reply Score: 2

RE[6]: Comment by BBAP
by moondevil on Tue 28th May 2013 14:34 UTC in reply to "RE[5]: Comment by BBAP"
moondevil Member since:
2005-07-08

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.

Reply Score: 2

RE[7]: Comment by BBAP
by Vanders on Tue 28th May 2013 15:20 UTC in reply to "RE[6]: Comment by BBAP"
Vanders Member since:
2005-07-06

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

Reply Score: 2

I clicked it, I liked it
by LaceySnr on Mon 27th May 2013 04:56 UTC
LaceySnr
Member since:
2009-09-28

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.

Reply Score: 3

RE: I clicked it, I liked it
by Brendan on Mon 27th May 2013 05:03 UTC in reply to "I clicked it, I liked it"
Brendan Member since:
2005-11-16

Hi,

This is exactly the kind of thing I like to see on here amongst all the other articles.


Agreed (in theory).

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.


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

Reply Score: 4

RE[2]: I clicked it, I liked it
by LaceySnr on Mon 27th May 2013 05:24 UTC in reply to "RE: I clicked it, I liked it"
LaceySnr Member since:
2009-09-28

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

Reply Score: 2

RE[3]: I clicked it, I liked it
by Brendan on Mon 27th May 2013 06:18 UTC in reply to "RE[2]: I clicked it, I liked it"
Brendan Member since:
2005-11-16

Hi,

The clearing to red seems to be written in Rust: https://github.com/charliesome/rustboot/blob/master/main.rs


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

Reply Score: 3

RE[2]: I clicked it, I liked it
by moondevil on Mon 27th May 2013 06:09 UTC in reply to "RE: I clicked it, I liked it"
moondevil Member since:
2005-07-08

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.


Only the boot loader is written in Assembly, like in any OS.

Have you read the code at all?!


unsafe fn clear_screen(background: Color) {
range(0, 80*25, |i| {
*((0xb8000 + i * 2) as *mut u16) = (background as u16) << 12;
});
}

Reply Score: 3

RE[3]: I clicked it, I liked it
by Brendan on Mon 27th May 2013 06:21 UTC in reply to "RE[2]: I clicked it, I liked it"
Brendan Member since:
2005-11-16

Hi,

Only the boot loader is written in Assembly, like in any OS.


Except for https://github.com/charliesome/rustboot/blob/master/runtime.asm . Have you read the code at all?!


- Brendan

Reply Score: 1

RE[4]: I clicked it, I liked it
by moondevil on Mon 27th May 2013 08:16 UTC in reply to "RE[3]: I clicked it, I liked it"
moondevil Member since:
2005-07-08

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?!

Reply Score: 2

RE[5]: I clicked it, I liked it
by M.Onty on Mon 27th May 2013 11:14 UTC in reply to "RE[4]: I clicked it, I liked it"
M.Onty Member since:
2009-10-23

You two enjoying yourselves?!

Reply Score: 9

RE[6]: I clicked it, I liked it
by moondevil on Mon 27th May 2013 17:05 UTC in reply to "RE[5]: I clicked it, I liked it"
moondevil Member since:
2005-07-08

Well, I am used to flamewars since the BBS days, so I can carry on for a while still. ;)

Reply Score: 2

RE[5]: I clicked it, I liked it
by Brendan on Tue 28th May 2013 04:53 UTC in reply to "RE[4]: I clicked it, I liked it"
Brendan Member since:
2005-11-16

Hi,

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?!


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

Reply Score: 3

RE[6]: I clicked it, I liked it
by Neolander on Tue 28th May 2013 06:08 UTC in reply to "RE[5]: I clicked it, I liked it"
Neolander Member since:
2010-03-08

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.

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

Reply Score: 2

RE[7]: I clicked it, I liked it
by moondevil on Tue 28th May 2013 07:48 UTC in reply to "RE[6]: I clicked it, I liked it"
moondevil Member since:
2005-07-08

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.


And Object Pascal, Modula-2, Ada, ...

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++.


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.

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...


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.

Reply Score: 2

RE[6]: I clicked it, I liked it
by moondevil on Tue 28th May 2013 06:40 UTC in reply to "RE[5]: I clicked it, I liked it"
moondevil Member since:
2005-07-08

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.


You mean like C?

Last time I checked you are doing exactly the same, glue between Assembly code that interacts with the hardware.

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". ;)


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.

Reply Score: 2

v Temple OS
by TempleOS on Mon 27th May 2013 08:26 UTC
SPAM report !
by Kochise on Mon 27th May 2013 10:51 UTC in reply to "Temple OS"
Kochise Member since:
2006-03-03

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

Reply Score: 4

RE: SPAM report !
by Chris_G on Mon 27th May 2013 11:15 UTC in reply to "SPAM report !"
Chris_G Member since:
2012-10-25

とあるOS ( http://toaruos.org ) might belong on that list too.

Edited 2013-05-27 11:18 UTC

Reply Score: 3

RE: Temple OS
by Chris_G on Mon 27th May 2013 11:06 UTC in reply to "Temple OS"
Chris_G Member since:
2012-10-25

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.

Reply Score: 3

v RE[2]: Temple OS
by TempleOS on Mon 27th May 2013 11:14 UTC in reply to "RE: Temple OS"
RE[3]: Temple OS
by kwan_e on Mon 27th May 2013 12:13 UTC in reply to "RE[2]: Temple OS"
kwan_e Member since:
2007-02-18

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".

Reply Score: 4

RE[3]: Temple OS
by MOS6510 on Mon 27th May 2013 12:19 UTC in reply to "RE[2]: Temple OS"
MOS6510 Member since:
2011-05-12

Root is God.

Reply Score: 2

RE[4]: Temple OS
by Kochise on Mon 27th May 2013 12:50 UTC in reply to "RE[3]: Temple OS"
Kochise Member since:
2006-03-03

libbible.so

Kochise

Reply Score: 2

RE[4]: Temple OS
by Soulbender on Tue 28th May 2013 05:22 UTC in reply to "RE[3]: Temple OS"
Soulbender Member since:
2005-08-18

No, that's Eric Clapton. Or was it Lemmy?

Reply Score: 2

RE: Temple OS
by sultanqasim on Mon 27th May 2013 20:22 UTC in reply to "Temple OS"
sultanqasim Member since:
2006-10-28

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.

Reply Score: 1

RE[2]: Temple OS
by subsider34 on Mon 27th May 2013 22:45 UTC in reply to "RE: Temple OS"
subsider34 Member since:
2010-11-08

Agreed.

Reply Score: 1

RE[2]: Temple OS
by kwan_e on Tue 28th May 2013 01:38 UTC in reply to "RE: Temple OS"
kwan_e Member since:
2007-02-18

Stop criticizing TempleOS's comments, and instead take a look at the actual project.


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?

Reply Score: 3

RE: Temple OS
by Soulbender on Tue 28th May 2013 05:26 UTC in reply to "Temple OS"
Soulbender Member since:
2005-08-18

Blatant self-promotion and religious craziness aside, sure why not? At least it does more than paint the screen red and hang.

Reply Score: 2

v 64-bit
by TempleOS on Mon 27th May 2013 11:02 UTC
RE: 64-bit
by Athlander on Mon 27th May 2013 12:20 UTC in reply to "64-bit"
Athlander Member since:
2008-03-10


God said 640x480.


No, God said 1200x1600 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.

Reply Score: 6

RE: 64-bit
by Kochise on Mon 27th May 2013 12:57 UTC in reply to "64-bit"
Kochise Member since:
2006-03-03

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

Reply Score: 3

v RE[2]: 64-bit
by TempleOS on Mon 27th May 2013 14:08 UTC in reply to "RE: 64-bit"
RE[3]: 64-bit
by Naomi on Mon 27th May 2013 16:52 UTC in reply to "RE[2]: 64-bit"
Naomi Member since:
2013-05-27

Can't tell if sarcastic





or just crazy.

Reply Score: 3

RE[3]: 64-bit
by Soulbender on Tue 28th May 2013 05:18 UTC in reply to "RE[2]: 64-bit"
Soulbender Member since:
2005-08-18

I seriously can't tell if you are truly deranged or just pulling our legs.

Reply Score: 2

RE[4]: 64-bit
by jal_ on Tue 28th May 2013 13:06 UTC in reply to "RE[3]: 64-bit"
jal_ Member since:
2006-11-02

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.

Reply Score: 3

RE[4]: 64-bit
by Nelson on Wed 29th May 2013 06:14 UTC in reply to "RE[3]: 64-bit"
Nelson Member since:
2005-11-29

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...

Reply Score: 2

RE[3]: 64-bit
by zima on Sat 1st Jun 2013 13:14 UTC in reply to "RE[2]: 64-bit"
zima Member since:
2005-07-06

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)

Reply Score: 2

RE: 64-bit
by umccullough on Mon 27th May 2013 15:57 UTC in reply to "64-bit"
umccullough Member since:
2006-01-26

Haiku is still 32-bit.


That's not entirely true...

http://haiku-files.org/unsupported-builds/x86_64/

Reply Score: 4

RE: 64-bit
by Bobthearch on Mon 27th May 2013 19:54 UTC in reply to "64-bit"
Bobthearch Member since:
2006-01-27

God said 640x480.


I think He did say that, in 1987.
But now God says 640x480 looks like butt on his 27" wide screen monitor.

;)

Reply Score: 2

RE[2]: 64-bit
by TempleOS on Mon 27th May 2013 20:06 UTC in reply to "RE: 64-bit"
TempleOS Member since:
2013-04-03

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

Reply Score: 0

RE[3]: 64-bit
by Kochise on Tue 28th May 2013 08:21 UTC in reply to "RE[2]: 64-bit"
Kochise Member since:
2006-03-03

1) The OS doesn't need GPU drivers, which makes it possible and open.

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.
2) No gore. A return to innocence.

Let's return to punch cards and LED matrix display.
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.
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

Reply Score: 2

RE[4]: 64-bit
by zima on Thu 30th May 2013 13:05 UTC in reply to "RE[3]: 64-bit"
zima Member since:
2005-07-06

Let's return to [...] LED matrix display.

In a way, that's what OLED displays are ;)

Reply Score: 2

I have never used rust,,,
by Coxy on Mon 27th May 2013 16:24 UTC
Coxy
Member since:
2006-07-01

...but maybe someone can explain to me how this code

https://github.com/charliesome/rustboot/blob/master/main.rs

constitutes an operating system?

Reply Score: 3

RE: I have never used rust,,,
by umccullough on Mon 27th May 2013 16:35 UTC in reply to "I have never used rust,,,"
umccullough Member since:
2006-01-26

...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>

Reply Score: 3

RE: I have never used rust,,,
by jayrulez on Mon 27th May 2013 16:37 UTC in reply to "I have never used rust,,,"
jayrulez Member since:
2011-10-17

I checked the Github page. Nowhere did it say that it is an operating system.

rustboot

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:

Reply Score: 2

RE: I have never used rust,,,
by butters on Mon 27th May 2013 20:17 UTC in reply to "I have never used rust,,,"
butters Member since:
2005-07-08

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.

Reply Score: 3

DOS
by TempleOS on Mon 27th May 2013 17:08 UTC
TempleOS
Member since:
2013-04-03

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

Reply Score: 0

RE: DOS
by Kochise on Mon 27th May 2013 18:15 UTC in reply to "DOS"
Kochise Member since:
2006-03-03

The Commodore 64 was the most sold personal computer ever. There's probably so many wrong people around the globe, who knows...

Kochise

Reply Score: 2

RE[2]: DOS
by tylerdurden on Mon 27th May 2013 22:57 UTC in reply to "RE: DOS"
tylerdurden Member since:
2009-03-17

The Commodore 64 was the most sold personal computer ever.


That depends on what you meant by "computer," "personal," "sold," and "ever."

Reply Score: 1

RE[3]: DOS
by Kochise on Tue 28th May 2013 06:10 UTC in reply to "RE[2]: DOS"
Kochise Member since:
2006-03-03

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

Reply Score: 3

RE[2]: DOS
by MOS6510 on Tue 28th May 2013 04:27 UTC in reply to "RE: DOS"
MOS6510 Member since:
2011-05-12

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.

Reply Score: 2

RE: DOS
by Soulbender on Tue 28th May 2013 05:13 UTC in reply to "DOS"
Soulbender Member since:
2005-08-18

Every minute we had to press a reset button when it hung. We could only type for 30 seconds before some virus got us.


I have bad news for you. This is not a failure with DOS, it's a PEBCAK.

Reply Score: 3

RE[2]: DOS
by zima on Thu 30th May 2013 13:04 UTC in reply to "RE: DOS"
zima Member since:
2005-07-06

PEBKAC ;)

Reply Score: 2

Knowing assembly
by TempleOS on Wed 29th May 2013 02:25 UTC
TempleOS
Member since:
2013-04-03

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

Reply Score: 0

BallmerKnowsBest
Member since:
2008-06-02

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.

Reply Score: 2

zima Member since:
2005-07-06

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.

Reply Score: 2