MenuetOS Updated With SMP Threads & Onscreen Keyboard

[sarmad]

This abomination(!) is a perfect example how bloated and on steroids even the OSes written in C are..

I think it has little to do with whether the code is written in C or Assembly. It's about how the code is designed and how the design is fine tuned. Yes, hand writing things in Assembly results in smaller code, but not that smaller. I think if we are to rewrite MenuetOS completely in C with a similar design we'll end up with a compiled code that is probably 20% to 30% bigger, not 100x bigger.
I think we have big OSes (and applications in general) because of two main reasons:
* everywhere speed of development is favored to code optimization.
* many times fancy code designs are introduced needlessly.

Think Windows 95 which works with 4MB of RAM and compare that to Windows 8 which requires 1GB (250x) and wonder if the features included in Win8 and not in Win95 really justifies that much change in memory requirement. It's like you write a notepad application with a size of 1MB, then you add support for multi tabs and the size jumps to 20MB!!

[curaga]

"...and fits on a 1.5MB floppy disk image..."

of course I'm not leaving linux for menuet OS but the fact that even after installing linux or whatever OS from a dvd I have to download additional software to make it suit my needs, look at the size difference.. 4gb vs 1.5mb lol

If you prefer not to need internet access, you can always install Debian from the blurays IIRC the entire Debian archive fits to two blurays.

Also let's not mention the elephant in the corner that requires 25GB for an install without any useful software.

[DrYak]

If it had things like Pidgin, Steam, other useful Software and maybe even Wine support;

If it had all these, it wouldn't fit on a 1.5 floppy minimum.
To get Pidgin working, you'd need all the support libraries that Pidgin uses and that are lacking in MenuetOS (GTK interface, libao sound, Aspell spelling, the whole GObject object oriented stuff which powers it). And that's only for Pidgin. Now imagine how much more libraries and functionnalities big applications llike steam or Wine would require. At that point, you'ld be implementing an almost complete POSIX system on top of MenuetOS.

So cut the middle man and go straight for Linux.

[QUOTE=stiiixy;436126]I was thinking the same thing. I guess until recently the ever increasing speed/power/cost ratios of hardware were simply forcing dev's to not bother with minimising their file and package size footprints[quote]

More speed/power/cost also gives you the capability to add more abstraction, which end up enabling more advanced uses and give the possibility to add more features if needed.
compare:
- pulseaudio (complex mixing, and complex audio routing, even over wireless connection bluetooth - and thus for the same reason also possible to send audio over network "? la" Apple AirPlay)
- dmix (can mix and resample multiple source, through hacking of an ALSA specific layer that sits above ALSA-only sound drivers. Difficult to stack with other such layers)
- OSS and ALSA (just send a sound stream to a sound card. You make sure that the stream is compatible and avoid locking the device from one application)

(BTW: does menuetos even have sound ?)

The same kind of abstraction is everywhere else in a modern OS. (Filesystems: MenuetOS barely supports FAT, Linux is the king of "you want something? we can do it!")

This OS reminds me of those 'scene' demo's crew's like Farbrausch did in the 90'sand 00's.

The only point in common is the small size of the executable. And that's about it.
- Farbrausch's demo still rely on having a full blown OS underneath and a full 3D GFX API. Farbrausch's magic relies on *procedural generation*: instead of having an artist painstakingly draw 128MB worth of textures for you, you teach a program how to generate those textures and even more for you.

- MenuetOS relies on ultra-tigh integration. You need a lot less abstraction levels when you're the one designing both the core OS and the software running on it. Just implement the bare minimum, design everything to have as few layers between them, etc.
But with less abstraction come also less feature and adding new stuff that weren't thaught about before hand require massive work. (it probably won't be easy to add support for EXT3/4. Probably no way at all to add journalling).

MenuetOS is nice and interesting, and is still a small-scale enough project so and interested developer can study it and have a clear idea of the whole OS.
But if you want it to catch up as many features as Linux, you'll end up having something as big as Linux.

