You haven't said which programming language the SDK is in, but one thing that makes a bad SDK is one that's a literal translation from an API in a different language.
Case in point:
A Java API for a commercial product is based on the earlier C API. All the magic handles are properly translated to objects, but sometimes the internals stick out. It has a method you can (or, as it turns out: must) call to set the character encoding the library uses to communicate with the server. This makes sense for C, which needs to be told, but if all of your Java API uses Strings, a method like this is nothing more than a please don't suck method you have to call, or things fail.
Heh, funny you should mention the Dutch government and Adam Curry.
It seems the ministry of education has paid a former company of Curry (jamby) a large sum of money for work that they were promised but that didn't happen.
The work/money was too big to give to one company without having other European companies bid on it.
Just a guess. But Solaris needs dramatically more swap than Linux for the same amount of Apache processes. That's because Solaris does not allow you to overcommit memory. Not even if you really really want it, because you know all those Apache processes share a lot of pages.
UPDATE: the binary requires glibc 2.2, it may not work with older versions. Hopefully the final version will have a fully statically linked binary, but we couldn't do that this time around due to crashing problems when loading NVIDIA's libGL.so.
I'd say that the glibc license is another reason why they can't do it.
I'd be interested in a similar success story about China.
Yes, they have internet. But it's highly regulated and censored.
Yes, they have foreign TV stations. Who are all too willing to self-censor so as not to offend the government, for which they in turn get the privilege to sell to an audience of a billion people.
And while you're at it, show us what good technology does in North Korea with respect to human freedom.
It's really very simple, but the Matrox support forum and people choose to make things complicated.
The only thing you really need is to recompile the stock XFree86 mga driver with the binary-only HALlib available. The instructions on the Matrox forum choose to say that that means you should reinstall all of X, from source, nuking everything your distro put in/usr/X11R6.
Of course, just going to the mga driver directory, hacking at it until you get two.o files and only moving mga_drv.o and mga_hal_drv.o to/usr/X11R6/lib/modules/drivers is all that's needed.
My simplified instructions:
Get the Matrox beta source stuff that contains HALlib
Get XFRee86 source (4.0.3 should work I guess)
Do not replace the whole mga directory from XFree86 with the Matrox one. Instead, unpack Matrox's source and copy HALlib to xc/programs/Xserver/hw/xfree86/drivers/mga. Then follow the rest of the Matrox README file, but you can save an awful lot of time if you break out of the "make World" step and instead just go directly to the matrox driver directory and build only that.
Copy the abovementioned driver files to your existing installation (possibly reading up on dpkg-divert first so mga_drv.o won't get overwritten on a minor upgrade)
This printer has a builtin PostScript clone, does 1200x600 dpi, never jams and was one of the cheapest PS printers I could find. Add an old SIMM that you might have lying around and you have a great printer.
See http://www.m-tech.ab.ca/download/sched/ for a batch-oriented solution. You could enhance it with a web interface yourself, but it at least gets you going with scheduling and printed output.
First: the title of this/. item is misleading: CORBA is already open.
I've written my own CORBA implementation in perl using only the freely available documentation from the OMG (see COPE).
Second: about XML and remote procedure/method calls.
From the MS SOAP specification it looks like the scope of SOAP is far more limited than that of CORBA. The same can be said of Dave Winer's XML RPC (I forgot the exact name). The difference is that the XML-based specifications only tell you how to make a method call. What they don't tell you are things like
How to address objects (how do you find them, how does the server keep them apart, do they all have to live in a web server?)
How to write contracts that ensure that client and server speak on the same terms. XML is very flexible, it's easy to add a new field to your structure. But if you write your high performance server in C++ then it will need a recompile with some added code to make sense of that added field. CORBA uses IDL to write the contracts. Or you can use an Interface Repository.
How to write clients and servers portably. Does everyone take their favourite XML library and start hacking, or will there be a standard way to map the SOAP datatypes to native datatypes for all the programming languages people might use?
The embrace-and-extend angle. I noticed that MS felt the need to implement a new HTTP method called M-POST. So even though from a distance everything looks standard (XML, HTTP), a closer look reveals thta for best results people should use web servers, client libraries, proxy-servers and firewalls that are all taught to properly handle M-POST.
Conclusion It might actually make sense to use SOAP as a new transport mechanism with CORBA. Coders would get to keep their language bindings and their existing code base, and CORBA would get a more or less standard way to travel over HTTP (which is the whole point of the SOAP excercise. HTTP means that every firewall will understand it)
the proper way Corel should handle this is to slap the right licenses on the right pieces of code.
That means leaving the existing licenses on all the existing Debian packages (and advertise the fact that they can be redistributed), and doing whatever they want to their own code.
For the Corel code this could mean: "not redistributable for now, GPL later when the beta period is over".
That would also mean that the CD as a whole is not redistributable, but parts of it are.
Slashdot Mirror
You haven't said which programming language the SDK is in, but one thing that makes a bad SDK is one that's a literal translation from an API in a different language.
Case in point:
A Java API for a commercial product is based on the earlier C API. All the magic handles are properly translated to objects, but sometimes the internals stick out. It has a method you can (or, as it turns out: must) call to set the character encoding the library uses to communicate with the server. This makes sense for C, which needs to be told, but if all of your Java API uses Strings, a method like this is nothing more than a please don't suck method you have to call, or things fail.
this article in Dutch makes it clear that simPC uses Linux.
first post? anyway, that was quick.
Heh, funny you should mention the Dutch government and Adam Curry.
It seems the ministry of education has paid a former company of Curry (jamby) a large sum of money for work that they were promised but that didn't happen.
The work/money was too big to give to one company without having other European companies bid on it.
Switch away from Solaris?
Just a guess. But Solaris needs dramatically more swap than Linux for the same amount of Apache processes. That's because Solaris does not allow you to overcommit memory. Not even if you really really want it, because you know all those Apache processes share a lot of pages.
A few weeks ago, there was a post in /. about Knuth. I was surprised to see many ask who he was!
Please, it's is! Knuth still has a series of books to finish :-)
Always fun when you see that on a mailinglist. Preferably one with a web archive.
I'd be interested in a similar success story about China.
Yes, they have internet. But it's highly regulated and censored.
Yes, they have foreign TV stations. Who are all too willing to self-censor so as not to offend the government, for which they in turn get the privilege to sell to an audience of a billion people.
And while you're at it, show us what good technology does in North Korea with respect to human freedom.
It's worse than that. It can't be valid because it doesn't even have a DTD.
But this document is not even well-formed XML. In other words, it is not XML at all. It's plain text with some tags.
For details on what it means for an XML document to be well-formed or valid, see the spec at the W3C
by using those options when putting them in.
It's really very simple, but the Matrox support forum and people choose to make things complicated.
The only thing you really need is to recompile the stock XFree86 mga driver with the binary-only HALlib available. The instructions on the Matrox forum choose to say that that means you should reinstall all of X, from source, nuking everything your distro put in /usr/X11R6.
Of course, just going to the mga driver directory, hacking at it until you get two .o files and only moving mga_drv.o and mga_hal_drv.o to /usr/X11R6/lib/modules/drivers is all that's needed.
My simplified instructions:
I found it highly ironic to read this bit:
"As a desktop platform, it works great, but as a server platform, there are things missing," Henderickson notes.
Almost every other person dismisses Linux as being nice for servers, but not ready for the desktop yet...
Does something like that exist?
I've read about at least one DVD player that can also do MP3 CDs.
This printer has a builtin PostScript clone, does 1200x600 dpi, never jams and was one of the cheapest PS printers I could find. Add an old SIMM that you might have lying around and you have a great printer.
See http://www.m-tech.ab.ca/download/sched/ for a batch-oriented solution. You could enhance it with a web interface yourself, but it at least gets you going with scheduling and printed output.
First: the title of this /. item is misleading:
CORBA is already open.
I've written my own CORBA implementation in perl using only the freely available documentation from the OMG (see COPE).
Second: about XML and remote procedure/method calls.
From the MS SOAP specification it looks like the scope of SOAP is far more limited than that of CORBA. The same can be said of Dave Winer's XML RPC (I forgot the exact name).
The difference is that the XML-based specifications only tell you how to make a method call. What they don't tell you are things like
CORBA uses IDL to write the contracts. Or you can use an Interface Repository.
The embrace-and-extend angle.
I noticed that MS felt the need to implement a new HTTP method called M-POST. So even though from a distance everything looks standard (XML, HTTP), a closer look reveals thta for best results people should use web servers, client libraries, proxy-servers and firewalls that are all taught to properly handle M-POST.
Conclusion
It might actually make sense to use SOAP as a new transport mechanism with CORBA. Coders would get to keep their language bindings and their existing code base, and CORBA would get a more or less standard way to travel over HTTP (which is the whole point of the SOAP excercise. HTTP means that every firewall will understand it)
the proper way Corel should handle this is to slap the right licenses on the right pieces of code.
That means leaving the existing licenses on all the existing Debian packages (and advertise the fact that they can be redistributed), and doing whatever they want to their own code.
For the Corel code this could mean: "not redistributable for now, GPL later when the beta period is over".
That would also mean that the CD as a whole is not redistributable, but parts of it are.
Why Larry puts up with Tom?
Because he is tolerant and understanding.
Wow. it supports the new SGI machines that have been out a cold 10 days.
It's not an NT-only machine if Linux support lags for only 10 days, is it?