However, it would propably help if they actually wanted to innovate. I remember my fealings of disgust on seeing their ripoff of speedisk (sp?) and discdoctor (sp?) (both Nortons/Symantics) in DOS 6.0. That was when I first became aware of their `innovation'. Before that, I actually thought they were innovative (being totally naive in these things at that time). It took getting a taste of real os power (Linux) to make me realise just how lousy windows was/is (dos is actually ok as something to launch real things like DJGPP). Hmm, I don't think I ever thanked DJ Delorie, I'll have to do something about that.
I'm not certain, but I seem to remember hearing that all the standard tools ('cept the compiler tool chain) are non-gnu. I believe BSD has its own equivelents to fileutils, textutils, shellutils etc. I also suspect they don't use bash, but I don't know.
Althoug I prefer Linux, I've always liked the FreeBSD devil. Tux is fine and I find him soothing to look at (and my kids seem to love penguins from some strange reason...I just don't know why:), but I find the little devil in sneakers very adorable. Hopefully the two will become good friends:)
I ordered two cds from cheapbytes yesterday and I'm expecting them sometime in the next 10 days (I'm in New Zealand). I just did the calulations, and assuming 640MB per cd and 10 day delivery, that gives me just under 12.5Kbps. Not particularly fast, but it beats tying up my one phoneline for 2 odd days (and I imagine my isp would get miffed at 1.3+G of traffic). That's only two cds. Can you imagine a plane load of them?
Thanks. That's what I'd gathered from various messages here and there (mostly here on slashdot over the last 1.5 years), and actually looking at a FreeBSD release note.
Also, what's there to be negative about? FreeBSD and Linux are just different (esp in licensing which is, admittedly, a religious topic). I've run into a few problems getting things to port (ssleay-ified telnet), but nothing to slam BSD over. I don't dislike FreeBSD, I just don't use it. Choice is good, choice works:).
judging by a quick glance at the release notes, this seems to be on par with a new release of Red Hat or Debian, etc. FreeBSD 3.3 seems to be the whole distribution, not just the FreeBSD kernel (is it even referred to as that?).
Good work, guys, but I'm not actually interested in installing FreeBSD. The three year gap between my attempt at FreeBSD (late 94 or early 95) and Linux (late 97) is the main factor in this. hw support during my two attempts was my main issue, though I'm sure FreeBSD now supports the Matsushita cdrom interface now, it didn't in 94/95 and Linux did in 97 (I was still using dos/windows with djgpp in between). I almost gave Linux a go back in 94, but I wasn't sure what it was:) but I recognised FreeBSD's pedigree from the Dr Dobbs articles on porting BSD to the 386. I've still got that CD collecting dust.
None of this is meant as tinder. Good luck to the FreeBSD guys from a guy in the Linux camp.
How does requiring source distribution even for internal only use protect your privacy?
This is how I imagined not requiring source distribution for internal use could be used to circumvent the intent of the GPL.
I agree with you about circumventing the intent of the GPL (which appears to not be the case, but I'll have to reread the GPL, I haven't for a while), but what has this got to do with privacy? That's the only point of your argument that has me confused, The rest I more or less agree with you.
My preference to the GPL over most of the others is based on if it's worth doing, it's worth doing properly. Now, you may not agree with this, but I feel that the contradictory nature of the two QPL licences is not a proper solution, whereas the GPL is at least consistent (I'll have to verify that for myself, but that's my impression). I feel the need for the compromise of the LGPL to be an unfortunatly necessity caused by the need to work with others (which is a good thing). Yes, this `taints the purity' of the GPL (thus hurting my argument:), but if things were perfect, the GPL wouldn't be needed in the first place. It's a compomise itself bwtween idealistic freedom (an admirable goal, IMHO) and protection from vultures
BTW, if you want to go to email, the address in these postings is valid.
By secret, do you mean from users within the company, or the rest of the world? Either way I don't see your point, especially your bit about privacy. How does requiring source distribution even for internal only use protect your privacy? Doesn't it violate your privacy? Or is it that you're not explaining enough or you're using the wrong word and you mean security? I can see some rogue grabing some program off the net, patching it with some malicious code and distributing the binaries within the company being a problem (is this what you're getting at?). No license you could possibly dream up can protect you from this and so your `loophole' argument is still a null issue because no license can protect you in this instance, only brains.
Yeah, I can, but you telling me on slashdot kinda let the cat out of the bag, hmm?:)
OK, this is probably where religion comes in, but what is the problem with the GPL's `loophole'? If I make some local modifications to someone else's code, why should I have to give those modifications away? Sure, it's a nice thing to do and does benifit others, but I shouldn't have to. Anyway, how the hell is (eg) TrollTech (sp?) or the FSF going to know if I made any local modifications? What? I just sent an e-mail to them saying so? If I did that, the patch would (hopefully, I've been known to forget:) be attached to that very same e-mail, or, failing that, I would ask if they are interested in said patch. Your loophole is a null issue.
BTW, a and b would have been good to read if they were there, but still, thanks for the info.
Re:There may be a reason people call you names
on
KDevelop review
·
· Score: 1
I believe the original poster meant inhouse use, not redistributed code. For inhouse use, you can do whatever you want with GPLed code, but as soon as it goes out-of-house, the GPL kicks in. I've never looked at the QPL, but from what's been implied here and there (and from my readings of other licenses), even inhouse use of Qt requires payment (correct me if I'm wrong).
are never the user's fault. No application should ever segfault nomatter what the user does. A segfault is the programmer's fault as he obviously overlooked some special case in the code and it was not handled gracefully.
This attitude of program crashes being the fault of the user is one of the saddest legacies of the Microsoft Dynasty. Illegal input should not crash a program, it should only generate an error message and the program should continue on in a sensible fassion (even if it's exit(1)).
That will hurt. Trouble is, I imagine there are plenty of artists that are willing to sell that part of their soul (along with all the other bits in previous contracts) just to get published.
Yeah, that was the first time I was ever happy to click on the `agree' button. Man, that felt good. Unfortunatly, I'd just ordered two CNet cards (they were less than half the price @ $37 + GST (12.5%)), so I won't be buying from 3com soon (for myself, anyway), but if any cards here at work go belly up, I know which cards I'll recommend (even though all the PC's here are 9x/NT (but I've got a sparc running Linux:)).
You are almost right. What you (and everbody else in the above list) are forgetting is Newton's 2nd(?) law: for every action, there is an equal and opposite reaction. Yes, the absolute accelleration of an object in a gravity field is independent of its mass, but its accelleration relative to the body creating the gravity field is not due to the object accellerating the body towards it at the same time.
The relative accelleration (ie the rate the object appears to be falling, or the rate of approach) is givven by a=G(m1+m2)/(d*d). Here's the proof:
NOTE: The directions of the two absolute accellerations are opposite to each other (unit(a1)=-unit(a2)) so as relative accellaration is a1-a2 (or a2-a1), the magnitude of the relative accelleration is mag(a1)+mag(a2) and we couldn't care less about the direction.
In conclution, the mass of an object does affect its rate of fall, but when we're talking about the moon, a hammer and a feather, the difference between the hammer and feather is insignificant and not easily measurable.
NOTE 2: I just realised that if you drop the hammer and the feather at the same time, they probably (ie I'm too lazy to prove it) fall at the same rate because they're both pulling on the moon (ie acting as a single body), but if you drop them separatly, there will be a slight difference.
That flickering you're seeing is not the flickering of the light or the display; it's the interaction of the two. The human eye can detect flickering at a maximuim of somewhere between 12 and 24 Hz (can't remember which one, I think it's 12) due to persistence of vision (this is how animation/movies work; film updates at around 24fps from memory). If the refresh rate of the display is close enough to the flicker rate of the lights, you will then get flicker due to the beat frequency which is abs(f1 - f2). I believe harmonics can come into this as well (they do, but it's the exetent to which they affect things that I reffering to). Solution: either adjust your refresh rate or turn off the lights. BTW, this is explained in the display timings faq in XFree86 (written by ESR). Sorry, no link.
From what I've gathered by following the alsa-dev mailing list, they've gotten latencies down to arround 2ms max using Ingo's patch (sched? timer? can't remember the details of what it's for) and some optimisations in alsa itself. Most of their work seems to be currently concentrated on midi timers, but I beleive they were also discussing sound samples/effects as well. Alsa and Linux are gaining (soft?) real time capabilities and are slowly making RTLinux needed only for true hard RT applications and BeOS less relevant (not meant as a troll, but when Linux and BeOS get similar multimedia performance, BeOS loses it's standing as `the multimedia os' and becomes required only by BeOS enthusiasts (more power to them, viva la diference)).
With the case on, my CPU runs a full 15C hotter than with it off..
Hehe, that's believable. Until last night, I could overclock my dual celery system only if I had the case off (only got through two to four kernel compiles). Last night I installed two case fans (it previously only had the power supply fan in addition to the cpu fans), one in the front and one in the back (my case came with two fan locations, woohoo), and it happily got through 11 compiles, top -d1, procinfo -d1, and ping -f (to another machine). Now, I wonder how well it will work when summer hits (I'm in the southern hemisphere).
Anyway, to paraphrase Gecko: fans are good, fans work. Or better yet: airflow is good, airflow works.
Slashdot Mirror
Hmmm, you may be right. It's been a looong time (6 years). However, I still felt miffed, and the rest of my comment still stands.
However, it would propably help if they actually wanted to innovate. I remember my fealings of disgust on seeing their ripoff of speedisk (sp?) and discdoctor (sp?) (both Nortons/Symantics) in DOS 6.0. That was when I first became aware of their `innovation'. Before that, I actually thought they were innovative (being totally naive in these things at that time). It took getting a taste of real os power (Linux) to make me realise just how lousy windows was/is (dos is actually ok as something to launch real things like DJGPP). Hmm, I don't think I ever thanked DJ Delorie, I'll have to do something about that.
Nah, they probably assumed that if you don't know slashdot's url, you don't know nuffin, and it ain't your favorit:)
under favorite platform they had abacus. 'Course, I had to vote for that, spefifying Linacus:)
I'm not certain, but I seem to remember hearing that all the standard tools ('cept the compiler tool chain) are non-gnu. I believe BSD has its own equivelents to fileutils, textutils, shellutils etc. I also suspect they don't use bash, but I don't know.
Are you being sarcastic or antangonistic?
Althoug I prefer Linux, I've always liked the FreeBSD devil. Tux is fine and I find him soothing to look at (and my kids seem to love penguins from some strange reason...I just don't know why:), but I find the little devil in sneakers very adorable. Hopefully the two will become good friends:)
I ordered two cds from cheapbytes yesterday and I'm expecting them sometime in the next 10 days (I'm in New Zealand). I just did the calulations, and assuming 640MB per cd and 10 day delivery, that gives me just under 12.5Kbps. Not particularly fast, but it beats tying up my one phoneline for 2 odd days (and I imagine my isp would get miffed at 1.3+G of traffic). That's only two cds. Can you imagine a plane load of them?
Also, what's there to be negative about? FreeBSD and Linux are just different (esp in licensing which is, admittedly, a religious topic). I've run into a few problems getting things to port (ssleay-ified telnet), but nothing to slam BSD over. I don't dislike FreeBSD, I just don't use it. Choice is good, choice works:).
Good work, guys, but I'm not actually interested in installing FreeBSD. The three year gap between my attempt at FreeBSD (late 94 or early 95) and Linux (late 97) is the main factor in this. hw support during my two attempts was my main issue, though I'm sure FreeBSD now supports the Matsushita cdrom interface now, it didn't in 94/95 and Linux did in 97 (I was still using dos/windows with djgpp in between). I almost gave Linux a go back in 94, but I wasn't sure what it was:) but I recognised FreeBSD's pedigree from the Dr Dobbs articles on porting BSD to the 386. I've still got that CD collecting dust.
None of this is meant as tinder. Good luck to the FreeBSD guys from a guy in the Linux camp.
I agree with you about circumventing the intent of the GPL (which appears to not be the case, but I'll have to reread the GPL, I haven't for a while), but what has this got to do with privacy? That's the only point of your argument that has me confused, The rest I more or less agree with you.
My preference to the GPL over most of the others is based on if it's worth doing, it's worth doing properly. Now, you may not agree with this, but I feel that the contradictory nature of the two QPL licences is not a proper solution, whereas the GPL is at least consistent (I'll have to verify that for myself, but that's my impression). I feel the need for the compromise of the LGPL to be an unfortunatly necessity caused by the need to work with others (which is a good thing). Yes, this `taints the purity' of the GPL (thus hurting my argument:), but if things were perfect, the GPL wouldn't be needed in the first place. It's a compomise itself bwtween idealistic freedom (an admirable goal, IMHO) and protection from vultures
BTW, if you want to go to email, the address in these postings is valid.
By secret, do you mean from users within the company, or the rest of the world? Either way I don't see your point, especially your bit about privacy. How does requiring source distribution even for internal only use protect your privacy? Doesn't it violate your privacy? Or is it that you're not explaining enough or you're using the wrong word and you mean security? I can see some rogue grabing some program off the net, patching it with some malicious code and distributing the binaries within the company being a problem (is this what you're getting at?). No license you could possibly dream up can protect you from this and so your `loophole' argument is still a null issue because no license can protect you in this instance, only brains.
OK, this is probably where religion comes in, but what is the problem with the GPL's `loophole'? If I make some local modifications to someone else's code, why should I have to give those modifications away? Sure, it's a nice thing to do and does benifit others, but I shouldn't have to. Anyway, how the hell is (eg) TrollTech (sp?) or the FSF going to know if I made any local modifications? What? I just sent an e-mail to them saying so? If I did that, the patch would (hopefully, I've been known to forget:) be attached to that very same e-mail, or, failing that, I would ask if they are interested in said patch. Your loophole is a null issue.
BTW, a and b would have been good to read if they were there, but still, thanks for the info.
I believe the original poster meant inhouse use, not redistributed code. For inhouse use, you can do whatever you want with GPLed code, but as soon as it goes out-of-house, the GPL kicks in. I've never looked at the QPL, but from what's been implied here and there (and from my readings of other licenses), even inhouse use of Qt requires payment (correct me if I'm wrong).
This attitude of program crashes being the fault of the user is one of the saddest legacies of the Microsoft Dynasty. Illegal input should not crash a program, it should only generate an error message and the program should continue on in a sensible fassion (even if it's exit(1)).
That will hurt. Trouble is, I imagine there are plenty of artists that are willing to sell that part of their soul (along with all the other bits in previous contracts) just to get published.
Yeah, that was the first time I was ever happy to click on the `agree' button. Man, that felt good. Unfortunatly, I'd just ordered two CNet cards (they were less than half the price @ $37 + GST (12.5%)), so I won't be buying from 3com soon (for myself, anyway), but if any cards here at work go belly up, I know which cards I'll recommend (even though all the PC's here are 9x/NT (but I've got a sparc running Linux:)).
The relative accelleration (ie the rate the object appears to be falling, or the rate of approach) is givven by a=G(m1+m2)/(d*d). Here's the proof:
f1=G*m1*m2/(d*d) -> a1=f1/m1=G*m2/(d*d)
f2=G*m1*m2/(d*d) -> a2=f2/m2=G*m1/(d*d)
a=a1+a2 = G*m2/(d*d) + G*m1/(d*d) = G*(m1+m2)/(d*d)
NOTE: The directions of the two absolute accellerations are opposite to each other (unit(a1)=-unit(a2)) so as relative accellaration is a1-a2 (or a2-a1), the magnitude of the relative accelleration is mag(a1)+mag(a2) and we couldn't care less about the direction.
In conclution, the mass of an object does affect its rate of fall, but when we're talking about the moon, a hammer and a feather, the difference between the hammer and feather is insignificant and not easily measurable.
NOTE 2: I just realised that if you drop the hammer and the feather at the same time, they probably (ie I'm too lazy to prove it) fall at the same rate because they're both pulling on the moon (ie acting as a single body), but if you drop them separatly, there will be a slight difference.
A slow diode would make the light look smoother, not rougher (ie make it seem like the phosphors last longer).
That flickering you're seeing is not the flickering of the light or the display; it's the interaction of the two. The human eye can detect flickering at a maximuim of somewhere between 12 and 24 Hz (can't remember which one, I think it's 12) due to persistence of vision (this is how animation/movies work; film updates at around 24fps from memory). If the refresh rate of the display is close enough to the flicker rate of the lights, you will then get flicker due to the beat frequency which is abs(f1 - f2). I believe harmonics can come into this as well (they do, but it's the exetent to which they affect things that I reffering to). Solution: either adjust your refresh rate or turn off the lights. BTW, this is explained in the display timings faq in XFree86 (written by ESR). Sorry, no link.
From what I've gathered by following the alsa-dev mailing list, they've gotten latencies down to arround 2ms max using Ingo's patch (sched? timer? can't remember the details of what it's for) and some optimisations in alsa itself. Most of their work seems to be currently concentrated on midi timers, but I beleive they were also discussing sound samples/effects as well. Alsa and Linux are gaining (soft?) real time capabilities and are slowly making RTLinux needed only for true hard RT applications and BeOS less relevant (not meant as a troll, but when Linux and BeOS get similar multimedia performance, BeOS loses it's standing as `the multimedia os' and becomes required only by BeOS enthusiasts (more power to them, viva la diference)).
Hehe, that's believable. Until last night, I could overclock my dual celery system only if I had the case off (only got through two to four kernel compiles). Last night I installed two case fans (it previously only had the power supply fan in addition to the cpu fans), one in the front and one in the back (my case came with two fan locations, woohoo), and it happily got through 11 compiles, top -d1, procinfo -d1, and ping -f (to another machine). Now, I wonder how well it will work when summer hits (I'm in the southern hemisphere).
Anyway, to paraphrase Gecko: fans are good, fans work. Or better yet: airflow is good, airflow works.
Actually, thanks. Just got through the first few of `Satan' and it was a laugh. Highly recommended.
Aye, though SMP could be interesting, or even a Beowulf cluster.
It's from `Saving Private Ryan', when pvt Ryan is telling [Hanks] about his brothers.