Python is pretty much established as the leading open-source foundation for high-level scientific computing, competing head-on with tools like Matlab and IDL, either via the pure 'python stack' (Numpy, Scipy, Matplotlib, ipython - http://www.scipy.org/ and tools around them) or a project like Sage (http://sagemath.org).
I suggest you find a *topic* that interests you, that you're likely to work on for fun. If it's something that can benefit your research, even better. Then try to improve the specific package that covers that problem. Python is a much easier language to get into than C++, yet there are ways (with Cython and C/C++/Fortran) of getting performance when needed.
The range of topics where significant contributions can be made ranges from the very low-level, hard-core optimization work to high level user interface and visualization libraries. Special functions, ODE integrators, statistics, code generators, visualization, you name it, there's work to be done and welcoming communities in Python. If you'd like more specific pointers, drop an email to the Numpy discussion list as a starting point, indicating with a bit more precision what topics you find interesting intellectually. You'll find a welcoming reception and guidance on where to go from there, until you can find a project to focus your energy on.
is an excellent overview of the key ideas in 20th century physics, with an eye for the unifying mathematical principles that underlie them all.
In your situation I think it would be very useful, because it gives you a big picture of what the main concepts in physics are like, rather than dwelling too much into the details of any one topic. Give it a read first, and then move on to a few more topic-specific books like others recommended here.
Care to give more mathematical details? While it *looks* good, there's no way to tell if your method is actually numerically doing the right thing without details on your implementation.
The way research works is that you provide technical details of how things are implemented for others to judge/validate/reproduce your results. A pretty picture, no matter how appealing, a research result doesn't make.
I'm actually interested in this, so I'd be happy to have a look at a research paper backing your Java applet (which does look very nice indeed!).
To save the OP the googling: lyx and svn (you can include raw latex for the diehards, if you want).
I've written many collaborative documents in this manner. One involved people across 2 continents, 7 institutions, Linux, OSX and MS Windows, a tight deadline, strict government formatting requirements, and noone with enough time to merge the whole thing.
One simple makefile, and anyone could do at anytime
svn update make pdf
and check that the final PDF was in tiptop agreement with the NIH formatting guidelines, print it, review it, etc.
The guy hitting the 'submit' button was pulling contributions up until a few hours before the actual deadline. Try that with MS Word...
1. matplotlib right now will detect both numeric and numarray, and _not_ resort to the sequence protocol. The poster above said this, and while it used to be true, recent versions have removed this limitation.
2. If you are dealing with large arrays, numarray is _far_ more efficient than Numeric. The problem is for those (like me) who need millions of small arrays rapidly created. Here, numarray has significant creation-time overhead which becomes a killer.
3. Chaco continues to be developed by enthought, but it remains for now somewhat under the radar, since it's not really in shape for public consumption. But matplotlib continues to make great strides, and is being heavily used in production environments.
Mmh. I re-read it once more, and I think you're right, which is a bummer. It really is a _very_ restrictive license.
It's funny, I've been using Gnuplot since 1991 (under Windows 3.0), and I had always thought it really was Free software (though I knew it had nothing to do with GNU).
Not quite. I just carefully read the license file, and it does say:
"Permission to distribute the released version of the source code along with corresponding source modifications in the form of a patch file is granted with same provisions 2 through 4 for binary distributions."
IANAL, but to me this says: you can even distribute a modified, ready to compile version (no need for the end users to manually apply patches). It's just that you need to _also_ include the patch file, so that users can see what is different in your version compared to the official tree.
Agreed, it's not GPL. But it's not quite as bad as others have said. You could concievably even fork it in full, and as long as you keep on providing a big patch file against the last version you forked from, you'd be in full compliance.
I'd prefer to see it be regular GPL, and I do find these license terms a bit annoying. But other than add some minor hassle, they don't really seem to really prevent any kind of third-party modifications.
Lyx (www.lyx.org) currently does not have this feature, but there have been enough discussions about it that there's a good chance it will be available soon. And in every other aspect of document creation, lyx is just absolutely fantastic. Since the underlying typesetting engine is latex, the quality is perfect, and technical journal submissions are a breeze. Yet you have a beautiful interface to work with (use the 1.3.2 qt build), bibliography management (along with pybliographic), instant math editing/preview, etc.
Give it a try. I started using it years ago and never have written a single line of tex by hand since.
Well, until the GIMP gets adjustment layers, it's basically useless for professional photo work (not web work). Adjustment layers allow you to do massive modifications to your image as parameters of the layer, leaving the underlying 'negative' untouched. Photoshop is almost the only thing still forcing me to keep windows around.
Also, the Gimp unfortunately crawls with very large images. Try comparing the performance of the two with 6-10 Megapixel images and you'll see.
Yes, I think the Gimp is great. No, it doesn't beat a tool like Photoshop which has had literally millions of dollars worth of _very talented_ people's time sunk into it. Hopefully in the future it will, but not today. Simple fact.
Have you tried a Petzl Duo belt with the 5 LED module? That's my mountaineering light of choice for big things (I use a tikka for backup purposes). You can use the 5 LEDs on easier/safer terrain, and switch momentarily to the halogen beam when needed.
The halogen beam is zoomable, so you can fit it to your needs. The 5 LEDs are reasonable for watching where you are going, but not for seeing far in front of you. Having the battery pack on your belt/pocket makes it very light on your head, and it's built like a tank. Keep in mind this thing is designed for serious mountaineering, where your headlamp can literally mean your life.
I've been using Petzl headlamps for 12 years, and they've never let me down (I own 3 different ones). Petzl stuff is expensive, but it's the best gear in the world.
The problem in most beowulf-type clusters is not bandwith, it's _latency_. That's what you pay for in Myrinet cards: an on-card cpu which gives ridiculously low latencies. And that's what BigIron has: backplanes which allow not only high throughput, but esp. low latency between cpus.
The area where it's useful to use a cluster is in problems where you can split the calculation in small pieces. Typically you don't need to send tons of data across processors, but you need to do it often and quickly. That's where latency kills you.
So you have an idea which is a solution looking for a problem. Now, since others have already pointed that high-bandwith parallel systems are ultimately a bad idea, it turns out you have a _bad_ solution looking for a problem.
I'm not saying that there aren't ways of improving life in the clustering world. But yours isn't one of them. Sorry.
Why don't you think of it as a project - in the longer term? I agree with others who have said that you should use the right tool for the job, you are after all teaching physics.
But it's also true that in most physics labs, one of the daily tasks is writing data collection and instrument control software. While a lot of that is done using LabView, I see no reason --at least in a teaching setting where the needs are fairly basic-- not to try an alternative.
So what I suggest you do is to consider having a 'computational experimental physics' project whose ultimate goal is writing precisely such software. It would give your students _extremely_ valuable experience, and would show them first hand what I consider to be Linux's biggest strength. To me the power of Linux isn't so much that it's free, but that out of the box you get every language, compiler and development tool under the sun.
So get your students involved, and think of it as a great opportunity to learn how to write a small C library to read data off that port, probably coupled with a Numeric Python back end for data processing and a PyQt front end for the plotting and control (perhaps driving a Gnuplot window).
That's what I would do at least.
Cheers.
Re:You're doing it backwards
on
Extensible IDEs?
·
· Score: 2, Insightful
If "The language choice is based upon features, extensibility, and ease of learning", I'd take a serious look at using Python instead of Perl.
I know these things get religious quickly, but I say this as someone who used to love Perl and write lots of it. Eventually I looked at Python and now I just can't stand the mountain of misfeatures and backwards design that Perl is. Fine for impressing people with cryptic 3-liners which do lots, absolutely useless for implementing large, clean, maintainable systems. Yes, I know full well that it _can_ be done in Perl, but you have to fight at every line to get there.
OTOH, you can obviously also write bad code in Python (or any other language). But the point is that in one (Python) the design 'flows' with you for making things clean, modular and readable, while in the other (Perl) you're swimming always upstream. You can eventually get there, but you'll be exhausted and it will have taken much longer.
Besides, Python has very easy integration with C/C++ (in case you ever need speed in certain critical parts) and bindings for pretty much every GUI toolkit out there.
Keep an eye on the weave project here. Currently it allows you to inline C/C++, and work is under way to have automatic acceleration of arbitrary python code via compilation to C/C++. It's *really* cool.
Just curious, why do you consider a file 'too big for Lyx' at some point? I've written things over 100 pages long with 50+ complex figures and hundreds of equations with zero problems. Of course, I break up the whole thing in chapters and only build the master file once in a while, but I've never seen lyx buckle under the weight of a large file.
I beg to differ on the LyX issue. I (and many others) find it unbelievably useful, as an easy to use front end to the underlying raw power of latex and friends.
I personally use LyX not only for technical stuff (physics) but also for software documentation. The manual for my most recent project IPython was all written in LyX and from the single LyX source I generate html and pdf versions for distribution.
I wrote a little perl tool called lyxport that automates the process of generating PostScript, HTML and PDF from a single LyX source file.
With LyX I have a word-processor like environment (but where I can customize everything I want) that handles long, multipart documents flawlessly, cross-referencing, graphics, bibliographies, you name it. And from that single source I get properly subdivided HTML, ready to print PostScript or fully hyperlinked PDF (just remember to use the hyperref package for that).
I have used MSWord for long documents (100+pages, multi-part with included subdocuments) and it is simply a stupid, devilishly bad joke. It can (I've seen it do it) crash and leave a multi-part document corrupted to the point where the only option is to rebuild the global structure from subdocuments, and the overall design is simply moronic.
Latex was designed with books and technical documents in mind. Lyx was designed to offer easy access to Latex's power. And side tools can pull them together into a near-perfect environment for what the original poster wanted. And by the way, LyX also handles DocBook if you're looking in that direction.
Allows you to prepare and deliver presentations, often just minutes before you step up to the mike - with a native Powerpoint you are leagues ahead of anything Linux can offer.
Except if you need lots of math, which looks horrible under any of Microsoft's programs. Yes, I know there's an equation editor and whatnot, it still looks like crap.
In that case the only reasonable solution is latex+pdf, which beats powerpoint any day (granted, harder to get up and running). google on PPower4 or TexPower, the stuff out there is very impressive.
Quoting: "the only way we have to preserve our freedoms is to stop abusing them."
Er, NO! The point is, these are NOT abuses of freedoms. Fair use rights, freedom of research and publication are *fundamental* rights that should be vigorously defended. That includes Felten, deCSS and many others (not all, there are gray cases).
What you're saying is: 'let's cave in, be nice and they'll leave us alone'. I have news for you: they won't. The more you lower your sight and keep your mouth shut, the harder they'll hit you.
Never heard how an abusive relationship works? Never heard how a dictatorship works?
Ideas like yours are exactly the message they want to propagate: behave and we all mighty will let you play in your little sandboxes.
I'm not saying 'go on a cracking rampage, deface every Microsoft/RIAA/whatever website!'. NO. The fight must be intelligent, the battles well chosen, the arguments clear (people like Felten or Lessig have laid them with pristine clarity).
But by all means, the battles MUST be fought. The amounts of money behind this are so monstrous that the potential to crush voices of dissent is very large. And very fundamental freedoms are directly and indirectly at stake.
Cowardice is definitely NOT the way to defend them.
Not good. I have the cds for the 90's, and I can tell you reading from them will give you a headache quick. The problem is they used *way* too aggressive jpeg compression for *everything* (yes, that includes the text). Jpeg is fine for photos, but sucks big time at sharp b/w like text. The end result is that you can barely read the articles, and only if you squint a lot.
Couple that with a shitty interface, and what could have been a fabulous product is in fact nearly useless.
In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.
Does someone know why high-res flat panels are not more common? My laptop has a beautiful 1400x1050 screen and 1600x1200 is now a normal option for high end laptops. Yet these things are nowhere to be found as standalone displays.
I just don't get it. Why would the manufacturers not offer these displays?
LM 8.1 has been getting *very* negative comments (like I'd never seen before) on their forums. Just go here and see for yourself.
Devfs is causing many people no end of grief, I wonder if Mandrake is going to actually fix a few things while their "production delays" are taken care of.
If they don't, I suspect 8.1 is going to be one bumpy ride for them.
I would like to ask why this committee is so heavily biased towards the legal side in its makeup. Of course there should be lawyers there, since it deals with legal issues. But these issues have a tremendous impact on technology --in particular on its free exchange. Yet the members come from the IP departments of huge corporations, with little visible representation of technical people from the free software world.
The W3C is setting up a standard which will potentially harm many free software projects, yet is not giving that side any true voice in the drafting committee. I find it hard to believe that this was not a deliberate decision driven by corporate interests.
This attitude is sad, short sighted, and at the very least ungrateful. It avoids acknowledging the extent to which the free software world has contributed to the very existence and success of the internet as we know it.
I would like to question the term "Non Discriminatory", as it tries to convey a false sense of democracy. Let me do it with a simple hypothetical example: I open a club, admittance to which is "Non Discriminatory". The only conditions are an entrance fee of US $1.000.000 and a monthly service fee of US $10.000, anyone able to pay the fees is welcome.
Obviously this ends up excluding 99.99...% of the population, and makes it clear that using the expression "Non Discriminatory" is just a smokescreen to cover my legal butt, while making sure that I only get the billionaires I really want in my club.
The RAND policy follows exactly the same underhanded practices: it "requires" charging Free Software projects royalties because not doing so would be "discriminatory" against the poor corporations. Well, it's always nice to know that someone is looking after the interests of the poor Microsofts and IBMs of this world. Their rights would otherwise be trampled on by the evil hordes of Free Software, wouldn't they?
So my specific question, based on the above argument is: how can you really defend this use of the term "Non Discriminatory"? Discrimination is a more complex issue than simply saying "apply the same rule to everyone", as proportinal taxes have long shown. Your committee is full of lawyers who I'm sure know these issues well. So is it just a smokescreen, or do you have other more solid arguments to defend this idea?
Slashdot Mirror
Python is pretty much established as the leading open-source foundation for high-level scientific computing, competing head-on with tools like Matlab and IDL, either via the pure 'python stack' (Numpy, Scipy, Matplotlib, ipython - http://www.scipy.org/ and tools around them) or a project like Sage (http://sagemath.org).
I suggest you find a *topic* that interests you, that you're likely to work on for fun. If it's something that can benefit your research, even better. Then try to improve the specific package that covers that problem. Python is a much easier language to get into than C++, yet there are ways (with Cython and C/C++/Fortran) of getting performance when needed.
The range of topics where significant contributions can be made ranges from the very low-level, hard-core optimization work to high level user interface and visualization libraries. Special functions, ODE integrators, statistics, code generators, visualization, you name it, there's work to be done and welcoming communities in Python. If you'd like more specific pointers, drop an email to the Numpy discussion list as a starting point, indicating with a bit more precision what topics you find interesting intellectually. You'll find a welcoming reception and guidance on where to go from there, until you can find a project to focus your energy on.
By Ian Lawrie:
http://www.amazon.com/review/product/0750306041/ref=dp_top_cm_cr_acr_txt?_encoding=UTF8&showViewpoints=1
is an excellent overview of the key ideas in 20th century physics, with an eye for the unifying mathematical principles that underlie them all.
In your situation I think it would be very useful, because it gives you a big picture of what the main concepts in physics are like, rather than dwelling too much into the details of any one topic. Give it a read first, and then move on to a few more topic-specific books like others recommended here.
Care to give more mathematical details? While it *looks* good, there's no way to tell if your method is actually numerically doing the right thing without details on your implementation.
The way research works is that you provide technical details of how things are implemented for others to judge/validate/reproduce your results. A pretty picture, no matter how appealing, a research result doesn't make.
I'm actually interested in this, so I'd be happy to have a look at a research paper backing your Java applet (which does look very nice indeed!).
Cheers,
f
To save the OP the googling: lyx and svn (you can include raw latex for the diehards, if you want).
I've written many collaborative documents in this manner. One involved people across 2 continents, 7 institutions, Linux, OSX and MS Windows, a tight deadline, strict government formatting requirements, and noone with enough time to merge the whole thing.
One simple makefile, and anyone could do at anytime
svn update
make pdf
and check that the final PDF was in tiptop agreement with the NIH formatting guidelines, print it, review it, etc.
The guy hitting the 'submit' button was pulling contributions up until a few hours before the actual deadline. Try that with MS Word...
A few things:
1. matplotlib right now will detect both numeric and numarray, and _not_ resort to the sequence protocol. The poster above said this, and while it used to be true, recent versions have removed this limitation.
2. If you are dealing with large arrays, numarray is _far_ more efficient than Numeric. The problem is for those (like me) who need millions of small arrays rapidly created. Here, numarray has significant creation-time overhead which becomes a killer.
3. Chaco continues to be developed by enthought, but it remains for now somewhat under the radar, since it's not really in shape for public consumption. But matplotlib continues to make great strides, and is being heavily used in production environments.
Mmh. I re-read it once more, and I think you're right, which is a bummer. It really is a _very_ restrictive license.
It's funny, I've been using Gnuplot since 1991 (under Windows 3.0), and I had always thought it really was Free software (though I knew it had nothing to do with GNU).
Thanks for the correction.
Not quite. I just carefully read the license file, and it does say:
"Permission to distribute the released version of the source code along with corresponding source modifications in the form of a patch file is granted with same provisions 2 through 4 for binary distributions."
IANAL, but to me this says: you can even distribute a modified, ready to compile version (no need for the end users to manually apply patches). It's just that you need to _also_ include the patch file, so that users can see what is different in your version compared to the official tree.
Agreed, it's not GPL. But it's not quite as bad as others have said. You could concievably even fork it in full, and as long as you keep on providing a big patch file against the last version you forked from, you'd be in full compliance.
I'd prefer to see it be regular GPL, and I do find these license terms a bit annoying. But other than add some minor hassle, they don't really seem to really prevent any kind of third-party modifications.
Lyx (www.lyx.org) currently does not have this feature, but there have been enough discussions about it that there's a good chance it will be available soon. And in every other aspect of document creation, lyx is just absolutely fantastic. Since the underlying typesetting engine is latex, the quality is perfect, and technical journal submissions are a breeze. Yet you have a beautiful interface to work with (use the 1.3.2 qt build), bibliography management (along with pybliographic), instant math editing/preview, etc.
Give it a try. I started using it years ago and never have written a single line of tex by hand since.
Well, until the GIMP gets adjustment layers, it's basically useless for professional photo work (not web work). Adjustment layers allow you to do massive modifications to your image as parameters of the layer, leaving the underlying 'negative' untouched. Photoshop is almost the only thing still forcing me to keep windows around.
Also, the Gimp unfortunately crawls with very large images. Try comparing the performance of the two with 6-10 Megapixel images and you'll see.
Yes, I think the Gimp is great. No, it doesn't beat a tool like Photoshop which has had literally millions of dollars worth of _very talented_ people's time sunk into it. Hopefully in the future it will, but not today. Simple fact.
f.
Have you tried a Petzl Duo belt with the 5 LED module? That's my mountaineering light of choice for big things (I use a tikka for backup purposes). You can use the 5 LEDs on easier/safer terrain, and switch momentarily to the halogen beam when needed.
The halogen beam is zoomable, so you can fit it to your needs. The 5 LEDs are reasonable for watching where you are going, but not for seeing far in front of you. Having the battery pack on your belt/pocket makes it very light on your head, and it's built like a tank. Keep in mind this thing is designed for serious mountaineering, where your headlamp can literally mean your life.
I've been using Petzl headlamps for 12 years, and they've never let me down (I own 3 different ones). Petzl stuff is expensive, but it's the best gear in the world.
The problem in most beowulf-type clusters is not bandwith, it's _latency_. That's what you pay for in Myrinet cards: an on-card cpu which gives ridiculously low latencies. And that's what BigIron has: backplanes which allow not only high throughput, but esp. low latency between cpus.
The area where it's useful to use a cluster is in problems where you can split the calculation in small pieces. Typically you don't need to send tons of data across processors, but you need to do it often and quickly. That's where latency kills you.
So you have an idea which is a solution looking for a problem. Now, since others have already pointed that high-bandwith parallel systems are ultimately a bad idea, it turns out you have a _bad_ solution looking for a problem.
I'm not saying that there aren't ways of improving life in the clustering world. But yours isn't one of them. Sorry.
Why don't you think of it as a project - in the longer term? I agree with others who have said that you should use the right tool for the job, you are after all teaching physics.
But it's also true that in most physics labs, one of the daily tasks is writing data collection and instrument control software. While a lot of that is done using LabView, I see no reason --at least in a teaching setting where the needs are fairly basic-- not to try an alternative.
So what I suggest you do is to consider having a 'computational experimental physics' project whose ultimate goal is writing precisely such software. It would give your students _extremely_ valuable experience, and would show them first hand what I consider to be Linux's biggest strength. To me the power of Linux isn't so much that it's free, but that out of the box you get every language, compiler and development tool under the sun.
So get your students involved, and think of it as a great opportunity to learn how to write a small C library to read data off that port, probably coupled with a Numeric Python back end for data processing and a PyQt front end for the plotting and control (perhaps driving a Gnuplot window).
That's what I would do at least.
Cheers.
If "The language choice is based upon features, extensibility, and ease of learning", I'd take a serious look at using Python instead of Perl.
I know these things get religious quickly, but I say this as someone who used to love Perl and write lots of it. Eventually I looked at Python and now I just can't stand the mountain of misfeatures and backwards design that Perl is. Fine for impressing people with cryptic 3-liners which do lots, absolutely useless for implementing large, clean, maintainable systems. Yes, I know full well that it _can_ be done in Perl, but you have to fight at every line to get there.
OTOH, you can obviously also write bad code in Python (or any other language). But the point is that in one (Python) the design 'flows' with you for making things clean, modular and readable, while in the other (Perl) you're swimming always upstream. You can eventually get there, but you'll be exhausted and it will have taken much longer.
Besides, Python has very easy integration with C/C++ (in case you ever need speed in certain critical parts) and bindings for pretty much every GUI toolkit out there.
Just an opinion... Good luck.
- A compiler (very hard, but I can dream)
Keep an eye on the weave project here. Currently it allows you to inline C/C++, and work is under way to have automatic acceleration of arbitrary python code via compilation to C/C++. It's *really* cool.
Just curious, why do you consider a file 'too big for Lyx' at some point? I've written things over 100 pages long with 50+ complex figures and hundreds of equations with zero problems. Of course, I break up the whole thing in chapters and only build the master file once in a while, but I've never seen lyx buckle under the weight of a large file.
I'm honestly curious.
I personally use LyX not only for technical stuff (physics) but also for software documentation. The manual for my most recent project IPython was all written in LyX and from the single LyX source I generate html and pdf versions for distribution.
I wrote a little perl tool called lyxport that automates the process of generating PostScript, HTML and PDF from a single LyX source file.
With LyX I have a word-processor like environment (but where I can customize everything I want) that handles long, multipart documents flawlessly, cross-referencing, graphics, bibliographies, you name it. And from that single source I get properly subdivided HTML, ready to print PostScript or fully hyperlinked PDF (just remember to use the hyperref package for that).
I have used MSWord for long documents (100+pages, multi-part with included subdocuments) and it is simply a stupid, devilishly bad joke. It can (I've seen it do it) crash and leave a multi-part document corrupted to the point where the only option is to rebuild the global structure from subdocuments, and the overall design is simply moronic.
Latex was designed with books and technical documents in mind. Lyx was designed to offer easy access to Latex's power. And side tools can pull them together into a near-perfect environment for what the original poster wanted. And by the way, LyX also handles DocBook if you're looking in that direction.
Allows you to prepare and deliver presentations, often just minutes before you step up to the mike - with a native Powerpoint you are leagues ahead of anything Linux can offer.
Except if you need lots of math, which looks horrible under any of Microsoft's programs. Yes, I know there's an equation editor and whatnot, it still looks like crap.
In that case the only reasonable solution is latex+pdf, which beats powerpoint any day (granted, harder to get up and running). google on PPower4 or TexPower, the stuff out there is very impressive.
Quoting: "the only way we have to preserve our freedoms is to stop abusing them."
Er, NO! The point is, these are NOT abuses of freedoms. Fair use rights, freedom of research and publication are *fundamental* rights that should be vigorously defended. That includes Felten, deCSS and many others (not all, there are gray cases).
What you're saying is: 'let's cave in, be nice and they'll leave us alone'. I have news for you: they won't. The more you lower your sight and keep your mouth shut, the harder they'll hit you.
Never heard how an abusive relationship works? Never heard how a dictatorship works?
Ideas like yours are exactly the message they want to propagate: behave and we all mighty will let you play in your little sandboxes.
I'm not saying 'go on a cracking rampage, deface every Microsoft/RIAA/whatever website!'. NO. The fight must be intelligent, the battles well chosen, the arguments clear (people like Felten or Lessig have laid them with pristine clarity).
But by all means, the battles MUST be fought. The amounts of money behind this are so monstrous that the potential to crush voices of dissent is very large. And very fundamental freedoms are directly and indirectly at stake.
Cowardice is definitely NOT the way to defend them.
Not good. I have the cds for the 90's, and I can tell you reading from them will give you a headache quick. The problem is they used *way* too aggressive jpeg compression for *everything* (yes, that includes the text). Jpeg is fine for photos, but sucks big time at sharp b/w like text. The end result is that you can barely read the articles, and only if you squint a lot.
Couple that with a shitty interface, and what could have been a fabulous product is in fact nearly useless.
just a quick fact: you cant' licence gpl under win32 b/c qt/win isn't itself gpl. But you can use other free software licences (mit, artistic,...).
With this precision, the above stands.
No it won't. Qt Non Commercial Edition for Microsoft Windows.
Not that you'd ever bother checking your facts before posting. That would be a grave violation of the Slashdot code of conduct, wouldn't it?
Qt's licencing is pretty simple: GPL code? get Qt for free. Wanna charge $$$? Then pay Trolltech some. Sounds pretty fair to me.
Does someone know why high-res flat panels are not more common? My laptop has a beautiful 1400x1050 screen and 1600x1200 is now a normal option for high end laptops. Yet these things are nowhere to be found as standalone displays.
I just don't get it. Why would the manufacturers not offer these displays?
Devfs is causing many people no end of grief, I wonder if Mandrake is going to actually fix a few things while their "production delays" are taken care of. If they don't, I suspect 8.1 is going to be one bumpy ride for them.
I would like to ask why this committee is so heavily biased towards the legal side in its makeup. Of course there should be lawyers there, since it deals with legal issues. But these issues have a tremendous impact on technology --in particular on its free exchange. Yet the members come from the IP departments of huge corporations, with little visible representation of technical people from the free software world.
The W3C is setting up a standard which will potentially harm many free software projects, yet is not giving that side any true voice in the drafting committee. I find it hard to believe that this was not a deliberate decision driven by corporate interests.
This attitude is sad, short sighted, and at the very least ungrateful. It avoids acknowledging the extent to which the free software world has contributed to the very existence and success of the internet as we know it.
I would like to question the term "Non Discriminatory", as it tries to convey a false sense of democracy. Let me do it with a simple hypothetical example: I open a club, admittance to which is "Non Discriminatory". The only conditions are an entrance fee of US $1.000.000 and a monthly service fee of US $10.000, anyone able to pay the fees is welcome.
Obviously this ends up excluding 99.99...% of the population, and makes it clear that using the expression "Non Discriminatory" is just a smokescreen to cover my legal butt, while making sure that I only get the billionaires I really want in my club.
The RAND policy follows exactly the same underhanded practices: it "requires" charging Free Software projects royalties because not doing so would be "discriminatory" against the poor corporations. Well, it's always nice to know that someone is looking after the interests of the poor Microsofts and IBMs of this world. Their rights would otherwise be trampled on by the evil hordes of Free Software, wouldn't they?
So my specific question, based on the above argument is: how can you really defend this use of the term "Non Discriminatory"? Discrimination is a more complex issue than simply saying "apply the same rule to everyone", as proportinal taxes have long shown. Your committee is full of lawyers who I'm sure know these issues well. So is it just a smokescreen, or do you have other more solid arguments to defend this idea?