laststep
laststep taking another step forward
Aug 27th
Just real quick and simple. While working on a modified Linux Kernel for my project was good fun and a nice learning experiment, I thought it’s time to push the project a bit deeper. As such I thought it is time to implement my own kernel, written from the ground up. This would give me absolute freedom to do whatever I wanted to do, at that stage I could even implement my own graphical server (which is probably what I gonna do… X11 is pretty heavy, you have to admit that). The trick is make my own kernel, and then get a toolchain ported so that I can compile stuff I need, and from then on in develop things I really want.
I have begun working on such a kernel. So far it doesn’t do much, other than say “Hello World!” \o/ … gotta start somewhere. Obviously the starting point is written in Assembler – because there’s no other way of getting a kernel started. The rest boils down to being written in C. At least the basics. After that, I can probably go and do my own object oriented implementations… I have to see about that.
For my purposes I believe the best way to go is a Microkernel. I’m calling it Aura. Currently I’m implementing IRQs and that stuff. Here’s a map of what the whole Kernel thing should look like.
I’ll update you on the progress.
Next step of the ‘Step
Jun 27th
tl;dr – laststep project has undergone changes, API has changed, UI has changed, and code is going open source for a small fee.
So just to give a little update on my project. Yes yes I know, I haven’t shown anything substantial apart from some screenshots and a YouTube… I know what you’re thinking. I have not abandoned the project, just made some changes to it – mostly concerning the user interface.
That’s right, I’m restructuring the UI to implement some new ideas I have, and when something is ready to show you, I’ll post it. While many things did work they way they should be, I have taken some things out and I can tell you that the API has changed, the one containing all the blocks to build your own apps. When I tell you that the API needed to change in order to make my new ideas work, that has to be enough for the moment.
Also, you might be interested to know that I have a distribution concept which kind of will reward me for the time and effort I put in, while you can have a look under the hood and modify everything you like… In other words it’s going open source, however you’d have to pay a small amount of money to get the actual code. I hope that philosophy won’t offend too many people.
Rest assured I am working on it – and I really want the final thing to be epic and not just a simple knockoff of things that already exist. So I am taking my time. Better that then producing second grade quality code and software – don’t you think?
That is all for the moment.
State of the ‘step
Feb 26th
Just a very brief update on my project. Right now I’m working on Milestone Build 1A115, which is the first one to provide a graphical login service. From there you can click on your user, enter password, and you’re in – the usual. As with most systems out there, even on Mac, LoginWindow.app can never ever terminate. If that happens, well, your desktop and everything in it and on it crashes with the service.
That way my Desktop can connect to the login manager and give the instruction to log the user out. LoginWindow.app therefore effectively links the most vital components – which is why 1A115 is a milestone build. As some developers might want to develop widgets (Cosmoids) that allow you to log out with one click, the API to connect to LoginWindow is obviously open to anyone to implement.
In case you were wondering about my versioning… First is the version of the system, in this case 1. The letter that follows describes what it is. A = Alpha – B = Beta – F = Final. A in this case. The last digits are a steadily increasing number. The higher the version, the more improved the code is.
Graphical login for laststep
Feb 10th
laststep Build 1A110 boots in under 20 seconds
Jan 28th
I am still working on the boot up routine which should include a graphical boot. However after doing some modifications to the start up scripts, a graphical boot seems no longer necessary and I can directly go into graphical login. As of right now I didn’t write the login application yet, but this is up next.
Working on boot for laststep… how should it look?
Jan 20th
As the title says. I am working on a graphical boot implementation which starts right into X11 while the system is loaded. While the system is booting one should know how long it is going to take until the computer is usable. Once everything is done, and since we would already be graphical, I only need to switch to the login manager.
So I am working on some ideas… here’s one mockup I made (meaning not a real screenshot! And yes the progressbar is from a Mac, I just change the colors. A Aqua progress bar will obviously not be in my project).
I think a progress bar at boot is good, the user knows how long it will take until he can log in. In my opinion, a simple logo is, well, just too simple.
If you have any improvement or other ideas, please let me know.
Boot Mockup Screen Idea 1.
Linux has been multi-touched
Jan 18th
Introducing Newton. laststep’s POSIX base.
Jan 14th
My project has progressed to a point where I can no longer use a virtual machine for development, the way I used to do it up until now. Because Voyager, the file browser, requires hardware support, I now have to use a real world machine to test things on. Wait what? A file browser requires hardware? Well you know if you want to browse through your USB drive or music player, you need it =) This is the reason why I moved to a real world machine.
Since I want laststep to be a rather unique platform, the base underneath is substantially different from other Linux/Unix-alikes out there – but maintains the established folder hierarchy standard, so everyone can operate safely in both eras.
Newton is what I call the base of laststep, the foundation on which everything is going to be running on. The biggest difference with Newton is the folder hierarchy, which is outlined below. As a filesystem, laststep is going to use JFS by default.
/ File system root inside which everything else resides in. /Applications The default location for all GUI applications | /Utilities Command-line or GUI tools of administrative nature /Library Contains all libraries and corresponding files /Network Network drives and other related files /Private Holds tools and configuration files, private to the OS, contains /bin, /etc and so on. /System Everything vital to the system | /CoreServices Crucial services such as the Desktop, Grids, Rewind, etc | /Kernel Kernel and all related files | /Library Internal libraries and other system-crucial files /Users Contains all data and files of a user's account /Volumes Directory inside which removable medias will be mounted, like USB drives, DVD's, digital cameras...
However the standard directories like /etc, /usr, and so on, are still accessible and can be changed into. For example if you do
cd /usr/bin
it will work, but in reality you are in /Private/usr/bin.
The only remaining entries in the root tree are /dev, /proc, and /sys, as these are virtual file systems required by the kernel to be on the root folder.


