SythOS – An experimental collaborative OS

A rather long time ago (around a year and a half), I wrote a post about a system I was making which was supposed to be a cloud-based OS, named CosmOS. I didn’t really develop it that much, as I had a rather vague sense of what I wanted to do with it, and I immediately had problems with implementing the most basic concepts. Most of the idea was actually quite boring, and had already been developed by others. But since I had gone through all the trouble of making a tool for creating it (relinux), I decided to try it anyways, and just radically changed the whole design. And I did. I also found that I couldn’t have used the same name, as CosmOS was already the name of at least two different OS’s, and it was also the name of a directory of linux OSs (among other unrelated usages), so I kind of got that I had to change the name.

The name is actually based on two words, Synergy and Lithosphere (I was going to call it LithOS, but it sounded like some kind of boring scientific and/or business-oriented OS, if you know what I mean). I know, kind of an odd combination, and the reasoning for it is a quite far-fetched, but heck, it’s an unused name, and it sounds cool! Lithosphere was used as a creative way to say “ground”, because it’s not cloud-based (unlike CosmOS, in fact), and it’s also designed to be “down to the ground” with you. Instead of you adapting to the OS, the OS adapts to you (will explain how this works later). Also, the Synergy part is because since it’s completely with you, it allows nearly everything to be done much easier and simpler, reducing the amount of time both the users AND the developers need to do nearly everything (except for the engine… :-/).

The OS itself is principally designed under the following goals:

• Help the user to become more productive within it
• Extremely intuitive
• Extremely easy to collaborate on anything
• Extremely customizable
• Fun

There is only one software that I’m aware of that does this well: Minecraft (creative mode). Okay, forget the productive element, but still, anyone can pick up the pace on how to use minecraft extremely quickly. Also, if you’ve ever played it, you’ll know how easy it is to collaborate on building something. You don’t need to use a VCS like git or mercurial to build something. Just get someone else on your server, and build together!

That’s kind of my idea with SythOS. You are inside a 3D environment, windows are mapped to 3D surfaces (I had this idea from Wolfenstein Qt, but it appears to already have been implemented: 

), and the environment is modifiable, using a minecraft-like in-game “level editor”. Other people can connect to your computer (if you allow them, of course), and then you can work together on projects (such as coding, audio, video, or even games) at the same time! Of course, for this to be effective, you have to have somewhat compatible software (you can’t both work on the same window for rather obvious reasons), but even if the software you use isn’t “compatible”, taking turns, and being able to see what the other is doing real-time is still way easier than using some kind of VCS or worse, emailing files back and forth, right? Also, with the chat and mic/audio features that are planned, you can also make meetings and/or “calls” (kind of like skype does, except without the video) within it.

Here’s a list of features that are either implemented or definite:

• 3D virtual world
• Windows mapped to the world
• MMO-like online presence
• World is Minecraft-like
• Different tools and blocks (inspired by minecraft)
  • Hand tool: Allows you to do basic edits to windows (such as moving, resizing, and closing), and allows you to use windows, plus allows you to remove blocks
  • Kill tool: Allows you to kill processes, based on the windows you hit, and, of course, allows you to remove blocks
  • Various blocks, which allows you to place them, and remove other blocks, plus allows everything the hand tool allows you to do
  • Portal tool: Allows you to create portals to different rooms, so as to decrease the time needed to go between two different “workspaces”
• Whitelist, Blacklist and “Asklist” for everything (great for multiple user computers, and/or online interaction)
• Chat
• Quake-like terminal with multiple tabs, but it can be used to place any kind of windows, not only terminals

Other features that are planned, but not implemented or definite would be:

• Mic/Audio
• Some kind of game engine, so you can create 3D objects that interact with the world (though it’s definitely not limited to games, it could even be used to create fancy movie creation software, or 3D modeling software)
• Facial expression recognition, so your character’s face will match your expression. This is definitely not an important feature, and if it is ever implemented, it will probably be quite far-future.
• Video… somehow… (no idea how to elegantly do this though)

