MS' code being out there would cause nothing but SCO style problems anyway. What is needed is to force (full) disclosure of (actual) protocols and formats. The last thing we need is accusations of improperly using MS' own implementation.
But this is not about the licensing of Microsoft's code! This is about Microsoft "licensing" their APIs to companies/projects (in Europe). Currently, this license does not allow anyone implementing those APIs to give out their code under an open source license, which is precisely what the argument is about.
Obviously, excluding any and all free software/open source projects (whether by a company or not) is a rather heavy restriction, and that's what the EU commission has been trying to get them to change.
Jack Wolfskin makes some great bags, the Commuter is the most practical laptop bag I've ever used. It has a comfortable shoulder strap plus hideway backpack straps, is the right size for a small to mid-size notebook and has just the right amount of space for accessories etc. They have some bigger ones, too.
After roughing it up for 5+ years without it breaking down in any way I got somewhat bored with it and decided to get something new, a Crumpler Roll-O-Notes (others recommended this one, too). It is very well made and looks good, but I've found it not nearly as practical for everyday work as the Wolfskin one.
I did not think there could be any desktop user that has not heard of k3b...
I did not think there could be any desktop user that doesn't understand k3b is a GUI FRONTEND to several command line tools, one of them being cdrecord-ProDVD for writing DVDs. Without these backends, your k3b will DO NOTHING. Another option for writing DVDs are the dvd+rw-tools, which also work for DVD-R now. THAT is what the question is about, not your GUI-of-the-day.
Perhaps for the next Ask Slashdot we could have a question about free web browsers? Or maybe a free Linux C compiler?
Or maybe have a question about what's the difference about a GUI frontend and an actual work-performing backend?
I'd love to get a Zaurus, but Sharp's regional distribution policies have me really puzzled. It might simply boil down to "only sells good enough in Japan", but it sure looks more like Sharp is randomly releasing/not releasing certain Sharp models in certain countries: no clamshell models in the US, but the new SL-6000 (with built-in WiFi and Bluetooth) apparently to be released there real soon. Old SL-5000 models discontinued in Europe (but still available in stores in e.g. Germany) and no new models planned for release there, either. No Zaurus at all in Canada. Does anybody have an insight on why they are doing this?
Also, before I ask some Japanese friends to bring me a Zaurus from Japan, I'd rather hold out for a clamshell model with built-in WiFi and Bluetooth. Given that the new SL-6000 has both (*and* the VGA screen), does anybody know if that means they are switching away from the clamshell idea for future models, or are they planning to release an updated clamshell model as well?
It's supposed to be confusing. Yes, to the unsuspecting computer guy (and MP!) it reads like pure software patents should not be allowed. What it means in reality, you can read on FFII's web site.
Especially read 4. How CEC/JURI ensure Unlimited Patentability: Some Sample Provisions from their Directive Proposal for a translation into real English: For a patent laywer, the term "computer-implemented inventions" means that everything that potentially runs on a computer (like, Software) can now be patented! Compare this to the existing law, which explicitly forbids pure software patents, yet the EPO (European Patent Office) granted ~30,000 software patents, from one-click shopping over email archiving to progress bars (so much for the "don't extend current practice" bit).
What it would mean for Linux et al. if this practice will be officially sanctioned we all know...
Two additions...
on
Design Patterns
·
· Score: 2, Informative
"Design Patterns" really is an excellent text that everybody doing OO design/programming should read.
While you're at it, pick up the books that inspired the idea of "design patterns" for OO design: Christopher Alexander et.al.'s books on architecture, especially A Timeless Way of Building (introduction to the idea of patterns) and A Pattern Language: Towns, Buildings, Construction, which contains their pattern catalogue (there's a third one in the series which I haven't read yet that describes the application of some of the patterns in a real-world example). Both books are beautifully written, accessible to non-architects, and (interestingly enough) seem to be more popular with computer science people than with architects.
Back to the CS design patterns, the reason why most of the examples draw on UI techniques probably stems from the fact that most patterns result from the author's work on the ET++ framework, which was quite popular in the early 90's (one of the first integrated software development tools for C++, SNiFF, was build with it -- very nice software before it became yet another commercialized packaged bloatware thingy.)
I agree that this is a Linux-related issue that mostly stems from lazyness. I have been using the modules
approach for tool management for years with very good results - even half a decade ago this was more advanced than any Linux approach out there today.
With this approach each tool/version-combination gets its own directory, including subdirectories for libraries, source code, configuration files etc.
You can then use a "module" commando to dynamically change your PATH, MANPATH,... environment to reflect the tools you want to use (note that this supports the usage of a tool, it is therefore not a replacement for package management tools like rpm, which are mainly concerned with installation.)
Each tool/version combination comes with an associated modulefile (which has a tcl-like syntax) where you can influence a user's system environment upon loading/unloading the module. It is also possible to e.g. create new directories, copy default configurations or do platform-specific stuff for a tool (which greatly helps users less fluent in Unix, since they do not have to care about stuff like shell-specific syntax for setting environment variables).
It also allows you to give tool-specific help, e.g.
$ module whatis wordnet
wordnet: Lexical database for English, inspired by psycholinguistic theories of human memory.
$ module add wordnet
This is also very helpful if you want to keep different versions of the same tool (package, library) around and switch between them dynamically, e.g. for testing purposes (think different jdks, qt-libraries, etc.). With modules, you can e.g. do a simple module switch jdk/1.2.2 jdk/1.3.1
and runs your tests again. And you never have to worry about overwriting libraries, configuration files etc. even if they have the same name (since they are kept in a subdirectory for each version).
For our institute I've set up a transparent tool management system that works across our Linux/Solaris/Tru64 platforms. All tools are installed this way (except the basic system commandos which still go into/bin etc.).
Of course, it's a lot of work to start a setup like this, but in a complex environment it is really worth it, especially in the long run.
Slashdot Mirror
But this is not about the licensing of Microsoft's code! This is about Microsoft "licensing" their APIs to companies/projects (in Europe). Currently, this license does not allow anyone implementing those APIs to give out their code under an open source license, which is precisely what the argument is about.
Obviously, excluding any and all free software/open source projects (whether by a company or not) is a rather heavy restriction, and that's what the EU commission has been trying to get them to change.
Jack Wolfskin makes some great bags, the Commuter is the most practical laptop bag I've ever used. It has a comfortable shoulder strap plus hideway backpack straps, is the right size for a small to mid-size notebook and has just the right amount of space for accessories etc. They have some bigger ones, too.
After roughing it up for 5+ years without it breaking down in any way I got somewhat bored with it and decided to get something new, a Crumpler Roll-O-Notes (others recommended this one, too). It is very well made and looks good, but I've found it not nearly as practical for everyday work as the Wolfskin one.
I did not think there could be any desktop user that has not heard of k3b...
I did not think there could be any desktop user that doesn't understand k3b is a GUI FRONTEND to several command line tools, one of them being cdrecord-ProDVD for writing DVDs. Without these backends, your k3b will DO NOTHING. Another option for writing DVDs are the dvd+rw-tools, which also work for DVD-R now. THAT is what the question is about, not your GUI-of-the-day.
Perhaps for the next Ask Slashdot we could have a question about free web browsers? Or maybe a free Linux C compiler?
Or maybe have a question about what's the difference about a GUI frontend and an actual work-performing backend?I'd love to get a Zaurus, but Sharp's regional distribution policies have me really puzzled. It might simply boil down to "only sells good enough in Japan", but it sure looks more like Sharp is randomly releasing/not releasing certain Sharp models in certain countries: no clamshell models in the US, but the new SL-6000 (with built-in WiFi and Bluetooth) apparently to be released there real soon. Old SL-5000 models discontinued in Europe (but still available in stores in e.g. Germany) and no new models planned for release there, either. No Zaurus at all in Canada. Does anybody have an insight on why they are doing this?
Also, before I ask some Japanese friends to bring me a Zaurus from Japan, I'd rather hold out for a clamshell model with built-in WiFi and Bluetooth. Given that the new SL-6000 has both (*and* the VGA screen), does anybody know if that means they are switching away from the clamshell idea for future models, or are they planning to release an updated clamshell model as well?
It's supposed to be confusing. Yes, to the unsuspecting computer guy (and MP!) it reads like pure software patents should not be allowed. What it means in reality, you can read on FFII's web site.
Especially read 4. How CEC/JURI ensure Unlimited Patentability: Some Sample Provisions from their Directive Proposal for a translation into real English: For a patent laywer, the term "computer-implemented inventions" means that everything that potentially runs on a computer (like, Software) can now be patented! Compare this to the existing law, which explicitly forbids pure software patents, yet the EPO (European Patent Office) granted ~30,000 software patents, from one-click shopping over email archiving to progress bars (so much for the "don't extend current practice" bit).
What it would mean for Linux et al. if this practice will be officially sanctioned we all know...
"Design Patterns" really is an excellent text that everybody doing OO design/programming should read.
While you're at it, pick up the books that inspired the idea of "design patterns" for OO design: Christopher Alexander et.al.'s books on architecture, especially A Timeless Way of Building (introduction to the idea of patterns) and A Pattern Language: Towns, Buildings, Construction, which contains their pattern catalogue (there's a third one in the series which I haven't read yet that describes the application of some of the patterns in a real-world example). Both books are beautifully written, accessible to non-architects, and (interestingly enough) seem to be more popular with computer science people than with architects.Back to the CS design patterns, the reason why most of the examples draw on UI techniques probably stems from the fact that most patterns result from the author's work on the ET++ framework, which was quite popular in the early 90's (one of the first integrated software development tools for C++, SNiFF, was build with it -- very nice software before it became yet another commercialized packaged bloatware thingy.)
I agree that this is a Linux-related issue that mostly stems from lazyness. I have been using the modules approach for tool management for years with very good results - even half a decade ago this was more advanced than any Linux approach out there today.
... environment to reflect the tools you want to use (note that this supports the usage of a tool, it is therefore not a replacement for package management tools like rpm, which are mainly concerned with installation.)
/bin etc.).
With this approach each tool/version-combination gets its own directory, including subdirectories for libraries, source code, configuration files etc.
You can then use a "module" commando to dynamically change your PATH, MANPATH,
Each tool/version combination comes with an associated modulefile (which has a tcl-like syntax) where you can influence a user's system environment upon loading/unloading the module. It is also possible to e.g. create new directories, copy default configurations or do platform-specific stuff for a tool (which greatly helps users less fluent in Unix, since they do not have to care about stuff like shell-specific syntax for setting environment variables).
It also allows you to give tool-specific help, e.g.
$ module whatis wordnet
wordnet: Lexical database for English, inspired by psycholinguistic theories of human memory.
$ module add wordnet
This is also very helpful if you want to keep different versions of the same tool (package, library) around and switch between them dynamically, e.g. for testing purposes (think different jdks, qt-libraries, etc.). With modules, you can e.g. do a simple
module switch jdk/1.2.2 jdk/1.3.1
and runs your tests again. And you never have to worry about overwriting libraries, configuration files etc. even if they have the same name (since they are kept in a subdirectory for each version).
For our institute I've set up a transparent tool management system that works across our Linux/Solaris/Tru64 platforms. All tools are installed this way (except the basic system commandos which still go into
Of course, it's a lot of work to start a setup like this, but in a complex environment it is really worth it, especially in the long run.
Did anyone try an upgrade from Madrake 5.3 to 6.0?
Were there any problems with the switch from 2.0 to 2.2? Any KDE user setups lost (e.g. kppp)?