But Sun would have too much to lose by frustrating API reimplementation by open source developers.
If they would really have the audacity to do this, then not only would they lose a tremendous amount of goodwill among the community, OpenOffice.org would then also most likely be forked into a GPL/LGPL project with the proprietary Sun Java API calls removed. Following that, more and more developers would flock from OpenOffice.org to that new fork, just like what happened to XFree86 and X.org. Naturally, such a fork would only be GPL/LGPL licensed (not Sun-licensed), and Sun would then no longer be able to implement any improvements from the open source community in its StarOffice suite.
Detriments abound for Sun. I say we try to persuade the Sun developers that they either replace any proprietary API calls from the code, or reasonably allow the community to add these extensions to any open source Java implementations.
2. RTFA, the major problem is that they're using undocumented sun-only features, almost as if they're deliberately breaking it on Kaffe etc.
Since everyone has access to the OO sources, nothing can stop Kaffe, Apache J2SE, GNU Classpath or any other project to implement these "proprietary" features, as they are called from the source code.
It is most unlikely that sun would actually take legal action for the "unauthorised" use of these non-standard API extensions required for OO support, since they would then really be making dicks of themselves.
OO's Java dependency is actually having a positive overall effect on FOSS development. Because of both Eclipse and OpenOffice.org, the development of much-needed and long overdue open-source mature Java implementations has made great strides recently.
Already Red Hat's OSS Java implementation is sufficiently mature to run Eclipse without any proprietary Sun software. Similar efforts by Debian and others are currently underway to get OpenOffice.org's Java-dependent features to work with exclusively open-source software.
Why do so many people fail to understand this?
I assume that the animosity by many of these "assholes" is actually due to irrational loathing of the Java language and platform in general, thinly veiled behind the "there are currently no mature OSS implementations" excuse. Bah.
Remember that Spanish company that was covered on Slashdot a while back, called Fluendo?
They had developed an open source streaming server called Flumotion, which supported Ogg (Theora video with Vorbis audio).
Even cooler, they have also released a Java Applet called Cortendo, which can play back such streams from a Flumotion server within any Java-enabled browser. It doesn't need any third party player or plugin and it is fully based on open source en open formats!
Now how cool is that?:)
They have a publicly accessible continuous demo stream running, showing them at work in their office, although the stream is sometimes down. I checked it out once, and the video quality is quite impressive.
It's free, it's open source and it allows people to view your streams with minimal effort. Why not try this option?
If it is satisfactory, don't forget to support these guys. They've done some excellent work on this and their decision to release their code under the GPL license should be rewarded!
Disclaimer: I am not affiliated with this company or its employers in any way.
Does the suite the OASIS-format or not?
on
Apple iWork Screenshots
·
· Score: 5, Interesting
So far, still nobody has been able to answer the question wether Apple's iWork suite will be using OASIS-compliant file formats or not.
And even if hot: will iWork at least be able to import from and/or export to OASIS?
Both OpenOffice and KOffice will be supporting OASIS and bringing Apple aboard will probably be crucial in order to establish a serious alternative to the Microsoft file format hegemony.
Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.
At least I can continue working on my project now. The encryption part would have been of later concern anyway.
I have one different question for you, though:
If I have to retrieve data from several url's (PNG images, XML data, etc), then how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog, instead of having to go to a whole load of them?
Whatever your answer: thank you for your help and your swift responses. It is much appreciated! Is there any J2ME forum you could recommend, by the way?
Hey, this is odd: the MIDlet started working om my phone after I had removed the Bouncy Castle midp_classes.zip from the Java build path!
But the Bouncy Castle classes don't give any problems until I use any code that employs KXML2.
I assume that the reason why it only goes wrong why I actually include the function call is because the obfuscator removes the entire XML parser code when it sees that the function is never called.
However, midp_classes.zip continues to stop de MIDlet from running, regardless wether I actually import something from Bouncy Castle or not.
Did you have any problems with combining KXML2 and Bouncy Castle in your MIDlets?
If I'm not able to combine these two fine libraries, then how can I possibly implement a secure solution compatible with all MIDP 1.0 phones (many of which don't support SSL)?:(
I will most likely require both libraries for my project.
I really hope that any of this will make sense to you.;)
Well, before I actually place any code snippets here (it might be contractually problematic), I could describe it briefly.
I wrote a function (part of a MIDlet) that parses an XML file using the KXML2 library.
In a separate MIDlet, I had tested this code with a simple form, showing the output. That worked, both on the emulator and on my device (my trusty Nokia 6600).
Then I tried to use this code in my main MIDlet. I tried launching this function from a thread, which itself would be launched from within a CommandAction input event handler. the reason why I launched the XML parsing code from a thread, because I wanted to show an animating icon during the parsing.
That triggered the problem. So first I thought that it was possibly something related to IO within a separate thread. So I changed the code temporarily (for testing purposes), so that the XML parser would be directly launched by the CommandAction handler, without using a separate thread. This would be hanging the UI while parsing the XML code, but I was just doing this for testing purposes.
It didn't work either. When I comment out the function call (calling the XML Parsing function), all works fine, regardless if the function was called directly from the CommandAction, or from a separate thread launched from the CommandAction.
The question is: why don't I just get a run-time error as soon as the function call is reached? Why won't the MIDlet run AT ALL on the device unless I comment out the function call?
Really weird.
Oh, by the way: it doesn't seem to make any difference wether the XML is parsed from a web page or from an internal XML file within the JAR. The problem occurs eitherway (and the code also functioned flawlessly eitherway when I tested it earlier on the aforementioned simple testing MIDlet).
Coincidentally, I'm working on a J2ME project within my internship right now.
I've been running into this really frustrating problem of code running flawlessly on emulators, why they refuse to even start on actual devices (I only tested it with Nokia devices sofar). You click on the application, and nothing happens. You just remain in the application selection menu.
the culprit is always a certain part of the code. If I comment it out, it runs fine on the device as well. But that's what makes it so weird: apparently these are not run-time errors. The application containing the "bug" doesn't even start on the devices, let alone throw any exceptions or error messages. This makes it so incredibly painful to debug.
I really can't imagine how one could do any serious development if the emulator on one's development machine isn't 100% compatible (or at least as close to 100% compatible as possible) to the real thing.
If any other J2ME developers (more experienced than I) could shed some light on this, it would be much appreciated.
"Moreover, they will be releasing a 30-page guide on how to port these two excellent Mozilla applications to alternative operating systems soon."
Excellent. From what I've heard lately, the Syllable community for some reason seems to be having a lot more difficulty porting Firefox to their OS. The document mentioned above might be very useful to them indeed.
With all due respect to the (very impressive) work by the very few people working on SkyOS, the fact that it is a commercial project makes me quite skeptical.
I don't believe that there is space in the x86 market for another payware OS besides Windows nowadays. I think BeOS and Solaris x86 are proof of that.
So, even though SkyOS seems superior to Syllable at the moment (at least judging from the screenshots and the successful ports), I'd still prefer Syllable, even if only for the fact that it is open source.
But if you ask me, the most promising (and underestimated) smaller alternative OS project at this moment is ReactOS.
If what you are theorizing is indeed true, than the only thing keeping the BeOS from being released by PalmSource would have to be an incentive that would be worth it for PalmSource to go through the relatively minor effort to check the legal status of the code and formally release it.
Community enthusiasm alone along with the undoubtedly large amount of free positive publicity among the developer community would most likely be incentive enough.
Even if we need just a bit more besides that to persuade them, we could challenge them to set up a source bounty, in a similar way how the Blender source code was eventually released.
If I recall correctly, PalmSource bought the BeOS sourcecode after it had failed in the marketplace.
Everyone expected PalmSource to use the BeOS code as a basis to built another mobile OS on.
Now that PalmSource has announced that they would be running future versions of PalmOS on top of Linux, that previous plan has apparently been axed.
Well, in that case I do have a great proposal for PalmSource if they if they are prepared to give something back to the Open Source community: by releasing the BeOS sourcecode under the GPL or any another acceptable OSI-compliant license.
I'll tell you this, mwk88: if PalmSource were to release the BeOS sourcecode, they would create a tremendous amount of goodwill throughout the entire OSS/FS community, even among many of us that do't use BeOS. And with that, you'd be attracting many talented volunteers who are prepared to help customize and optimize Linux for PalmOS. I can't think of any other use that PalmSource would have for BeOS, now that they're switching to a Linux-based platform.
Please do this, PalmSource. If you do, I'm sure you'll become the next cool open-source friendly company idolized on Slashdot (sorry, Novell;) ).
Well, they have already released most of the Winamp 3 sourcecode (without any of the DRM stuff) under the Wasabi project.
Furthermore, the Nullsoft-guys already brought us the open Gnutella protocol.
All of this would indicate that the good people at Nullsoft are pretty cool with open source. So if the Winamp 5 source code is not going to be released, then I think we should blame AOL for that, not Nullsoft.
Sorry to disappoint you, but Microsoft removed exactly that feature from MCE. That was to be expected, of course.:(
The only reason why MCE is based on XP Professional (instead of Home) is because of the Remote Desktop support, which will be required for the extenders to work. At least that's what I've understood about it.
Finally a somewhat positive reply to my proposal!:D
Of course Microsoft could still decide to add OpenBIOS/OpenFirmware-compatibility to Windows as more and more Linux-systems would be sold with such a BIOS. But that would be okay, for two reasons:
1) In order for this to become a priority for Microsoft, a lot of OpenBIOS-equipped Linux-systems must already have been sold first. By the time this is a reality, Linux-use must surely have increased considerably by then! After all, while Microsoft has been waiting for sufficient market share, not to mention spending time developing the necessary boot patch, what OS have those computers been running in the meantime?
2) Compelling Microsoft to support an open (DRM-free) BIOS standard would be a great achievement by itself!
Unfortunately, other replies to this idea where expressions of outrage, because they considered OpenBIOS-equipped systems to be a "restriction" compared to the currently common proprietary BIOS'es. They completely miss the point. OpenBIOS is actually more flexible. If Microsoft decides to continue ignoring this standard, then that's their choice and fault.
Windows XP happens to be incompatible with OpenBIOS, and as far as I can tell, Microsoft has no plans to fix this.
Granted, I indeed implied that in this particular case incompatibility would actually be an advantage.
But that still wouldn't be the fault of the OpenBIOS-developers or the system-builders. Sacrificing legacy compatibility is sometimes a neccessity when designing something new from scratch. The OpenFirmware specification is completely open and Microsoft is free to add support for it to Windows any time.
But they most likely won't, and I came up with this proposal with that (quite safe) assumption in mind.:)
Even though I didn't know Hans Bakker, I'd like to express my deepest sympathies to his loved ones.:'(
It's so bezarre. The atmosphere was great at the RAI conference center yesterday evening. It was a very nice event where like-minded ambitious and talented young people met with eachother and exchanged ideas.
Of course, not only Microsoft is unhappy with this phenomenon. The Linux community is not amused either, since of course we would have preferred to see the customers continuing the use of Linux instead of wiping it from the drive and replacing it with Windows, pirated or not.
But perhaps there is a solution that could kill two bird with one stone: make Linux-systems deliberately incompatible with Windows by supplying them with a legacy-free OpenFirmware-implementation, such as OpenBIOS, which could be optimised specifically for Linux.
Many experienced UNIX and Linux users have been desiring OpenFirmware/OpenBIOS acceptance in the x86-market anyway, and this may be just the chance to make it happen!
It's a perfect solution: On the one hand, Microsoft can no longer complain about Linux-systems being a merely a method to use pirated copies of Windows. On the other hand, selling Linux systems solely with OpenBIOS firmwares (and making some modification to make the motherboards imcompatible with pirated legacy BIOS-versions) guarantees that buyers will be running Linux (or other open-source/free-software OS'es) instead of Windows on it.
And of course, as we all know, an Openfirmware-based BIOS would provide additional technical advantages and features over legacy BIOS implementations.
And finally: true OpenBIOS-enabled Linux-systems would be free from any DRM-crap.
Take the problem, and turn it in to an opportunity Wonderful!:)
I've been wanting to try out Nokia's free (GCC-based) SDK for Series 60 Symbian platforms, but it requires Visual Studio, which I'm not prepared to buy.
There was a website out there somewhere that explained how to set up the SDK on a Linux system, but it was quite a hassle. And the emulator (which is necessary for debugging) didn't run under Linux anyway.
Although I'd be disappointed to boot Windows once more after having used Linux exclusively for some time now, I'd really like to do some serious Series 60 development.
Perhaps it will soon be possible to combine Nokia's SDK with both ReactOS and this free Visual Studio version. At least I'd still be working on a mostly open-source development platform, then!:D
By the way, if anybody can give me some pointers on setting up the Nokia SDK without having to rely on Visual Studio (and if possible without having to use any Microsoft software) while still being able to use a debugger, then please let me know, even though this is blatently off-topic.:)
Europe was supposed to be a single economic union, especially for circumstances like this.
Why are the inhabitants of the smaller EU countries being treated as second-rate citizens?
And what's with letting the UK go first, anyhow? They don't even want to be a member of the EU. They're not even part of the Eurozone!
Wouldn't it have been a lot more sensible for Apple to concentrate on all the Eurozone (single currency) countries first, and expanding to the non-eurozone EU members afterwards?
I'm pro-european, I believe we need to stand together in order to stand up to the US politically and stand on our own feet, but right now, with EUCD and software patents being rammed down our collective European throats on one hand and being discriminated against with the European iTunes-rollout on the other hand, I'm really getting the feeling like we're having to put up with the disadvantages of a united Europe whithout receiving the advantages.
Even if the record companies (and thus not Apple) are to blame, Apple should have filed a compliant to the European Authorities instead of conceding.
As a matter of fact, as I understood it, the entire reason why the European rollout took so long after the US launch was because Apple was trying hard to launch iTunes in the entire EU collectively from the start. Apparently, Apple gave up on that.
Oh well, for us Dutch it will just be another reason to root for our Orange boys when they battle the German mannschaft in tonight's Euro2004 soccer match.
For awhile, I thought OpenAL was going to die a silent death (no pun intended). Therefore, I have been pleasantly surprised lately, with both Creative (one of the initiators of the standard) and NVIDIA releasing Windows drivers with hardware-accelerated suport for the OpenAL API.
Unfortunately, there is still not a single audio solution available, which offers hardware-accelerated support in Linux.
The only promising development I've heard of recently was news a while ago from a group of people who somehow managed to obtain full specs for Vortex sound cards, originally developed by Aureal, which was bought by Creative when bankrupcy was imminent. Apparently, the specs are complete enough for the group to develop Linux drivers that can expose hardware-accelerated 3d audio through the OpenAL API.
Does anyone else have any news on this? As well as news on future hardware OpenAL support in Linux by Creative (which promised this years ago and sofar hasn't delivered on this) or NVIDIA?
What can the fine ALSA developers tell us about this?
Slashdot Mirror
But Sun would have too much to lose by frustrating API reimplementation by open source developers.
If they would really have the audacity to do this, then not only would they lose a tremendous amount of goodwill among the community, OpenOffice.org would then also most likely be forked into a GPL/LGPL project with the proprietary Sun Java API calls removed. Following that, more and more developers would flock from OpenOffice.org to that new fork, just like what happened to XFree86 and X.org. Naturally, such a fork would only be GPL/LGPL licensed (not Sun-licensed), and Sun would then no longer be able to implement any improvements from the open source community in its StarOffice suite.
Detriments abound for Sun. I say we try to persuade the Sun developers that they either replace any proprietary API calls from the code, or reasonably allow the community to add these extensions to any open source Java implementations.
2. RTFA, the major problem is that they're using undocumented sun-only features, almost as if they're deliberately breaking it on Kaffe etc.
Since everyone has access to the OO sources, nothing can stop Kaffe, Apache J2SE, GNU Classpath or any other project to implement these "proprietary" features, as they are called from the source code.
It is most unlikely that sun would actually take legal action for the "unauthorised" use of these non-standard API extensions required for OO support, since they would then really be making dicks of themselves.
Hear, hear!
OO's Java dependency is actually having a positive overall effect on FOSS development. Because of both Eclipse and OpenOffice.org, the development of much-needed and long overdue open-source mature Java implementations has made great strides recently.
Already Red Hat's OSS Java implementation is sufficiently mature to run Eclipse without any proprietary Sun software. Similar efforts by Debian and others are currently underway to get OpenOffice.org's Java-dependent features to work with exclusively open-source software.
Why do so many people fail to understand this?
I assume that the animosity by many of these "assholes" is actually due to irrational loathing of the Java language and platform in general, thinly veiled behind the "there are currently no mature OSS implementations" excuse. Bah.
Remember that Spanish company that was covered on Slashdot a while back, called Fluendo?
:)
They had developed an open source streaming server called Flumotion, which supported Ogg (Theora video with Vorbis audio).
Even cooler, they have also released a Java Applet called Cortendo, which can play back such streams from a Flumotion server within any Java-enabled browser. It doesn't need any third party player or plugin and it is fully based on open source en open formats!
Now how cool is that?
They have a publicly accessible continuous demo stream running, showing them at work in their office, although the stream is sometimes down. I checked it out once, and the video quality is quite impressive.
It's free, it's open source and it allows people to view your streams with minimal effort. Why not try this option?
This is their web site.
If it is satisfactory, don't forget to support these guys. They've done some excellent work on this and their decision to release their code under the GPL license should be rewarded!
Ah, I finally found the Slashdot article here:
Theora Codec Ported to Java
Also, this same technology was used to webcast the GUADEC conference in Norway a while back.
Disclaimer: I am not affiliated with this company or its employers in any way.
So far, still nobody has been able to answer the question wether Apple's iWork suite will be using OASIS-compliant file formats or not.
And even if hot: will iWork at least be able to import from and/or export to OASIS?
Both OpenOffice and KOffice will be supporting OASIS and bringing Apple aboard will probably be crucial in order to establish a serious alternative to the Microsoft file format hegemony.
Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.
At least I can continue working on my project now. The encryption part would have been of later concern anyway.
I have one different question for you, though:
If I have to retrieve data from several url's (PNG images, XML data, etc), then how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog, instead of having to go to a whole load of them?
Whatever your answer: thank you for your help and your swift responses. It is much appreciated! Is there any J2ME forum you could recommend, by the way?
Hey, this is odd: the MIDlet started working om my phone after I had removed the Bouncy Castle midp_classes.zip from the Java build path!
:(
;)
But the Bouncy Castle classes don't give any problems until I use any code that employs KXML2.
I assume that the reason why it only goes wrong why I actually include the function call is because the obfuscator removes the entire XML parser code when it sees that the function is never called.
However, midp_classes.zip continues to stop de MIDlet from running, regardless wether I actually import something from Bouncy Castle or not.
Did you have any problems with combining KXML2 and Bouncy Castle in your MIDlets?
If I'm not able to combine these two fine libraries, then how can I possibly implement a secure solution compatible with all MIDP 1.0 phones (many of which don't support SSL)?
I will most likely require both libraries for my project.
I really hope that any of this will make sense to you.
Well, before I actually place any code snippets here (it might be contractually problematic), I could describe it briefly.
I wrote a function (part of a MIDlet) that parses an XML file using the KXML2 library.
In a separate MIDlet, I had tested this code with a simple form, showing the output. That worked, both on the emulator and on my device (my trusty Nokia 6600).
Then I tried to use this code in my main MIDlet. I tried launching this function from a thread, which itself would be launched from within a CommandAction input event handler. the reason why I launched the XML parsing code from a thread, because I wanted to show an animating icon during the parsing.
That triggered the problem. So first I thought that it was possibly something related to IO within a separate thread. So I changed the code temporarily (for testing purposes), so that the XML parser would be directly launched by the CommandAction handler, without using a separate thread. This would be hanging the UI while parsing the XML code, but I was just doing this for testing purposes.
It didn't work either. When I comment out the function call (calling the XML Parsing function), all works fine, regardless if the function was called directly from the CommandAction, or from a separate thread launched from the CommandAction.
The question is: why don't I just get a run-time error as soon as the function call is reached? Why won't the MIDlet run AT ALL on the device unless I comment out the function call?
Really weird.
Oh, by the way: it doesn't seem to make any difference wether the XML is parsed from a web page or from an internal XML file within the JAR. The problem occurs eitherway (and the code also functioned flawlessly eitherway when I tested it earlier on the aforementioned simple testing MIDlet).
If you still need more information, let me know.
And thank you for your help.
Coincidentally, I'm working on a J2ME project within my internship right now.
I've been running into this really frustrating problem of code running flawlessly on emulators, why they refuse to even start on actual devices (I only tested it with Nokia devices sofar). You click on the application, and nothing happens. You just remain in the application selection menu.
the culprit is always a certain part of the code. If I comment it out, it runs fine on the device as well. But that's what makes it so weird: apparently these are not run-time errors. The application containing the "bug" doesn't even start on the devices, let alone throw any exceptions or error messages. This makes it so incredibly painful to debug.
I really can't imagine how one could do any serious development if the emulator on one's development machine isn't 100% compatible (or at least as close to 100% compatible as possible) to the real thing.
If any other J2ME developers (more experienced than I) could shed some light on this, it would be much appreciated.
"Moreover, they will be releasing a 30-page guide on how to port these two excellent Mozilla applications to alternative operating systems soon."
Excellent. From what I've heard lately, the Syllable community for some reason seems to be having a lot more difficulty porting Firefox to their OS. The document mentioned above might be very useful to them indeed.
With all due respect to the (very impressive) work by the very few people working on SkyOS, the fact that it is a commercial project makes me quite skeptical.
I don't believe that there is space in the x86 market for another payware OS besides Windows nowadays. I think BeOS and Solaris x86 are proof of that.
So, even though SkyOS seems superior to Syllable at the moment (at least judging from the screenshots and the successful ports), I'd still prefer Syllable, even if only for the fact that it is open source.
But if you ask me, the most promising (and underestimated) smaller alternative OS project at this moment is ReactOS.
We'll see how things will turn out.
If what you are theorizing is indeed true, than the only thing keeping the BeOS from being released by PalmSource would have to be an incentive that would be worth it for PalmSource to go through the relatively minor effort to check the legal status of the code and formally release it.
Community enthusiasm alone along with the undoubtedly large amount of free positive publicity among the developer community would most likely be incentive enough.
Even if we need just a bit more besides that to persuade them, we could challenge them to set up a source bounty, in a similar way how the Blender source code was eventually released.
Hmmm...
;) ).
If I recall correctly, PalmSource bought the BeOS sourcecode after it had failed in the marketplace.
Everyone expected PalmSource to use the BeOS code as a basis to built another mobile OS on.
Now that PalmSource has announced that they would be running future versions of PalmOS on top of Linux, that previous plan has apparently been axed.
Well, in that case I do have a great proposal for PalmSource if they if they are prepared to give something back to the Open Source community: by releasing the BeOS sourcecode under the GPL or any another acceptable OSI-compliant license.
I'll tell you this, mwk88: if PalmSource were to release the BeOS sourcecode, they would create a tremendous amount of goodwill throughout the entire OSS/FS community, even among many of us that do't use BeOS. And with that, you'd be attracting many talented volunteers who are prepared to help customize and optimize Linux for PalmOS. I can't think of any other use that PalmSource would have for BeOS, now that they're switching to a Linux-based platform.
Please do this, PalmSource. If you do, I'm sure you'll become the next cool open-source friendly company idolized on Slashdot (sorry, Novell
Well, they have already released most of the Winamp 3 sourcecode (without any of the DRM stuff) under the Wasabi project.
Furthermore, the Nullsoft-guys already brought us the open Gnutella protocol.
All of this would indicate that the good people at Nullsoft are pretty cool with open source. So if the Winamp 5 source code is not going to be released, then I think we should blame AOL for that, not Nullsoft.
Didn't Steve Ballmer grow up in Detroit?
If so, he might still have some contacts there.
That said, it's yet another example of Microsoft reaching out all of its corporate tentacles into almost every conceivable market.
(waiting for the obligatory "If Microsoft Made Cars" jokes to start flying around...)
Sorry to disappoint you, but Microsoft removed exactly that feature from MCE. That was to be expected, of course. :(
The only reason why MCE is based on XP Professional (instead of Home) is because of the Remote Desktop support, which will be required for the extenders to work. At least that's what I've understood about it.
Finally a somewhat positive reply to my proposal! :D
Of course Microsoft could still decide to add OpenBIOS/OpenFirmware-compatibility to Windows as more and more Linux-systems would be sold with such a BIOS. But that would be okay, for two reasons:
1) In order for this to become a priority for Microsoft, a lot of OpenBIOS-equipped Linux-systems must already have been sold first. By the time this is a reality, Linux-use must surely have increased considerably by then! After all, while Microsoft has been waiting for sufficient market share, not to mention spending time developing the necessary boot patch, what OS have those computers been running in the meantime?
2) Compelling Microsoft to support an open (DRM-free) BIOS standard would be a great achievement by itself!
Unfortunately, other replies to this idea where expressions of outrage, because they considered OpenBIOS-equipped systems to be a "restriction" compared to the currently common proprietary BIOS'es. They completely miss the point. OpenBIOS is actually more flexible. If Microsoft decides to continue ignoring this standard, then that's their choice and fault.
Not at all.
:)
Windows XP happens to be incompatible with OpenBIOS, and as far as I can tell, Microsoft has no plans to fix this.
Granted, I indeed implied that in this particular case incompatibility would actually be an advantage.
But that still wouldn't be the fault of the OpenBIOS-developers or the system-builders. Sacrificing legacy compatibility is sometimes a neccessity when designing something new from scratch. The OpenFirmware specification is completely open and Microsoft is free to add support for it to Windows any time.
But they most likely won't, and I came up with this proposal with that (quite safe) assumption in mind.
Even though I didn't know Hans Bakker, I'd like to express my deepest sympathies to his loved ones. :'(
:(
It's so bezarre. The atmosphere was great at the RAI conference center yesterday evening. It was a very nice event where like-minded ambitious and talented young people met with eachother and exchanged ideas.
And then, something like this happens.
Rest in peace, Hans.
Of course, not only Microsoft is unhappy with this phenomenon. The Linux community is not amused either, since of course we would have preferred to see the customers continuing the use of Linux instead of wiping it from the drive and replacing it with Windows, pirated or not.
:)
But perhaps there is a solution that could kill two bird with one stone: make Linux-systems deliberately incompatible with Windows by supplying them with a legacy-free OpenFirmware-implementation, such as OpenBIOS, which could be optimised specifically for Linux.
Many experienced UNIX and Linux users have been desiring OpenFirmware/OpenBIOS acceptance in the x86-market anyway, and this may be just the chance to make it happen!
It's a perfect solution: On the one hand, Microsoft can no longer complain about Linux-systems being a merely a method to use pirated copies of Windows. On the other hand, selling Linux systems solely with OpenBIOS firmwares (and making some modification to make the motherboards imcompatible with pirated legacy BIOS-versions) guarantees that buyers will be running Linux (or other open-source/free-software OS'es) instead of Windows on it.
And of course, as we all know, an Openfirmware-based BIOS would provide additional technical advantages and features over legacy BIOS implementations.
And finally: true OpenBIOS-enabled Linux-systems would be free from any DRM-crap.
Take the problem, and turn it in to an opportunity Wonderful!
For crying out loud, people! How hard is it to download Firefox and switch? Especially with the new settings import wizard?
This is about your internet banking passwords, people! Your hard earned money is at stake here!
Hmmm...
:D
:)
I've been wanting to try out Nokia's free (GCC-based) SDK for Series 60 Symbian platforms, but it requires Visual Studio, which I'm not prepared to buy.
There was a website out there somewhere that explained how to set up the SDK on a Linux system, but it was quite a hassle. And the emulator (which is necessary for debugging) didn't run under Linux anyway.
Although I'd be disappointed to boot Windows once more after having used Linux exclusively for some time now, I'd really like to do some serious Series 60 development.
Perhaps it will soon be possible to combine Nokia's SDK with both ReactOS and this free Visual Studio version. At least I'd still be working on a mostly open-source development platform, then!
By the way, if anybody can give me some pointers on setting up the Nokia SDK without having to rely on Visual Studio (and if possible without having to use any Microsoft software) while still being able to use a debugger, then please let me know, even though this is blatently off-topic.
It was halitosis that drived the dinosaurs to extiction!
Come on Malda, this is "News for Nerds"! Trek is large enough to deserve a separate category icon (even dispite of "Star Trek: Enterprise").
I suggest either a picture of the Original TOS Enterprise (NCC-1701 without any suffix) flying towards the user or a Starfleet Emblem.
You know it makes sense!
Well put, parent poster.
Europe was supposed to be a single economic union, especially for circumstances like this.
Why are the inhabitants of the smaller EU countries being treated as second-rate citizens?
And what's with letting the UK go first, anyhow? They don't even want to be a member of the EU. They're not even part of the Eurozone!
Wouldn't it have been a lot more sensible for Apple to concentrate on all the Eurozone (single currency) countries first, and expanding to the non-eurozone EU members afterwards?
I'm pro-european, I believe we need to stand together in order to stand up to the US politically and stand on our own feet, but right now, with EUCD and software patents being rammed down our collective European throats on one hand and being discriminated against with the European iTunes-rollout on the other hand, I'm really getting the feeling like we're having to put up with the disadvantages of a united Europe whithout receiving the advantages.
Even if the record companies (and thus not Apple) are to blame, Apple should have filed a compliant to the European Authorities instead of conceding.
As a matter of fact, as I understood it, the entire reason why the European rollout took so long after the US launch was because Apple was trying hard to launch iTunes in the entire EU collectively from the start. Apparently, Apple gave up on that.
Oh well, for us Dutch it will just be another reason to root for our Orange boys when they battle the German mannschaft in tonight's Euro2004 soccer match.
For awhile, I thought OpenAL was going to die a silent death (no pun intended). Therefore, I have been pleasantly surprised lately, with both Creative (one of the initiators of the standard) and NVIDIA releasing Windows drivers with hardware-accelerated suport for the OpenAL API.
Unfortunately, there is still not a single audio solution available, which offers hardware-accelerated support in Linux.
The only promising development I've heard of recently was news a while ago from a group of people who somehow managed to obtain full specs for Vortex sound cards, originally developed by Aureal, which was bought by Creative when bankrupcy was imminent. Apparently, the specs are complete enough for the group to develop Linux drivers that can expose hardware-accelerated 3d audio through the OpenAL API.
Does anyone else have any news on this? As well as news on future hardware OpenAL support in Linux by Creative (which promised this years ago and sofar hasn't delivered on this) or NVIDIA?
What can the fine ALSA developers tell us about this?