Slashdot Mirror

1. Which operating systems the open sourced version at Sourceforge supports as of now?

Stephane Denis: Actually, the sources are designed for Win32 but they will be compatible for Linux and MacOS soon.
The ENSEIRB (a french engineer school in Bordeaux) are currently porting it for Linux and will probably speed up a lot the developement of the interface.

2. If the wrapper only supports Windows and BeOS, how easy/difficult a port to Linux or MacOS would be?

Stephane Denis: Personally, I continue the win32 emulation/wrapper to validate the wrapper compatibility and then I will do the MacOS version. For Linux, there is already a crew on it working. For the BeOS version, well I probably adapt it later.

A test D3D-2-GL program loading under WindowsXP. Click for larger version.

3. How far down the line the wrapper is? What has to be done yet?

Stephane Denis: Actually the Direct3d 8.0 part (only immediate mode) seems to works more or less, but not sufficiently enough to support really complex programs for the moment. But I expect that more people will look on other parts too, like DirectInput and DirectSound (since they are completly separated modules).

4. How fast/slow the implementation is when compared to a "native" GL app?

Stephane Denis: The speed or efficiency of the wrapper depends mainly of the OpenGL extensions supported. Since most of the time is consumed on rendering and not on API calls, this should be as fast as the original Direct3D code.

But you know, the goal is to get the DirectX API available on non-Win32 platform in order developers be able to create or port actual Direct3D 8 code. For Win32, some video cards like 3DLabs Wildcat or professional SGI video cards do not support Direct3d or Directdraw at all, but they have an excellent Opengl implementation. So the wrapper would be especially useful for theses adapters. A solution already exists, but we want to add Direct3D8 support.

I truly hope that more developers will join this interesting project now so we get things going in a faster pace.

A Direct3D application running in GL mode with the help of the wrapper.

Actually, OSNews has an interview with the guy behind the wrapper, and they even have some screenshots! I hope this wrapper comes to Linux soon!

frankly the installer on 4.4 was buggy to say the least.

It's not so much buggy as it is non-intuitive. Unlike the Linux installers I've seen, it doesn't provide a good step by step wizard for what things you do next. I guess you could call that buggy, but it's not like it doesn't work.

Robert Watson recently commented on this in an interview on OS News. There's apparently work being done now to get a more straight forward, and quite possibly pertier, installer up and ready for FreeBSD 5.0.

It's actually a great interview, worthy of it's own thread.

This interview with Robert Watson describes many of the new 4.5-RELEASE features, and talks about how they relate to the much more advanced work in 5.0. He also talks about how the Linux development targets relate to those in FreeBSD, and says he reads linux-kernel regularly. It
sounds like 5.0 should be incredible.

Concerning native Java: According to this interview with Robert Watson it will be available shortly ofter 4.5-RELEASE. He says "it's in final conformance testing". HTH.

There will be a 4.6, and *possibly* a 4.7, but 5.0 will be -released before then. See this interview with one of the TrustedBSD developers for a good read on the status of 5.0. It also covers the fixes to 4.5.

*cough* you're a moron *cough* Commodore made other machines than C64 *cough*

--
Evan

"He" is a she - Eugenia Loli-Queru. Eugenia is Editor-in-Chief of OSNews.com. Before moving to the U.S. she was a web-designer in the U.K., ported more than 80 Linux/Posix/DOS applications to BeOS and founded the BeUnited BeOS Development Movement in April 2000.

As for a background in embedded systems, I'm not sure - but she is certainly more qualified than you suggest, having experience with many OSes incl. BeOS, AtheOS and FreeBSD among others...

By speeding up development the estimation of time it takes will be easier to get a grip on.

I don't claim to be a programming language creator, instead 3000+
languages in less than 50 or so years should be enough to figure out that
the limitations of programming languages are not going to be solved by
creating another one. But rather in making use of the various languages
where they best fit, thru an action set that enable the creation of
automation of language use.

Comments from the LL1 article

USPTO Article specific reference is here.
Three Primary User Interfaces

The need for speed and language barrier to break:"

What's beyond the language barrier:

What I have found odd about the Virtual Interaction Configuration as I've
attempted to explain it to others over the years, is that there is an
extreamly strong tendancy to preceive in it terms of their individual and
specific mindset focus. i.e. if one is focused into prolog, they preceive
it as a prolog function set, which causes problems in correctly
understanding the actual general action set.