Voyager, laststep’s file browser takes shape
Jan 5th
You know I could have gone and write a simple file manager. But by the scope of this project, a file browser has to be a bit more than that. For my project, I call it Voyager. It doesn’t look like much right now, but so far it required some work.
For example one file browser window can have many instances of the file browser itself, by using tabs. The Explorer in Windows 7 does not have tabs, neither does Mac’s Finder. I kinda like tabs so I built them. So that was the first element required. This view is also available to developers for all kinds of things. LSTabbedElementView is the class name for it.
Next thing up was the creation of a preliminary version of the background indexing service, which should be known as Searchlight. It is using SQLite and stores all information in a central location. Information stored is vital basic data such as file name, location, among other things. On top of that you can store a description for a file/folder, as well as meta tags. Music files have special fields like artist, composer, album, etc, while photos have geo-tagging fields. Also, a file can be flagged as a favorite – and thus the machine knows what things you prefer. Ultimately you can search for practically any conceivable criteria or combination of criterias, in one or many locations.
With those things implemented, it was possible to create a preliminary interface for the browser, looking like this:
Cosmos. Widgets now also in laststep
Dec 13th
As you might have gathered, I pick up on speed with my little project. Now that many components are written and in place, I can pretty much add anything I want, really.
The next thing I decided to add after virtual desktops is a little widget engine that allows you to add little bits of information on the desktop, like you would expect it nowadays from a modern operating system. The widgets can have any shape and form, can even be completely translucent.
To make this possible I had to create a parser for the files that contain the information for the widgets… sorry, Cosmoids. Those are CML files, and are in a very simple format, I explain in a second.
Seeing is believing eh?
This is the little testing and demo Cosmoid. As you can see it has a text label, an image, and two buttons. When you click the “Rain!” button, the image changes. No wai!!
Nothing spectacular, but it demonstrates that it works.
This is the corresponding cosmoid.cml file which is read in the beginning and makes up this particular Cosmoid. First entirely:
[Information]
Name = Demo Cosmoid
Background = Resources/csm_back.png
Active = YES[Dimensions]
Width = 300
Height = 200
Position = 827.000000, 764.000000[Content]
TextLabel = helloLabel, Hello Cosmos!, 250, 20, 25, 150, white, bold, 16
Image = sunImage, Resources/sunny.png, 90, 20
Button = sunChanger, Sun!, sunImage, setMyImage:, Resources/sunny.png, 100, 20
Button = rainChanger, Rain!, sunImage, setMyImage:, Resources/rainy.png, 200, 20
That’s it! Isn’t that simple? Let me explain some things.
[Information]
Name = Demo Cosmoid
Background = Resources/csm_back.png
Active = YES
This block should be obvious.
[Dimensions]
Width = 300
Height = 200
Position = 827.000000, 764.000000
This defines the width and height of the Cosmoid, as well as its location. You can either define a position from left and from bottom of the screen – or use “Center” on one or both to center it on the screen when loaded. The “Position” parameter is updated in real time when the user drags it to a different location on the desktop – and this is how it remembers its position after a reboot or re-logon.
Now for the elements. Right now, for starters, I support text labels, images, and buttons. Gotta start somewhere right?
[Content]
TextLabel = helloLabel, Hello Cosmos!, 250, 20, 25, 150, white, bold, 16
The syntax is as follows:
ID, string to display, width, height, from left border, from bottom border, text color, text weight (“bold” or “normal”), text size
Next is:
Image = sunImage, Resources/sunny.png, 90, 20
Syntax:
ID, image to display, from left border, from bottom border
Now with buttons it gets slightly more interesting as they do something or manipulate elements. They look like:
Button = sunChanger, Sun!, sunImage, setMyImage:, Resources/sunny.png, 100, 20
Button = rainChanger, Rain!, sunImage, setMyImage:, Resources/rainy.png, 200, 20
Syntax:
ID, text to display, ID of element to manipulate, action, parameter (or if none, put ‘nil’), from left border, from bottom border
So as you can see – you quite literally construct your Cosmoid line by line in a single file – it cannot be easier than that!
And I call it CML – Cosmos Markup Language.
Cosmoids have to be places in either: /Users/YOUR_USERNAME/Library/Cosmoids (for personal use only) or /Library/Cosmoids (system wide availability). The file that builds a Cosmoid is always called ‘cosmoid.cml’.
Obviously there’s gonna be a graphical construction tool for this, so don’t worry! Also Cosmoids can be configured via the Settings tool.