Now for the point of this post (the reason why I’m writing it): Would you use something like this? If so, or if not, why? Any ideas and/or comments on this?

About the possibility of it being implemented, I know that it is possible, but I’m not sure how much time it’ll take me to do all of this (and I’m not sure if I’ll have the stamina needed to do this). I’m planning on releasing a prototype by the end of this summer (2013) though.

extract-xxx – An easy way of extracting XXX/FIXME’s

First: The “Why”. Well, it’s because when I write code, I usually don’t have the time (or the patience) to write everything perfectly, so I usually just write in a small XXX, TODO, or FIXME for later. The issue is, when I do want to fix them (e.g. in the final polishing stage of development), it’s hard to find them (especially if you have many source files, and it takes some time to open any of them). Also, it’s because I wanted to learn perl, and I wanted to take a small break from my other project (which is taking up most of my free time).

The repository is here: 
https://github.com/MiJyn/extract-xxx
. Download it however you want, then run extract-xxx.pl.

What it basically does is that it searches through a file for the “comment types” (which is just a name I assigned for things like “XXX” or “TODO”, since I don’t know that they’re really called), and then prints them with (by default), 2 lines of context, both before and after. It’s kind of like grep, but it’s a bit more specialized towards this task (though you could theoretically do everything this does by fancy utilization of grep, find, and nl).

Example usage:

$ ./extract-xxx.pl -e 'cpp,h'
./src/engine/box.cpp

 51   |  */
 52   | bool Box::uncollide(Box* other, QVector3D old_pos) {
>53>>>|         // XXX: VAR_IS_UNUSED(old_pos)
 54   | 
 55   |         // Broadphase (?)
>56>>>|         // TODO: Check if this actually increases performance
 57   |         if (!this->collides(other)) {
 58   |                 return false;

 61   |                   ds = d + other->size;
 62   |         QVector3D overlap;
>63>>>|         // TODO: Decide the side from `old_pos`
 64   | #define syd_box_ov(x, X) {\
 65   |         qreal x##l_s = syd_max(0, d.x()),\

 79   |  */
 80   | bool Box::render() {
>81>>>|         // TODO: Use Vertex Array Object!
 82   |         qreal ex = size.x() / 2,
 83   |               ey = size.y() / 2,

./src/engine/image.cpp

 66   |         }
 67   |         this->image = image;
>68>>>|         // TODO: Maybe add support for graphics cards that support non-POT images?
 69   |         bool use_mipmaps = this->power_of_two();
 70   |         if (!this->id) {
 71   |                 glGenTextures(1, &this->id);
 72   |         }
>73>>>|         // TODO: Add support for GL_LUMINANCE and GL_LUMINANCE_ALPHA
 74   |         GLint format = this->image.hasAlphaChannel() ? GL_RGBA : GL_RGB;
 75   |         glBindTexture(GL_TEXTURE_2D, this->id);

 78   |                         /* This value must be 0, according to the OpenGL documentation... */ 0,
 79   |                         format, GL_UNSIGNED_BYTE, this->image.bits());
>80>>>|         // TODO: Add support for GL_LINEAR
 81   |         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
 82   |         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, (use_mipmaps) ? GL_NEAREST_MIPMAP_NEAREST : GL_NEAREST);

./include/syd/math.h

 23  | }
 24  | 
>25>>| // TODO: Add/use those ultra-optimized-and-hacky functions
 26  | 
 27  | SYD_END_FILE

When run with no arguments, it will recursively go through the current directory (including sub-directories, and sub-sub-directories, etc…), and will then go through each file, as mentioned previously. As you can notice, many lines are highlighted (e.g. >53>>>), as they contain a “comment type” (in this case, either TODO or XXX), proceeded by a colon.

Instead of rewriting everything here, check out the repository, as the README explains pretty much everything you need to know about it.

Anyways, let me know what you think, any constructive criticism is appreciated

My thoughts on Mir

If you aren’t aware, Canonical is planning on writing a new display server, competing to both X11 and Wayland, named Mir.

