Let's see -- you need 10 TB, low bandwidth. The last 250GB drive I bought was $100. That would be $4,000 for 40 drives. If you can buy 10 old (400 MHz-ish) desktop computers for $100 each (should be easy enough -- there's alot of them about), hosting 4 drives per machine, along with a 10-port hub (100 Mbps ethernet) for, say, $100 (probably much less), then that comes to a little over $5,000.
Read the next slide -- it says it took a mere 5 hrs to rebuild the source tree on a 486/50!!
Clearly, the 50gb number is an exaggeration. Maybe it includes lots of redundant cruft which isn't actually compiled. Or perhaps documentation. I can't see any way that a 486/50 could compile 50 gb of code in 5 hours. That's 10 gb of code per hour, or about 2.7 mb of code per second! At 27 chars per line avg. that would be 100,000 lines per second -- on a 486/50!
Sure, Windows comes with a built-in language: Javascript! It's an interesting way for kids to learn to program -- you can do neat stuff with a browser...
But note that "generics" or "parametric types" have been present in languages such as Eiffel or Sather for well over a decade, and for much longer in ML.
ML (at least) has parametric types, but not generics.
Wrong - bottom part would fall to earth
on
The Space Elevator
·
· Score: 1
Remember -- the whole space elevector together acts just like a geo-synchronous satellite. It's just a particularly long and skinny one. Theoretically (barring any atmospheric effects, or other "noise"), it would "float" - no force would be required to anchor it down to earth (but due to the noise, some force would be required).
If it were cut in two, then it would become 2 satellites. The lower satellite (the piece closer to earth) would have a lower orbit, and therefore would require a greater velocity than it had, to remain in orbit. It would therefore fall. The top half would have a further-out orbit, and would be going too fast to remain in orbit. It would therefore escape orbit (i.e. would be flung out to space).
Python is dog-slow compared to C++, inherently. Implying that it somehow isn't, or even worse, that it can be faster, or still worse, that it can be massively faster, strikes me as silly.
In my experience, most batteries (except for some, but not all, lead acid gel batteries) die pretty quickly. They never last more than about 2 years, at best. (Although it sounds like the author is complaining about something even worse). I can no longer recall just how many cordless phones I've bought...
Yes, I read the article (which I loved). Unlike the author, however, I _love_ the shell.
From command line:
cd/movie
mplayer -vo x11 Ha
and the movie (which starts with the letters "Ha") starts playing. Why do I need a GUI for that? It could only be slower.
If I cared enough, I might make a quickie script to do the -vo x11 and cd/movie parts for me. But I don't care enough. What I might do, now that I'm thinking about it, is to add an alias to my.bashrc for mplayer, to add in the "-vo x11" part for me. That way, I don't have to remember some new script name -- I only have to remember "use mplayer for playing movies". It would take me less time than it takes me to write one sentence of this note.
Eventually, I'll set it up for my wife to use. She's not fond of the shell (like many people, she seems to have an irrational fear of it). Perhaps I'll set up the file associations appropriately (the file manager becomes the GUI -- click on the file and mplayer starts playing it). That would take me about one minute, I'd estimate.
More likely, I'll set up something a little fancier, like I did for our music files (the way that works is, I have a script which runs once a day, and generates a desktop link for each album. The purpose of this design is mostly is to associate a particular.jpg with an.mp3/.ogg -- e.g. "The White Album.jpg" goes with "The White Album.ogg"). That will take me about 10-30 minutes, but it will be oh so sweet.
What's my point? Within minutes, I can accomplish just about anything I want to, with the command line/scripting.
I've been using Linux for a few months -- switched over to using it as my main machine. For the most part, I find it more productive than Windows.
However, often, for one reason or another, I want to run something on windows. For example, I like the screen magnifier which comes with Visual C. So, I have 2 monitors on my desk -- one is Linux and one Win2k. With Samba, I have a pretty seamless connection between them. I often compile my code on Windows to use the wonderful Visual C debugger. But then I'll switch back to Linux to take advantage of the awesome Valgrind memory debugger.
All in all, Linux gets the egde, because of the huge number of free apps. Gimp is fantastic, once you get over the initial hump (there's an initial hump for Photoshop, too). Kino is fine for video editing.
Case in point: the other day, I wanted to copy a CD of mine to my hard drive. I thought "let's check Google, and see what apps are out there to do this". About 10 minutes later, I had downloaded a Linux app (readiso) which did exactly what I wanted. It was free, which was nice. But more importantly, because it was free, it was very easy for me to make use of.
This kind of thing happens about every week or so -- I find some nifty free app for Linux which does something I want to do.
If all things were equal, I'd use Linux. I just can't trust Microsoft. With Linux, I know what I'm getting.
But things aren't all equal. Linux has a much larger base of useful apps than Windows. OK, perhaps with Windows, I could buy apps to do what I want. But what am I supposed to do? Buy a bunch of movie editing apps to see if there are any which do what I want? With Linux, I download 2 or 3 apps, and decide what I like.
Back to my subject line: I use both (Win2k + Linux). I trust Linux more, and find it more useful and flexible most of the time. But alot of times, I want to use a Windows app, for one reason or another.
Qt is a great cross-platform C++ environment. It's a highly polished GUI framework, but also general-purpose. In terms of cross-platform C++ frameworks, I don't know of anything that beats Qt.
Sash is an example of an application-development framework built on IE. Sash is an IBM project -- I believe it might be open source. Not sure. Does seem to be free, at least. You build apps on top of Sash (they call them, ahem, "Weblications"). The core functionality is mostly provided by IE.
Sash-XB is another IBM project, which builds on Mozilla in the same way.
Knoppix sounds like it would be perfect. It's a bootable Linux CD, which includes lots of useful software, including Moz and Open Office. So, users couldn't accidentally screw it up. It did a nice job with the 2 computers I tried it on. It can access an attached hard drive or floppy, for storing files. Not sure how it deals with Moz profiles, for setting up email. But you could always set them up with web mail.
I use KDE with Moz and OO -- believing each to be the best-of-breed. I don't find the lack of integration too problematical. But it would be great if RedHat spends some resources on improving the integration between these three -- perhaps that will be a beneficial outcome.
At this point your best argument to be made for Linux lies in three points, one of which you nailed. First is flexibility. Use that. Second is openess, both in source but more importantly protocols. Third is security.
Actually, I think cost is alot more important than you're making it out to be. What's really great about Linux is that you can stay current with all the apps you've invested your time learning -- e.g. Gimp, Open Office, etc. It's not just about the cost of Windows -- it's the cost of the whole package. Most Windows people get way out of date with their software -- e.g. my sister uses some ancient dusty old Works on one computer, and a newer one on a more recent computer. File formats are incompatible. Why this unsatisfactory state of affairs? Because it's too expensive and/or too much trouble to upgrade. With Linux, it's so easy/cheap to upgrade. There's _one_ source for _everything_ (if you use apt-get, or an equivalent). And it's all free.
Another example is PhotoShop -- yes, Photoshop is better than the Gimp. But, most people I know who use Photoshop at home have some really ancient version, which is much worse than the Gimp. Here, it's really the cost that's the issue. The same can be said for Microsoft Office -- which I very much doubt Microsoft will ever give away for free.
As I see it, ultimately, that's the major strength of Linux -- it gives cost-conscious users an easy and cheap way to stay current. In any case, that's the main reason I switched our household to Linux. (we have about 5 or 6 active or semi-active computers -- WinXP's copy protection drove the final nail in the coffin)
ok, first there's mysql. their license page [mysql.com] is rather surprising. they state that their client lib is lgpl, and yet in embedded systems it seems like they're saying it's gpl. kind of odd really - seems like they're trying to extend it.
The discrepancy comes in defining what "linkage" means. One of their examples of when you need to pay for a license (i.e. otherwise your code must be GPL):
You have a commercial application that ONLY works with MySQL and ships the application with the MySQL server. This is because we view this as linking even if it is done over the network.
It's very strange. So, does this mean you can ship MySQL with your product, as long as your product _could_ work without MySQL? (although badly, perhaps). That's what they say here. But what does the license say? Well, the license in question is the GPL. So they're saying this about _all_ GPL code.
So, yes, you can link your proprietary code with their LGPL client library, and ship the combination without encumbrance. However, if you also ship MySQL in the same "bundle", then everything is subject to GPL. (whatever "bundle" means exactly -- I'd assume it is interpreted broadly, so it actually means something at all -- that is, you can't bypass the clause through petty tricks, like shipping MySQL on a different CDROM)
The same reasoning could, I would think, be applied to programs which only run on the Linux kernel. However, as you say:
the gpl'ed linux kernel specifically allows closed source modules under certain conditions
So it appears the Linux kernel license is not pure GPL -- it explicitly allows some linkage. That would put it somewhere in-between LGPL and GPL (I've never studied the Linux license -- always assumed it was plain-old GPL). Does the Linux kernel license explicitly allow non-GPL programs which only run under the linux kernel? Does it need to? It would seem the MySQL folks would say that it does need to explicitly allow this.
So who's right?
That's where case law comes in. But there is no case law that I'm aware of. So nobody can say definitively who's right. And, ultimately, different countries will establish different case law over the years. So it will be a messy answer at best.
the example i gave, tivo, has closed source software written by tivo
According to the GPL, Tivo clearly must GPL any modifications they make to GPL code. I think it's a grey area whether or not Tivo must GPL all of the code on their embedded platform. It's a question of how tightly bound their code is to the GPL code. The LGPL explicitly allows linkage to non-GPL code. This implies that GPL code does not allow linkage. But what is linkage, exactly? Is loading a DLL the same as linkage? According to Cygwin, you cannot link a non-GPL program with their DLL, unless your program is GPL. Is this true of all GPL code? I'd imagine so. Or at least, Cygwin imagines it is so.
But, of course, as is always the case with legal matters, nobody really knows the answer until it has been tested in court. And even then, we can only know the answer _somewhat_ better than we did previously. The more the GPL is tested, the more exactly we know the answer. I don't believe the GPL has ever been tested. Which would explain why there's so much doubt about its legal (vs intended) meaning.
if someone uses the c api to write a mysql client application, they can distribute that code as closed, bsd, gpl, or whatever licensed software. and that's true if it is embedded, on a server, [...]
Of course, you can distribute any code you write, any way you want to. What you can't do is distribute your code in conjunction with MySQL. If you do that, you must pay MySQL licensing fees, according to MySQL. To make it more clear: you _can_ distribute your proprietary extensions, and tell your customers to separately install MySQL (I _think_ you can do this, but I could be wrong). But what you can't do is to distribute MySQL along with your proprietary extensions. To do this, you'd have to GPL your extensions. I think this is how all GPL code works. But it is certainly the case with MySQL -- they go to some lengths on their website to make this clear -- in laying out the conditions under which you must purchase a MySQL license.
I don't really understand your question, I don't think -- no, I don't want the freedom to be bound. I just want the freedom to make money!
But it's not really about what I want (since I don't have any current plans to sell products with embedded DB's) -- I'm speculating on what others may find relatively attractive about PostgreSQL vs the (GPL'd) SAP database. As a general matter, BSD is probably more attractive (from a business perspective) than GPL. At least in terms of licensing restrictions (i.e. all other things being equal, which they never are...)
It's a tricky question. Yes, you can embed any GPL code you want, as long as you make your code GPL. But what if you want to _sell_ a program? Then GPL is a liability -- probably makes it impossible. You have to sell support, or something like that. Unless you have patent protection, in which case you can give away the source (GPL), but sell licenses to use the patent.
In the case of Tivo, they're selling hardware, not software, so it works out OK. Also, their business model is protected by patents (perhaps).
Slashdot Mirror
Let's see -- you need 10 TB, low bandwidth. The last 250GB drive I bought was $100. That would be $4,000 for 40 drives. If you can buy 10 old (400 MHz-ish) desktop computers for $100 each (should be easy enough -- there's alot of them about), hosting 4 drives per machine, along with a 10-port hub (100 Mbps ethernet) for, say, $100 (probably much less), then that comes to a little over $5,000.
A bit unweildy, perhaps...
Read the next slide -- it says it took a mere 5 hrs to rebuild the source tree on a 486/50!!
Clearly, the 50gb number is an exaggeration. Maybe it includes lots of redundant cruft which isn't actually compiled. Or perhaps documentation. I can't see any way that a 486/50 could compile 50 gb of code in 5 hours. That's 10 gb of code per hour, or about 2.7 mb of code per second! At 27 chars per line avg. that would be 100,000 lines per second -- on a 486/50!
Sure, Windows comes with a built-in language: Javascript! It's an interesting way for kids to learn to program -- you can do neat stuff with a browser...
Runs on both Windows 2000 and Linux
ML (at least) has parametric types, but not generics.
Remember -- the whole space elevector together acts just like a geo-synchronous satellite. It's just a particularly long and skinny one. Theoretically (barring any atmospheric effects, or other "noise"), it would "float" - no force would be required to anchor it down to earth (but due to the noise, some force would be required).
If it were cut in two, then it would become 2 satellites. The lower satellite (the piece closer to earth) would have a lower orbit, and therefore would require a greater velocity than it had, to remain in orbit. It would therefore fall. The top half would have a further-out orbit, and would be going too fast to remain in orbit. It would therefore escape orbit (i.e. would be flung out to space).
Python is dog-slow compared to C++, inherently. Implying that it somehow isn't, or even worse, that it can be faster, or still worse, that it can be massively faster, strikes me as silly.
In my experience, most batteries (except for some, but not all, lead acid gel batteries) die pretty quickly. They never last more than about 2 years, at best. (Although it sounds like the author is complaining about something even worse). I can no longer recall just how many cordless phones I've bought...
Yes, I read the article (which I loved). Unlike the author, however, I _love_ the shell.
/movie
/movie parts for me. But I don't care enough. What I might do, now that I'm thinking about it, is to add an alias to my .bashrc for mplayer, to add in the "-vo x11" part for me. That way, I don't have to remember some new script name -- I only have to remember "use mplayer for playing movies". It would take me less time than it takes me to write one sentence of this note.
.jpg with an .mp3/.ogg -- e.g. "The White Album.jpg" goes with "The White Album.ogg"). That will take me about 10-30 minutes, but it will be oh so sweet.
From command line:
cd
mplayer -vo x11 Ha
and the movie (which starts with the letters "Ha") starts playing. Why do I need a GUI for that? It could only be slower.
If I cared enough, I might make a quickie script to do the -vo x11 and cd
Eventually, I'll set it up for my wife to use. She's not fond of the shell (like many people, she seems to have an irrational fear of it). Perhaps I'll set up the file associations appropriately (the file manager becomes the GUI -- click on the file and mplayer starts playing it). That would take me about one minute, I'd estimate.
More likely, I'll set up something a little fancier, like I did for our music files (the way that works is, I have a script which runs once a day, and generates a desktop link for each album. The purpose of this design is mostly is to associate a particular
What's my point? Within minutes, I can accomplish just about anything I want to, with the command line/scripting.
A GUI is like a jail. A pretty jail.
Just forget the GUI stuff. I use mplayer from the command line, and it's wonderful. Very flexible, handles lots of formats, does everything I want.
GUI's are generally a pain, and I avoid them whenever possible.
Mod points? I don't need no stinkin' mod points!
The government is saying, quite rightly, that if you provide a conduit to the net, then you must take responsibility for that conduit.
That's what governments do best - make sure there is accountability for whatever goes on (without regulating what goes on).
I've been using Linux for a few months -- switched over to using it as my main machine. For the most part, I find it more productive than Windows.
However, often, for one reason or another, I want to run something on windows. For example, I like the screen magnifier which comes with Visual C. So, I have 2 monitors on my desk -- one is Linux and one Win2k. With Samba, I have a pretty seamless connection between them. I often compile my code on Windows to use the wonderful Visual C debugger. But then I'll switch back to Linux to take advantage of the awesome Valgrind memory debugger.
All in all, Linux gets the egde, because of the huge number of free apps. Gimp is fantastic, once you get over the initial hump (there's an initial hump for Photoshop, too). Kino is fine for video editing.
Case in point: the other day, I wanted to copy a CD of mine to my hard drive. I thought "let's check Google, and see what apps are out there to do this". About 10 minutes later, I had downloaded a Linux app (readiso) which did exactly what I wanted. It was free, which was nice. But more importantly, because it was free, it was very easy for me to make use of.
This kind of thing happens about every week or so -- I find some nifty free app for Linux which does something I want to do.
If all things were equal, I'd use Linux. I just can't trust Microsoft. With Linux, I know what I'm getting.
But things aren't all equal. Linux has a much larger base of useful apps than Windows. OK, perhaps with Windows, I could buy apps to do what I want. But what am I supposed to do? Buy a bunch of movie editing apps to see if there are any which do what I want? With Linux, I download 2 or 3 apps, and decide what I like.
Back to my subject line: I use both (Win2k + Linux). I trust Linux more, and find it more useful and flexible most of the time. But alot of times, I want to use a Windows app, for one reason or another.
See Walmat.com...
Qt is a great cross-platform C++ environment. It's a highly polished GUI framework, but also general-purpose. In terms of cross-platform C++ frameworks, I don't know of anything that beats Qt.
Another thought is Java, of course...
Sash is an example of an application-development framework built on IE. Sash is an IBM project -- I believe it might be open source. Not sure. Does seem to be free, at least. You build apps on top of Sash (they call them, ahem, "Weblications"). The core functionality is mostly provided by IE.
Sash-XB is another IBM project, which builds on Mozilla in the same way.
Knoppix sounds like it would be perfect. It's a bootable Linux CD, which includes lots of useful software, including Moz and Open Office. So, users couldn't accidentally screw it up. It did a nice job with the 2 computers I tried it on. It can access an attached hard drive or floppy, for storing files. Not sure how it deals with Moz profiles, for setting up email. But you could always set them up with web mail.
I use KDE with Moz and OO -- believing each to be the best-of-breed. I don't find the lack of integration too problematical. But it would be great if RedHat spends some resources on improving the integration between these three -- perhaps that will be a beneficial outcome.
Actually, I think cost is alot more important than you're making it out to be. What's really great about Linux is that you can stay current with all the apps you've invested your time learning -- e.g. Gimp, Open Office, etc. It's not just about the cost of Windows -- it's the cost of the whole package. Most Windows people get way out of date with their software -- e.g. my sister uses some ancient dusty old Works on one computer, and a newer one on a more recent computer. File formats are incompatible. Why this unsatisfactory state of affairs? Because it's too expensive and/or too much trouble to upgrade. With Linux, it's so easy/cheap to upgrade. There's _one_ source for _everything_ (if you use apt-get, or an equivalent). And it's all free.
Another example is PhotoShop -- yes, Photoshop is better than the Gimp. But, most people I know who use Photoshop at home have some really ancient version, which is much worse than the Gimp. Here, it's really the cost that's the issue. The same can be said for Microsoft Office -- which I very much doubt Microsoft will ever give away for free.
As I see it, ultimately, that's the major strength of Linux -- it gives cost-conscious users an easy and cheap way to stay current. In any case, that's the main reason I switched our household to Linux. (we have about 5 or 6 active or semi-active computers -- WinXP's copy protection drove the final nail in the coffin)
...(like the subject says)...
So, yes, you can link your proprietary code with their LGPL client library, and ship the combination without encumbrance. However, if you also ship MySQL in the same "bundle", then everything is subject to GPL. (whatever "bundle" means exactly -- I'd assume it is interpreted broadly, so it actually means something at all -- that is, you can't bypass the clause through petty tricks, like shipping MySQL on a different CDROM)
The same reasoning could, I would think, be applied to programs which only run on the Linux kernel. However, as you say: So it appears the Linux kernel license is not pure GPL -- it explicitly allows some linkage. That would put it somewhere in-between LGPL and GPL (I've never studied the Linux license -- always assumed it was plain-old GPL). Does the Linux kernel license explicitly allow non-GPL programs which only run under the linux kernel? Does it need to? It would seem the MySQL folks would say that it does need to explicitly allow this.
So who's right?
That's where case law comes in. But there is no case law that I'm aware of. So nobody can say definitively who's right. And, ultimately, different countries will establish different case law over the years. So it will be a messy answer at best.
But, of course, as is always the case with legal matters, nobody really knows the answer until it has been tested in court. And even then, we can only know the answer _somewhat_ better than we did previously. The more the GPL is tested, the more exactly we know the answer. I don't believe the GPL has ever been tested. Which would explain why there's so much doubt about its legal (vs intended) meaning.
I don't really understand your question, I don't think -- no, I don't want the freedom to be bound. I just want the freedom to make money!
But it's not really about what I want (since I don't have any current plans to sell products with embedded DB's) -- I'm speculating on what others may find relatively attractive about PostgreSQL vs the (GPL'd) SAP database. As a general matter, BSD is probably more attractive (from a business perspective) than GPL. At least in terms of licensing restrictions (i.e. all other things being equal, which they never are...)
It's a tricky question. Yes, you can embed any GPL code you want, as long as you make your code GPL. But what if you want to _sell_ a program? Then GPL is a liability -- probably makes it impossible. You have to sell support, or something like that. Unless you have patent protection, in which case you can give away the source (GPL), but sell licenses to use the patent.
In the case of Tivo, they're selling hardware, not software, so it works out OK. Also, their business model is protected by patents (perhaps).
All depends on the application.