[glxextxexlg]

I think it has little to do with whether the code is written in C or Assembly. It's about how the code is designed and how the design is fine tuned. Yes, hand writing things in Assembly results in smaller code, but not that smaller. I think if we are to rewrite MenuetOS completely in C with a similar design we'll end up with a compiled code that is probably 20% to 30% bigger, not 100x bigger.
I think we have big OSes (and applications in general) because of two main reasons:
* everywhere speed of development is favored to code optimization.
* many times fancy code designs are introduced needlessly.

While your points being true about software design and development process, even if menuet OS would do the essential things a modern desktop OS (GNU/linux, windows, OSX) does (word processing, mails, browsing etc.), I think the difference in size would still be 1 to 10 or so. Its because of libraries used by the system. Easiest example to this is you want to write something to console in C++? You'll use iostream header and have to link libstdc++, which is around 1mb in mingw (dunno about the size in linux) and this library includes tons of features which you don't need to write to console. Its the same with many other libraries and in fact its the reason they are called libraries in the first place. Otherwise we'd call them functions and we'd have a dependency and maintenance hell of a system strange nerds would spawn around it sharing functions amoung themselves.. oh and I just woke up from that nightmare

[stiiixy]

[QUOTE=DrYak;436237]If it had all these, it wouldn't fit on a 1.5 floppy minimum.
To get Pidgin working, you'd need all the support libraries that Pidgin uses and that are lacking in MenuetOS (GTK interface, libao sound, Aspell spelling, the whole GObject object oriented stuff which powers it). And that's only for Pidgin. Now imagine how much more libraries and functionnalities big applications llike steam or Wine would require. At that point, you'ld be implementing an almost complete POSIX system on top of MenuetOS.

So cut the middle man and go straight for Linux.

[QUOTE=stiiixy;436126]I was thinking the same thing. I guess until recently the ever increasing speed/power/cost ratios of hardware were simply forcing dev's to not bother with minimising their file and package size footprints

More speed/power/cost also gives you the capability to add more abstraction, which end up enabling more advanced uses and give the possibility to add more features if needed.
compare:
- pulseaudio (complex mixing, and complex audio routing, even over wireless connection bluetooth - and thus for the same reason also possible to send audio over network "? la" Apple AirPlay)
- dmix (can mix and resample multiple source, through hacking of an ALSA specific layer that sits above ALSA-only sound drivers. Difficult to stack with other such layers)
- OSS and ALSA (just send a sound stream to a sound card. You make sure that the stream is compatible and avoid locking the device from one application)

(BTW: does menuetos even have sound ?)

The same kind of abstraction is everywhere else in a modern OS. (Filesystems: MenuetOS barely supports FAT, Linux is the king of "you want something? we can do it!")



The only point in common is the small size of the executable. And that's about it.
- Farbrausch's demo still rely on having a full blown OS underneath and a full 3D GFX API. Farbrausch's magic relies on *procedural generation*: instead of having an artist painstakingly draw 128MB worth of textures for you, you teach a program how to generate those textures and even more for you.

- MenuetOS relies on ultra-tigh integration. You need a lot less abstraction levels when you're the one designing both the core OS and the software running on it. Just implement the bare minimum, design everything to have as few layers between them, etc.
But with less abstraction come also less feature and adding new stuff that weren't thaught about before hand require massive work. (it probably won't be easy to add support for EXT3/4. Probably no way at all to add journalling).

MenuetOS is nice and interesting, and is still a small-scale enough project so and interested developer can study it and have a clear idea of the whole OS.
But if you want it to catch up as many features as Linux, you'll end up having something as big as Linux.

'reminds' was the operative. I didn't say it was using the same low-down tech. I remember player kkrieger and seeing things that were obviously simple ascii text characters.

As for the size differance, most of the time it's simple art assets, is it not?