I’ll state my opinion right now: I really do NOT like this move. The rest of the post is the “why” of my opinion. I have not written all of the “why”, because some of the reasons I thought of lacked enough proof to back what I said (such as Canonical becoming another M$ or Apple, trying to take over the linux world ).

First, the segregation. Let’s assume that Mir is, as was planned “A … that is extremely well-defined, well-tested and portable.” (this is very hard to do, in fact, there are only a very few amount of software and libraries that are this good). Now this would cause a horrible issue of segregation, because now application developers that write applications for Mir will exclude people who do not have Mir (kind of an obvious issue though). Most application developers will use a toolkit, such as Qt or GTK+, which provides an abstraction layer that will allow the applications to run on any display server (though, of course, this requires patching them to support the display servers, but canonical, IIRC, has promised to do this, at least for Qt), so this is less of an issue. The bigger issue would be with the 3rd party graphics drivers. Both major GPU manufacturers (Nvidia and ATI) are already having issues with giving X11 support to their drivers (though Nvidia has considerably less issues than ATI). Now comes along Wayland, an alternative to X11. Back in 2010, Nvidia clearly stated that they do not have any plans to support wayland (they seemed to have changed their mind though, or at least, considered it), and ATI does not plan on supporting wayland anytime soon. This is reasonable for the companies and for linux. As long as X11 will still be supported until both companies officially support wayland, everything should be somewhat okay. But then comes along Mir, a company-lead alternative to both Wayland and X11, for their operating system. 3 different display servers for linux, and both major GPU manufacturers are already having issues with one. This is just ridiculous. And anyways, just think of the users and distros, trying to find which one they should use.

As I said before, I was assuming Mir was exactly what it was planned (i.e. perfect-world scenario). I already stated that it was extremely hard to actually meet the requirements they wanted, let alone that Canonical is not exactly known for their amazing abilities at efficient coding. Just look at unity. Even GNOME 3 and KDE are faster than that! And GNOME 3 uses Javascript extensively (a language that I think we can all agree on its slowness). Unity is written in C, C++, and Vala, 3 languages that are quite fast (though using many languages together can slow down an application). Please tell me: Why is it that Unity is so much slower that GNOME or KDE, which have at least the same complexity, if not much more? (EDIT: Some people have said part of the cause of the slowness is because of Compiz and Nux. Nux, IIRC, is developed by Canonical too) Now look at the Ubuntu software center, and at Ubiquity, two other applications written by canonical. The USC took ~10 seconds to load, compared to most other applications loading nearly instantly. Of course, they are written in python, which, after programming in it for a rather long time (and having a lot of experience with other languages), I think I can say that it is not only a slow language, but also a rather badly designed one. Canonical did not, of course, make python, but I just used that to show you an example of their poor decisions. Enough hitting on Canonical, let’s assume that they are great coders now. How long do you think it would take to write a complete display server that is “extremely well-defined, well-tested, and portable”? Canonical is a rather small company, how do you think they will write an application (or library) that is “well-tested”? Or maybe we should ask, what defines “extremely well-defined” and “well-tested” (and “portable”)?

Lastly, let’s say that they were able to accomplish their goal. Why do they need a new display server in the first place? Why can’t they just use Wayland? There is a section on the wiki about this, which I tried to read, but it was quite vague. All that I could understand is that they wanted support for 3D input devices. So why don’t they just talk to the Wayland developers about this and maybe help them implement it if progress is not going fast enough? Or if they don’t want to have it in wayland, just fork it, don’t start writing your own. “In summary, we have not chosen Wayland/Weston as our basis for delivering a next-generation user experience as it does not fulfill our requirements completely”. Oh, come on. Wayland is open-source, you can change it if you need to, you know. Or if they don’t want the changes, you can just fork it. I know I’m repeating my last sentence, but this is just ridiculous.

So to summarize, I’m not that crazy about Mir