It's possible that communication of the VIC to Carl Sassenrath triggered
off the creation of what is now called REBOL. And it's also very possible
that SHEEP has as well gotten inspiration from the VIC.

Noodle baking...

SHEEP article

Another SHEEP article

Go here if you want screen shots. The link on the story post was just for the download.

If you follow the link to OS News there's a link to the left for screenshots and a bunch of other stuff

Lindows is vaporware. Check OSNews for more information on the subject.

Granted, webserver uptime isn't the gold standard of reliablity, but BSD is a real workhorse - it's huge in ISPs and quite prevalent in telecom as well - both markets where stability is key.

Still, if you look at the architecture and internals much at all, you'll quickly realize that BSD A) is better suited for "real work" than Linux (for instance the Linux I/O layers, especially SCSI and the current single global I/O spinlock, are a disaster area), and, B) has an architecture that results in considerably better stability than Linux over the long haul. (The threads model is a perfect example: KSE is a brilliant solution: you get the parallelism of SMP with the lightning fast user-land context switch and NO kernel overhead. KSE and SMPng will put BSD well on the way to catching Solaris. A good quick overview of these BSD features are in this OSNews interview with FreeBSD's Matt Dillon.)

I'm not at all anti-Linux (in fact, my company bases its primary product on Linux, and we recently partnered to bring IP SAN support to mainframe Linux), but it's simply not fair or accurate to say that the BSDs are not used or suited for real work: In reality, the BSDs are far better suited for "real work" than Linux in some cases, although still far behind Solaris and AIX in many important ways (which may or may not be critical in any given application environment.)

The key,of course, is knowing what attributes are critical in what circumstances and choosing any technology, even the OS, appropriately...

For those like me who kept getting a 404 looking for the PDF, an HTML version of the entire article is available here.

For those who don't like to click all day long- Here

• The article given does some comparisons:
  http://www.usenix.org/publications/library/proceed ings/usenix2000/general/full_papers/seltzer/seltze r_html/index.html

• Then we have the Matt Dillon Interview, where Soft Updates covered as well (point 3):
  http://www.osnews.com/story.php?news_id=153

• Here is a nice french article:
  http://www.freebsd-fr.org/docs/fr/others/systeme-f ichier/

• And this is a series of articles on file systems:
  http://www-106.ibm.com/developerworks/linux/librar y/l-fs7/

• This is the original FFS paper:
  http://docs.freebsd.org/44doc/smm/05.fastfs/paper. html

Assuming its this eugena then I don't think it counts as plagarism.

wow. that's a lot in about 2 weeks.

http://www.osnews.com/story.php?news_id=199

rebol announces it wants to directly compete
against microsoft's .net services architecture
with their own "x-internet" vision and platform.

http://rebol.com/news1a31.html

then rebol announces it is teaming up with streamcast networks
(formerly known as musiccity as the announcement says)
to use rebol for the new morpheus 2.0.
it's weird that i could not find either the new streamcast site
or anything about this announcement on musiccity's current site.

and now eff.org announces it will defend musiccity
against the music industry.

interesting chain of events i'd say :)

While we're on the topic of the FreeBSD vm, let's see what Matt Dillon, the FreeBSD vm hacker has to say about the Linux vm:

"I think Linux is going through a somewhat painful transition as it moves away from a Wild-West/Darwinist development methodology into something a bit more thoughtful. I will admit to wanting to take a clue-bat to some of the people arguing against Rik's VM work who simply do not understand the difference between optimizing a few nanoseconds out of a routine that is rarely called verses spending a few extra cpu cycles to choose the best pages to recycle in order to avoid disk I/O that would cost tens of millions of cpu cycles later on." (Read the rest of the interview here.)

Kakemann

When you are tired of reading the usual crappy ./ comments, you can try reading some more insightful ones [osnews.com].

What's the point in doing this. If they are wrapping Linux kernel in BeOS like calls defies the purpose of the excercise. BeOS has been known for its superb threading whereas Linux well... Let's just say it's not Linux's strongest side.

