Scitech officially announced today a port of their SNAP graphic interface to the Unununium Operating System, read the white paper written by Richard Fillion, part of the Unununium main developers.
Scitech officially announced today a port of their SNAP graphic interface to the Unununium Operating System, read the white paper written by Richard Fillion, part of the Unununium main developers.
Some people have too much free time on their own… I love the name however. At least no big company is going to sue them for trademark infringement.
Support for what? Probably Scitech isn’t here for commercial success.
Support for what? Probably Scitech isn’t here for commercial success.
My guess is that it’s just another platform they can say it supports. That’s one of the major selling points for Scitech SNAP.
This way they can say something along the lines of “Scitech SNAP now supports x Operating Systems!”
“Probably Scitech isn’t here for commercial success.” – SciTech most certainly attempts to find success in all areas of its business, both in commercial and in non-commercial markets. Projects such as this provide us with a real opportunity to work with talented developers whom are not here to serve our interests but instead serve their own. From this we gain valuable insight on our products and processes and use this insight to improve how we do things here at SciTech. With each successful port of SciTech SNAP we get a step closer to our goal of being able to provide a complete no excuses solution for the non-MS world.
…efforts in supporting non-commecial and/or opensource software. thanks for projects like porting snap graphics and especially also watcom c++!
Thanks! I will pass along your kind note to the team here at SciTech.
Couldn’t agree more to be honest.
I’d love to see SNAP ported to AROS, that is a project with ALOT of go in it, SNAP and Watcom in AROS would make my cup of tea (actually coffee, I don’t drink tea )
Have SciTech examined AROS, would AndrewB care to comment about that?
You’ll notice from the white paper that the Unununium port was done by the Unununium developers. You are certainly welcome to pass the white paper on to the AROS developers.
Again thanks for the continued show of support. In regards to AROS, to be honest I can’t say that we have looked at it. However, as was shown by the team at Unununium porting SNAP has never been easier 25hrs to a basic port and less than 3-weeks to a completed project.
Nah, it wasn’t done with assembler, as we announced about a month ago, Unununium also has a C Library now (the doc also mentions this).
It is also quite a feat to port a driver architecture to a new (and in this case, rather “unusual”) OS this fast. It definitely says something about SNAP. The more different (and differing) OSes use SNAP, the better it gets debugged and the smoother the process will become for the Nth port.
Having looked at the SNAP SDK myself, I can only say it quite clean and well-thought-out. The support from the company is quite exceptional, even if there aren’t thousands of dollars to be made on your pet project.
Thumbs up for SciTech.
I think like Jacques Lema, that the use of Assembler can be a problem.
It is nice, that uuu becomes with use of Assebler a little bit faster. But how portable is it?
I know, uuu have an libc, too. But that is based on an assembler written uuu-system.
I think that uuu can be nice. And I like the license they have choosen.
But the only problem I see is the use of Assembler.
Who knows what computer we use in ten years?
Linux runs on different computers: IA32, IA64, Alpha, Sparc, etc.
*BSD runs on differnt computers, too and can be ported to new architectures.
(Open)BeOS is like *BSD and Linux written in C/C++, too and runs on x86 and ppc and can be ported to different hardware.
But uuu have the same problem like MenuetOS, I think. Both are written in Assembler.
And trying to port it to ppc or any other hardware is like writing a completly new OperatingSystem. Right?
Or I am wrong?
Knut
From what I understand, they aren’t interested in portability or compatibility with other OSes.
To give hobbyist OS developers a perspective, what’s the requirement to get your hands on SNAP for your own OS? A licensing fee, a certain level of project maturity, what?
(I’ve been looking at SNAP for some time already, but I thought it would be too costly…)
The short answer is that if your OS is an Open Source project you can provide *access* to our drivers basically free of charge – note this different than providing our drivers for free, which you can not do:( If you wish to include a driver pack with your OS we have a fee structure in place for this
As a long time registered user of SciTech’s Display Driver and SNAP, I really enjoy the product. I use them for OS/2, and even though I have drivers native to my graphics cards, it is SO much easier to switch cards when the need arises. I wish the BeOS port had been finished, as it would have helped out the OS to some point, but alas, I digress. Overall, SciTech has done an excellent job at what they do- making graphics almost universal.
Adam, thanks for your continued support. We will do our best to repay your loyalty with a steady stream of enhancements and updates.
Best Regards,
Andrew Bloo
Thanks for the info, that’s definitely a perspective.
I should also point out that with the SNAP SDK comes a SciTech SNAP graphics VESA driver which can be included with your OS – for a commercial License the SDK will set you back 2,500 (per dev seat) for an open src project – simply download and enjoy:)