I know I said things rather bluntly, and I’m expecting that most of the reactions to this will be rather harsh, but I feel that it was important to write this. It’s not because I hate ubuntu that I write this, I really like the initiative, just not the execution (which is why I write these kinds of posts… maybe if enough people show their disapproval towards their methods, they might change their minds ^_^). Also, if you think that any of the claims I made were false, let me know, I’m not that closed-minded about it

IT – A game/demo that takes 4D realism to the next level

For the past week or so, I’ve been working on a game, or rather, a demo, on using a highly immersive 4D environment (3 dimensions plus time). I know that many games have used synthesized 3D images on a 2D canvas, constantly being updated at a certain rate, synthesizing the fourth dimension in real life, in fact, this is the standard for most games. The realism in these games rely on the capabilities on the 3D artists and the designers to create imperfect environments that simulate this world.

When I started working on this game, I wanted to do something completely different, and take 4D realism to the next level. It sounds impossible with the current technology, but it actually isn’t. In fact, nearly every computer has the required capabilities of doing this! By using the interfaces that allows real life to interact with the core of the computer (and vice-versa) in creative ways, it is possible to reverse this, and create an application or game that interacts with real life, while still remaining as software.

Though it may sound hard, it is actually really simple! It doesn’t need any kind of direct hardware interaction, you can implement this easily with most major kernels! Since I currently use linux, this game only runs under linux (might run on FreeBSD, I have heard that they had some kind of support layer for linux… not sure though).

Since I wanted to release this demo as soon as possible, I didn’t do an amazing job at keeping the codebase clean, but once I have finished cleaning it up (or at least so that it will be somewhat readable), I will release it on github.

But I have created both i386 and AMD64 builds for this, available here:

• i386: 
  http://ompldr.org/vaHlpMA/it-game-i386.tar.gz
  
• AMD64: 
  http://ompldr.org/vaHloeA/it-game-amd64.tar.gz
  

---

EDIT: Yes, this was an april fools joke. The game itself worked, but the 4D realism did things like open the CD drive, disconnect the internet (though it does not do that by default), change the num/caps/scroll lock status, and open pop ups (since the computer environment itself is more real than the game environment). It was more or less of a whack-a-mole game, where you won points by fixing/closing the “issues” it made.

Source code:
https://github.com/MiJyn/it
. It’s still really messy (especially in net.cpp and keylock.cpp), but you should be able to figure out what it basically does and how it does it.

This actually was my first time operating with kernel calls (and netlink, to which I had spent ~2-4 days trying to work it, just to find out that it didn’t do what I wanted it to ), so it was kind of a wonder that I was even able to finish it by april fools.

bfdk – A brainf*** development kit

Yes, I know, yet another compiler/interpreter for brainf***… we all know how many there are, we all know how easy it is to write, etc… First, you have to know, that was my 3rd application written in C, and I needed an exercise in C (compilers, interpreters, plugin systems, API design, etc…), so I decided to write this. So for the features:

• Compiler (compiles to C, then runs GCC) and interpreter
• Supports multiple dialects (pbrain, brainlove, ook!, and blub)
• Source slimming (strips all comments)

I know, not very exciting. You’re probably wondering where “development kit” comes in. That’s for later, as I planned to write some sort of shell for it, which would complete it. For now, I think it’s stable enough for general usage.

The source is available here: 
https://github.com/MiJyn/bfdk
. Since this written was before I switched to vim, it uses eclipse makefiles, so it would be simplest for you to compile using eclipse. If you can’t, you can always use make -f Debug/makefile.

Here are some examples of usage:
bfdk -f hello.bf — Will run hello.bf
bfdk -c -f hello.bf -o hello — Will compile hello.bf to hello
bfdk -s -f hello.bf — Will output a slimmed version of hello.bf (you can also specify an output file using -o)
bfdk -d brainlove -f test.bl — Will run test.bl using the brainlove dialect
bfdk — Will run a shell (currently just a simple EOF thingy)

As I said in the beginning, this is not a serious product, this was just an exercise for fun. If you can find it useful, awesome, if not, don’t blame me for writing a useless product.