Can you elaborate? There is nothing wrong with Linux threading. I had heavily threaded BeOS code which was ported to Linux and it ran just as efficient, if not faster! BeOS is known for its "pervasive multithreading", and there's nothing particularly "superb" about it. In fact, for large applications it pretty much sucks ass since BeOS can't guarantee 100% message delivery. Many big name vendors simply abandoned BeOS apps because of this trouble. Or, they created a global lock which got rid of the "pervasive" part of the threading just so they could predict the behaviour of their app. Imagine having your application running fine on a fast 1GHZ box, while it crashes and burns on a slower box because it looses 1 or 2 important messages! Of course, this would indicate a design flaw, but you can't blame the engineers for getting it wrong the first time. Unfortunately for Be, since they were a new entity it only took a couple of wrong turns to tick off potential customers.

Read more on the art of loosing BMessages here (particularly JBQ's posts).

-adnans

Nope. As has been stated over and over again, BeOS cannot and will not be relicensed as Open Source software. There is simply too much proprietary, third party, technology embedded in it that it would take a lot of time, and probably a lot of cash, to strip away. It took SGI almost a year, if not longer, to get XFS released as GPL. Okay, the had to reengineer a good deal of the Linux kernel too. Besides, even if Be manages to strip out the proprietary bits you will most likely be left with a shell of code that will not compile, for a significant amount of time (*cough* Mozilla *cough*).

And IMHO, the "coolest" bits of BeOS have already made it into Linux -> 64-bit journalling FS with attributes, XFS! The other cool BeOS buzzword "pervasive-multithreading" didn't turn out to be that cool after all.

-adnans (ex-BeOS fool)

From Timothy's question concerning GPL infringement, it might be construed that he has already assumed that there _is_ GPL infringement... and he's quite possibly right. Unfortunately becasue SkyOS is closed source, we will never know. Wine OTOH is an implementation of the win32 API written without access to microsoft's windows code... and therefore can't be an infringement of the windows copyright. In theory they _might_ be guilty of
reverse engineering microsoft code but that's alot harder to do and probably not the case. Linux has been successful because it has been open sourced. Microsoft has been successful... well not's get into that, but what I was going to say included the word "illegal". SkyOS will most probably go nowhere. ReactOS OTOH has a very good chance of being successful (althought in a much smaller arean than Linux). In the original posters article, the ReactOS link[osnews.com] links to an article in osnews.com where the authour of ReactOS talks about similarities and differences with PetrOS and also about GUI stuff... but presumably, the best GUI for ReactOS would be implemented through wine... Isn't that the only API / GUI (in the windows world API and GUI are confused) that makes sense?

Taken from and interview on OSnews ( www.osnews.com ), here's the answer to your question:

Robert Szeleney: Until version 3.0, SkyOS was open source. But now, I don`t want SkyOS to be open source. I put so many work into this project, that I don`t want to give to source away. But I accept project members. If someone want to code for SkyOS he can have source. Also, I accept source codes and bugfixes for SkyOS. I don`t put restrictions for coding style. If someone coded for example a new driver, I will change the code to fit into the whole SkyOS coding style.

For those who doesn't know, Robert Szeleney is the man behind SkyOS.

Some people have been playing with using the [SMP] locks on UP too, creating a fully preemptible kernel. A lot of people are playing around with the patches, and we'll see when/if I'll integrate them into the standard tree. It's not a high priority for me: they don't add performance (like the SMP scalability does), and if they improve latency noticeably I'd really rather look at why the latency is bad in the first place.

So right now as far as I'm concerned it's one of those "cool features" things, and it will need some prodding from the real world to show whether it is worth it.

Some people have been playing with using the [SMP] locks on UP too, creating a fully preemptible kernel. A lot of people are playing around with the patches, and we'll see when/if I'll integrate them into the standard tree. It's not a high priority for me: they don't add performance (like the SMP scalability does), and if they improve latency noticeably I'd really rather look at why the latency is bad in the first place.

So right now as far as I'm concerned it's one of those "cool features" things, and it will need some prodding from the real world to show whether it is worth it.

You thought MS had sort of nazi-esque methods? Well, I will now, in this brief essay, reveal to you the hidden truth of Linux, an joint Finnish-German Nazi conspiration for revenge against the victors of WW2. Let's look at the evidence.

During the second World War, Finland was a close allied to the Third Reich, as is clearly illustrated by this photo of a finnish military aircraft. After the defeat of the Axis Powers, a revantionist urge abounds in both countries.

Linux was written by Finnish stuent Linus Thorvalds, a member of the small Swedish-speaking minority of Finland, well known for it's white supremacist tendencies. In this article Torvalds expresses his enthusiasm and admiration for the German-led KDE project. He also makes some unclear statements about the claims of Richard Stallman for calling the operating system GNU/Linux being invalid. Why is this? Obviously, the Nazi -and therefore Anti-Communist- Thorvalds here shows his support for his German allies against the Communist GNU and GNOME [gnome.org] projects.

But what does this hideous Nazi conspiracy want? We cannot, at this point, know. But what we do know, is that Nazies are up to no good. To stop them from achieving whichever horrible goals they hav in mind, I would strongly discourage any use of the Linux kernel or the KDE. Instead, I would recomend the use of a truly democratic operating system.

Thank You.

You thought MS had sort of nazi-esque methods? Well, I will now, in this brief essay, reveal to you the hidden truth of Linux, an joint Finnish-German Nazi conspiration for revenge against the victors of WW2. Let's look at the evidence.

During the second World War, Finland was a close allied to the Third Reich, as is clearly illustrated by this photo of a finnish military aircraft. After the defeat of the Axis Powers, a revantionist urge abounds in both countries.

Linux was written by Finnish stuent Linus Thorvalds, a member of the small Swedish-speaking minority of Finland, well known for it's white supremacist tendencies. In this article Torvalds expresses his enthusiasm and admiration for the German-led KDE project. He also makes some unclear statements about the claims of Richard Stallman for calling the operating system GNU/Linux being invalid. Why is this? Obviously, the Nazi -and therefore Anti-Communist- Thorvalds here shows his support for his German allies against the Communist GNU and GNOME [gnome.org] projects.

But what does this hideous Nazi conspiracy want? We cannot, at this point, know. But what we do know, is that Nazies are up to no good. To stop them from achieving whichever horrible goals they hav in mind, I would strongly discourage any use of the Linux kernel or the KDE. Instead, I would recomend the use of a truly democratic operating system.

Thank You.

You thought MS had sort of nazi-esque methods? Well, I will now, in this brief essay, reveal to you the hidden truth of Linux, an joint Finnish-German Nazi conspiration for revenge against the victors of WW2. Let's look at the evidence.

During the second World War, Finland was a close allied to the Third Reich, as is clearly illustrated by this photo of a finnish military aircraft. After the defeat of the Axis Powers, a revantionist urge abounds in both countries.

Linux was written by Finnish stuent Linus Thorvalds, a member of the small Swedish-speaking minority of Finland, well known for it's white supremacist tendencies. In this article Thorvalds expresses his enthusiasm and admiration for the German-led KDE project. He also makes some unclear statements about the claims of Richard Stallman for calling the operating system GNU/Linux being invalid. Why is this? Obviously, the Nazi -and therefore Anti-Communist- Thorvalds here shows his support for his German allies against the Communist GNU and GNOME projects.

But what does this hideous Nazi conspiracy want? We cannot, at this point, know. But what we do know, is that Nazies are up to no good. To stop them from achieving whichever horrible goals they hav in mind, I would strongly discourage any use of the Linux kernel or the KDE. Instead, I would recomend the use of a truly democratic operating system.

Thank You.

I'm glad you did not copy their "TABLE WIDTH=765" stuff. It kind of sucks unless you happen to use a browsing window of exactly that width.

The printer friendly version is ok, though.

And what's more, the person who submitted the Slashdot article had the gall to steal the name "Eugenia" from the person who wrote the linked article! It's not just copyright infringement, it's identity theft as well!

Just 10 days ago, OSNews also hosted a very interesting interview with AtheOS' Kurt Skauen. Kurt talked about binary compatibility, gcc 3 and a lot of other things.

All OS afectionados love to brag. At least BeOS users can brag and not lie. I've laid out several reasons why (as a Media OS) BeOS beats Linux. If you'd care to refute any of these, be my guest.

Sure, list them. I happen to know a couple of people who are migrating their (BeOS) Media applications straight to Linux. No point in building your software/hardware on a dead/unsupported system. And from my own experience in porting BeOS software to Linux, I can say that Linux provides most everything that is needed and much more (e.g. progress).

BeOS was designed to encourage highly multithreaded programs with fast GUIs.

Sadly, this hasn't panned out too well. It takes quite long time to get threads right. Porting apps from other OSes took considerable effort and willpower. Be talked about the "tractor app" thingy since 1995. To date there hasn't been a single native tractor app for BeOS. So much for the highly multithreads programs with fast GUIs.

...there is the fact that BeOS's API encourages developers to extensively use attributes

And in the process they pretty much lock themselves to BeOS' APIs. And we all know how large the BeOS installed base is :-)

but you don't see applications doing this prevasively, do you?

No, because well, there's no reason to do so, unless there's a broader standard, and clearly there isn't (look for ACL/extended attributes integration in the 2.5.x kernel tree). BeOS was ahead of the pack, but unfortunately for Be and its develoeprs that meant shit..

the lack of any central encouragement precludes large scale integration of media apps.

Again, this hasn't helped Be one bit. Why? Because the Media Kit is so full of bugs, not to mention horribly documented, it is practically impossible for anyone outside of Be to write any Media add-on more complex than an audio codec.

...which is why neither GNOME nor KDE use threads extensively

The only apps that really benefit from threads are media applications and most, if not all of them do use threads. GTK+ 1.2.x is already thread safe. Qt 3.0 is too. But because developers are NOT FORCED to use threads you will most likely only encounter them when they actually make a difference! I do wish Mozilla used separate threads to manage each browser window. Anyway, threads have their place but don't glorify them too much (just watched over 3 hours of perfectly synced DVD, thanks to some clever threading :)

Where? I looked through the entire BeOS board, couldn't find anything related to multithreading. Did searches for both "GUI" and "thread." "Thread" turned up on irrelevant hit, while "GUI" simply turned up some articles about improving the GUI. What posts are you referring to?

This thread. Read the comments by JBQ.

"Multithreading sounds cool, but it's an unnecessarily complex beast to master, and the fact that it's asynchronous by nature makes it fairly hard to debug, and creates some behaviors that vary a lot between machines. Plus, people learn and like to write synchronous code. "

and

"The problem with BeOS isn't the fact that the kernel allows for multiple threads. The problem is the fact that developers are forced to use multithreading under BeOS, that they are forced to use the BeOS locking mechanism, and that various bugs and limitations in BeOS make all that even harder than it should already be. Sure, a computationally intensive application might (and probably will) benefit from spawning an extra thread. Sure, a game that needs to send feedback to different output devices might benefit from putting the game engine in a separate thread. But in many cases, it's just overkill. "

-adnans

You're exactly right. Microsoft's been trying to
have it both ways the whole time.

I wrote an article on this a while back... it seemed to me Microsoft's arguments were a lot like having a car mechanic say he coldn't remove
your car stereo because that would entail removing the battery too and then the car wouldn't work.

An application? Or integral part of the OS? Which way is it, Redmond?

--

first, its NOT free. you dont get ALL the source. so its closed source. you get some example code and some binaries.

second, it has NO memory protection. NONE! (if you read their forum, in development, one of the v2 guys confirmed the question). no memory protect, so your app can crash the kernel (sounds like a mac os or dos)... Having no memory protection means you have to give 100% trust to all your programs + programmers to do the correct thing. heh and we all know that means nothing in the real world.

sounds crap. ok, so its written in 100% asm. whoa. big deal. if your into hobbyist os (check my FAQ!!:), there are lots of startup OSii in 100% asm. nothing to get wet knickers over.

(i found it VERY strange to see this story on slashdot, if you read the OS dev newsgroups or follow OSii boards, little osii like this are announced *ALL* the time at an alarming rate. there really isnt anything special about this one)

but.. BUT! Creating OSii isnt everyones cup of tea and its good to see people still doing it ;)

mebbe i should make a distinction here about hobbyist os' and main stream type os. ala v2 vs linux. talk about apples and oranges.

linux has grown way past being a hobbyist os to a main stream os some time ago.

vsta + tinyos strikes me as being stuck inbetween, vsta more hobbyist than tinyos....

anyway.

if you do have an itch to scratch, you can check my faq for basic questions + answers on several os dev topics...

Write your Own Operating System [FAQ]!

OS News Ran this in early September, with a good link to Mackido's site. Here is is Mackidos take on it. The basics: USB 2.0 is no where near what FireWire offers now! When USB 2.0 hits the streets, FireWire will be even faster. Plus USB 2.0 was designed for low end devices, Mackido discusses why it would be a nightmare for anything else.