shbuild – An alternative to GNU Make… using shell scripts

I’ve been trying to find a make alternative or interface using more common languages, and so far, the only one I’ve found was waf (which, IMHO, wasn’t well documented and overly complex). Maybe I haven’t done enough research, but seriously, why do people have to reinvent the wheel for just a build system?

I spent around two days writing this (haven’t wrote shell scripts for a while), and I’m pleased of the result. Notice that this script is still in alpha stage, so I can’t guarantee that everything will work as expected. The main difference between this build system and others is that it works by commands (functions), which then runs the compilers, linkers, and whatever else is needed. Because of this design, it should (in theory) be more powerful and easier to code than a normal makefile. Here is an example of what I’m saying (sorry about the horrible formatting, wordpress breaks it):

Buildfile:

build() {
sources='file1.c file2.c file3.c file4.c file5.c file6.c main.c'
objects='file1.o file2.o file3.o file4.o file5.o file6.o main.o'
output="main"
runtargets $sources $objects 'gcc -c $target -o $output'
gcc $objects -o $output
}
addcmd build build Builds the project
default_command=build

Makefile:

all: main
file1.o: file1.c
gcc -c file1.c -o file1.o
file2.o: file2.c
gcc -c file2.c -o file2.o
(repeat this for each of the targets...)
main: file1.o file2.o file3.o file4.o file5.o file6.o main.o
gcc file1.o file2.o file3.o file4.o file5.o file6.o main.o -o main

For me, the buildfile technique seems much cleaner and easier, and anyways, it’s shell, so you can call functions within it to make your life even easier, etc…

The other thing that I spent a bit of time on was to add common utility functions so you don’t have to write them yourself. Some of them include:

• Automatic uninstaller
• printc for printing text in colors
• Many array utilities
• Help system (still a WIP)

No documentation is currently available, since I’m still polishing it, but I will add some soon. In the meantime, you can just browse through the source (honestly, it will only take you a couple of minutes, it’s currently very small). You can also check the buildfile for it, as it contains many of the functions you would probably use.

Source is located here: 
https://github.com/MiJyn/shbuild
. You can easily build and install the source by using the “build.sh” script (it’s simply a wrapper to use the unbuilt version of shbuild), like so:

sudo ./build.sh install

Let me know what you think, anything constructive (bug reports, ideas, patches, things that were unclear in this post, etc…) is appreciated

Why I migrated to Arch Linux

First, yes, I am well aware that this is an ubuntu-related blog, monitored on planet ubuntu, etc… This is not a “XYZ is better than ubuntu” post, but rather a “Consider XYZ too” post.

I have been a loyal ubuntu user for around 5 years, and I have also tried my best to help the community for around 3 years (and still am). I never plan on leaving the community, as I find ubuntu is sort of like a gateway for windows/mac users to the open source world, and all of us need to make sure that each user can have the best experience in that gateway so that they can explore deeper and, in their turn, help out too.

Anyways, going to the topic of this post, I have had a very pleasant experience with ubuntu until 11.10. Ubuntu then tried to attract the public to it by, well, over-blinging it (I’m referring to Unity). I have to say they did an excellent job on keeping it beautiful and minimalistic, but it needs a mid/high-range computer to use it. On my computer (which I consider it to be rather mid-range), it was really slow (2-5 minutes to login, let alone using it). Another thing that I didn’t like was how ubuntu over-patched everything. From the linux kernel to GNOME 3, it’s no wonder that everything was really slow. I’m sure that there are good reasons for doing so, but still, I personally like doing my own patching as I want it, not as someone else wants it. Also, I am not a huge fan of the debian package managment system, as even doing “nothing” takes around a second or two… not interested in that. The API is seriously messy, horribly documented, and even from a “users” perspective (a more tech-savvy one, of course), it’s hard to understand the output (for example, do you have any idea what’s happening when you run “sudo apt-get update”?)

You are probably thinking of a thousand counter-arguments against what I said, and they are probably all right. The thing is, I’m talking from a hacker/developer’s perspective where I want everything my way, nobody decides for me (which I feel that ubuntu is sort of doing). I know that the average user is probably very happy from the decisions ubuntu took, maybe even for the exact reasons that I don’t like it.

So now that I’ve written a bit why I don’t like ubuntu, I’ll write a few things that I like about arch. First of all, the installer is awesome! Yep, no installer, you do it by hand. This initially repulsed me from arch, until I discovered how the install process worked, and then I really loved it. It doesn’t come preinstalled with loads of apps that you might never use, it just has the bare minimum of a good linux desktop (which, IMHO, is great). I also loved the package manager ever since I started using it. So simple, so fast (even the downloads are faster because of LZMA compression, and by the way, the uncompressing is lightning fast), and yet so powerful! It uses standard getopt-type arguments instead of commands, so it’s way easier to use. The other thing that I like is how arch is so community-based. It isn’t a project where there is a team behind it, and community can help as 3rd party devs. It works by the community donating PKGBUILDs (shell scripts that build packages) and scripts or whatever else is needed and then “trusted members” (people who have been donating to arch linux a lot) will then review it for safety before including it. Another thing that I like is how it is a rolling release. This means that there are never new releases of arch, you update it, you have the latest arch system.

So as I said in the beginning, this is not “Arch is better than Ubuntu”, but rather “Arch works better for me than Ubuntu did”. I have nothing against the idea of ubuntu, I love it actually. But I don’t want to use it anymore, that’s all . That being said (and I repeat again), I do not plan on ever leaving the community, I will always try to help out the best I can

Thanks for reading! Feel free to comment below on your own opinions of this matter (and please, keep it nice, I don’t want to deal with a flame war).

libsatcr – A 2D collision detection and response library

This month, I’ve been working on a top-down adventure horror game with a friend of mine, and one part that I got stuck on was the field of collision detection and response. Since it was an online game written in JS, I tried to use Box2DWeb for the task, but of course, it didn’t work out the way I wanted it to. I’m sure that my problems could have been resolved some way or another, but really, if my only purpose of using a physics engine is for the collision detection and response, why don’t I just take a collision detection and response library? After a bit of googling, I stumbled upon SAT.js. I’ve been really impressed with how minimalist, yet powerful it was. It did the job of collision detection and response without needing to rewrite the whole codebase. So while I was waiting for my friend to do the art, and since C was my favourite programming language, I wrote libsatcr, a port of SAT.js to C. TL;DR version of this paragraph: libsatcr is a port of SAT.js to C.

Since this is my first real library in any language, it has bound to have errors here and there, so please don’t expect it to be by any means perfect. I have not thoroughly tested the library either, I have only estimated that its outputs are correct, but I will do more extensive testing later.

Anyways, here is the link to the main website: 
http://mijyn.github.com/libsatcr/index.html
, and the source: 
https://github.com/MiJyn/libsatcr
.

I would really appreciate any kind of constructive criticism, even if it has to do with minor style changes, clarification, spelling/grammar errors, etc…

Some random wallpapers I made a while back

I haven’t made a post in a rather long time, but I have been busy on a few different projects (which I will release soon). For now, I would like share some wallpapers I made in GIMP about a year or two ago. I have released them under a couple different places, but they were mostly either segregated, private, or I forgot the link to it, so now I will finally publish them to a rather more central place

Anyways, here they are:

Made using the “flame fractal”

My personal favourite ^_^

Thought this looked a bit like the fluid from The Matrix

Had some fun with the motion blur

As you can see, some were variations on others, a few were made with the flame fractal, and most were made using “whirl and pinch” plus a lot of blend modes for layers.

Hope some of you may enjoy them

I’m not 22

For a long time, I’ve been saying that I was 21/22 (1/1/1990) for internet security reasons, and then it was because I had told others that I was 21/22. I think that it would be about time for me to release my age publicly, as I feel that it would do more harm than good if I continued claiming that I’m 22 (soon to be 23 ).