I have exactly zero programs installed which use qt. I have programs installed that I use daily which use gtk+. So I have zero interest in installing and running a desktop that uses a completely different toolkit from any of my software, and I have zero interest in retraining myself to use all the qt-based equivalents that may or may not exist. If I'm going to switch (and I have) it certainly wouldn't be to anything that isn't either A) gtk+ based (e.g. xfce) or B) tiny (e.g. fvwm). KDE's not even on my radar, and from what I've seen of it when I have looked at it, I'm very happy with that fact. I hear 4 is an improvement, but with 3, the developers seemed unable to distinguish configuration from option. I don't want to have to pick through 500 options every time I click the mouse. That's why I configure my fvwm to work the way I want.
MM-DD may be common in China, but I doubt that MM-DD-YY is. And I especially doubt that MDYY is. Americans (who do use MM-DD-YY) would probably have trouble parsing 6489 as a date--I seriously doubt anyone in China would leap to that parsing.
Everything I know about Mantis Shrimps comes from The Science of Discworld (a book which should really be named, The Science of Roundworld, since it's about how the inhabitants of Discworld might view our world), by Terry Pratchett and two scientists, one of whom actually owned one of these critters. They're extremely smart (relatively speaking). He used to set it puzzles it had to solve to get food. After a while, it started ignoring food that didn't involve solving a puzzle, apparently because it was too boring.
Yes, but the amount of effort put in to make sure that your arbitrary selection out of those 35k works is pretty amazing. Want to use lighttpd or aolserver instead of apache? No problem. Firebird instead of pgsql or mysql? No problem. A BSD kernel instead of Linux? A little more work, but still basically no problem. Rexx instead of Perl? Hey, it's your system, and we're not here to cast aspersions on your sanity!:)
That's not why it beat Rexx, no, though that's certainly a reason why both Perl and Rexx became popular. Of course, Rexx was more of an IBM thing, but it had its advocates even on Unix. Ultimately, Unix guys liked the more Unix-y flavor of Perl, which was due in no small part to its syntactic resemblances to C, and Rexx-on-Unix became more of a curiousity than anything else. I suspect the last place Rexx saw much use was on the AS/400, although it's still available in Debian for the true fanatics.:)
Me, I had Perl and gcc and bash running on OS/2 back in those days. Rexx was supposed to be the glue language for OS/2, but I already knew C, and found Perl much more accessible.
Considering that a full Debian system (binaries for one platform) comes on eight DVDs, I think this project, whatever it might be, has a long way to go before it can really claim to be the "most far-reaching open source project." More mainstream, perhaps, but far less ambitious.
My post to which you've replied stated that, with the current rules and policies around Win8, it is highly unlikely that there is an anti-trust angle there.
Where? Your original post to which I replied said that they don't have a monopoly on ARM, so there can't be any anti-trust issues. I pointed out that that's not true. We've explored exactly what I meant, and you no longer seem to be supporting that position, and I don' t think we were ever in much disagreement about anything else.
(Or did you mean a later post to which I've replied? In which case, yeah, we've covered that now.):)
That's fine, but "they aren't" is a whole different argument from "they can't", which is what the original post I replied to was trying to claim. (Also, "not that I know of" is not exactly the strongest argument when it comes to a company with a history like MS's.)
C took off because it allowed imperative programming more easily (and portably) than assembler
Also because its use in the development of Unix meant that it had a huge (by the standards of the time) body of existing code and libraries by the time it was sprung upon an unsuspecting world. The very fact that you could use this portable, (moderately) high-level language for writing a complete OS without abandoning performance was a revelation. And the fact that Unix began invading universities shortly thereafter helped as well.
Since the rise of C, some loose compatibility with C has been a major factor too. When it came to powerful scripting languages, we had Rexx and Perl--and which one had a more C-like syntax? That's right, the one that succeeded, Perl. And Java is notable for it's C(++)-ness too.
It's rarely one or two simple factors, but usually a whole mess of things.
(As for functional programming, I think that's pretty much been a non-issue the whole time.)
A language succeeds or fails because the company building the language and/or the tools put on a dog and pony show for your company executives.
If that were true, PL/1 would have been a huge success. It had the backing of IBM, which was at the time, the computer company, and was heavily promoted by them, but it was rejected by the market as being too complex and hard to understand. (Ironically, by the standards of today's languages, it was remarkably straightforward, clean and elegant, and if anything, too simple.)
Um, that's why I said "if it can be shown that they are tied."
Win8 on ARM doesn't run existing Windows applications, and it doesn't run on any existing Windows PC.
But does it have hooks that allow it to communicate better with Windows? Or with MS's office suite? Private protocols? Aren't they already trying to prevent other phones from talking to Exchange? It's that sort of thing that could get them into Antitrust trouble. If they start saying, "if you run Windows, this is the phone you need," that's certainly at least flirting with leveraging their monopoly, especially if they try to make it true.
You're partly right, but remember that they also didn't have a monopoly on browsers at the time. Yet it was browsers they got sued over. What got them into trouble was leveraging their existing monopoly in Intel-compatible PCs to limit the market in browsers. And they could easily get into similar trouble with ARM devices, if it can be shown that they are tied to the PC OS in any way.
As for Apple, the analogy is inapt because Apple hasn't (yet) been judged to have any relevant monopolies.
Note, I'm not saying Microsoft is going to get in trouble for any of this; I'm simply saying that your argument for why they can't is flawed.
That's funny--I don't hear that sort of screaming about OpenBSD, which is miles ahead of Apple on making a solid, secure system. Maybe it's not the greater security and stability that pisses people off. And it's not the reduced functionality, because OpenBSD has that too. Maybe it's the reduced ability to tinker and fiddle, and the fact that you don't actually own what you bought, and the fact that Apple really are arrogant and paternalistic.
(Actually, I think OSX is a perfectly adequate system. It's Apple's mobile devices that I avoid like the plague.)
So you won't be actually distributing the GPL libraries at all.
What you're overlooking is that the law takes intent into account, and if there's only one way to use your code--by installing the GPL libraries--the law will see your lack of distribution as an obvious ruse. Don't just take my word for it. NeXT tried it with their original ObjC backend for GCC, and ended up just giving the whole thing to the FSF.
Now if there's more than one implementation, then nobody can say your work is an obvious derivative of just one. But if there's only one implementation, then they can.
Of course, none of this applies to the Google case, because Google wasn't trying to link with Oracle's code at all. Your analogy isn't even close.
Which, since we've been unable to track down the actual results, may simply indicate that what he did is much less impressive than some news reporters are making it sound.
My sentences were not at odds. You were leaping to an incorrect assumption about my position, which is that math isn't an invention! It's a discovery of a law of nature. Therefore math patents are bad patents. That's why I explicitly mentioned "real inventions".
Obviousness is a separate issue, though of course, those patents are not real inventions either. But I wasn't limiting my argument to just one type of not-real-invention. I want to get rid of patents on everything that's not a real invention.
Math shouldn't be patentable because it's not something physical. Software, no matter how complex, is something you can, at least in theory, do in your head. It's not a physical process--it's math. It's a practical application of mathematics, based on the mathematical ideal of the universal Turing machine. It's a law of nature. And by the precedents set in In Re Bilski and Mayo v Prometheus (not to mention common sense), it shouldn't be patentable.
If you really thought I was saying that all math is obvious, you should learn to read more carefully, or think things through more, because that (imaginary) position really makes no sense. Of course, this is slashdot, where some people seem to think some silly things, so I can't blame you for considering the possibility I meant something that silly. But it really would have been more polite to ask if that's what I meant, instead of assuming I was proposing something so preposterous.
The patent has still been made public, and will enter the public domain after the patent expires. So there's no contradiction with the "original intent". It may not be promoting the Progress at the rate you would like, but it's still happening.
Part of the problem is that the speed of industry has increased, so the length of a patent should really be decreasing to match. Fourteen years used to be a fairly short length of time as far as product development was concerned; now it's an eternity. But instead of decreasing, the life of a patent has gone from fourteen years to twenty.
But the real problem remains bad patents. If only real inventions were patented, we wouldn't see so many trolls grabbing patents on basic (and obvious) technology and preventing others from using it. Patents on math, in particular, have to go.
You must not know many people, then. Since I started using test-driven development, I find I rarely turn to a debugger any more. Not that I ever used one much in the first place. In the early days, I found I was most likely to need a debugger when I started getting sloppy, so I tried to stop being sloppy, with reasonable success, and my use of a debugger dropped dramatically.
But it's partly a matter of style. Some people like to step through their code to make sure it's all doing what they expect. I find that tedious, so I like to write the code so that it tells me if it's not doing what I expect, so I don't have to bother stepping through it. I've also been programming long enough to be fairly confident in my understanding of my own code. (Other people's code is a different story, and my main use of a debugger these days is to step through other people's code.) Horses for courses.
Add in another $100 or so for a Windows license, at least in my case. And then, if you're going to connect it to the internet, you're probably going to need a bunch of security software as well. (Certainly I would, as I have no idea how to secure Windows. I haven't used an MS product since '97.)
Slashdot Mirror
Emacs more closely resembles a windowing system than an OS, and you can run vi just fine under it: M-X term RET RET vi foo RET
I have exactly zero programs installed which use qt. I have programs installed that I use daily which use gtk+. So I have zero interest in installing and running a desktop that uses a completely different toolkit from any of my software, and I have zero interest in retraining myself to use all the qt-based equivalents that may or may not exist. If I'm going to switch (and I have) it certainly wouldn't be to anything that isn't either A) gtk+ based (e.g. xfce) or B) tiny (e.g. fvwm). KDE's not even on my radar, and from what I've seen of it when I have looked at it, I'm very happy with that fact. I hear 4 is an improvement, but with 3, the developers seemed unable to distinguish configuration from option. I don't want to have to pick through 500 options every time I click the mouse. That's why I configure my fvwm to work the way I want.
MM-DD may be common in China, but I doubt that MM-DD-YY is. And I especially doubt that MDYY is. Americans (who do use MM-DD-YY) would probably have trouble parsing 6489 as a date--I seriously doubt anyone in China would leap to that parsing.
So, in other words, a way of encoding the date that only Americans would recognize.
Everything I know about Mantis Shrimps comes from The Science of Discworld (a book which should really be named, The Science of Roundworld, since it's about how the inhabitants of Discworld might view our world), by Terry Pratchett and two scientists, one of whom actually owned one of these critters. They're extremely smart (relatively speaking). He used to set it puzzles it had to solve to get food. After a while, it started ignoring food that didn't involve solving a puzzle, apparently because it was too boring.
That's right--forgot about that one. Yeah, Rexx had quite a following for a while there.
Yes, but the amount of effort put in to make sure that your arbitrary selection out of those 35k works is pretty amazing. Want to use lighttpd or aolserver instead of apache? No problem. Firebird instead of pgsql or mysql? No problem. A BSD kernel instead of Linux? A little more work, but still basically no problem. Rexx instead of Perl? Hey, it's your system, and we're not here to cast aspersions on your sanity! :)
I think they are going to find it tough to keep Enterprise-level SLAs using Centos vice Red Hat.
They're already running on a Windows hypervisor. It's not like switching from RHEL to CentOS is going to affect their SLAs more than that will! :)
That's not why it beat Rexx, no, though that's certainly a reason why both Perl and Rexx became popular. Of course, Rexx was more of an IBM thing, but it had its advocates even on Unix. Ultimately, Unix guys liked the more Unix-y flavor of Perl, which was due in no small part to its syntactic resemblances to C, and Rexx-on-Unix became more of a curiousity than anything else. I suspect the last place Rexx saw much use was on the AS/400, although it's still available in Debian for the true fanatics. :)
Me, I had Perl and gcc and bash running on OS/2 back in those days. Rexx was supposed to be the glue language for OS/2, but I already knew C, and found Perl much more accessible.
Considering that a full Debian system (binaries for one platform) comes on eight DVDs, I think this project, whatever it might be, has a long way to go before it can really claim to be the "most far-reaching open source project." More mainstream, perhaps, but far less ambitious.
My post to which you've replied stated that, with the current rules and policies around Win8, it is highly unlikely that there is an anti-trust angle there.
Where? Your original post to which I replied said that they don't have a monopoly on ARM, so there can't be any anti-trust issues. I pointed out that that's not true. We've explored exactly what I meant, and you no longer seem to be supporting that position, and I don' t think we were ever in much disagreement about anything else.
(Or did you mean a later post to which I've replied? In which case, yeah, we've covered that now.) :)
That's fine, but "they aren't" is a whole different argument from "they can't", which is what the original post I replied to was trying to claim. (Also, "not that I know of" is not exactly the strongest argument when it comes to a company with a history like MS's.)
Can you give an example of such a situation? I can't think of one.
The ability to talk to Exchange. Or import/export from Word properly.
C took off because it allowed imperative programming more easily (and portably) than assembler
Also because its use in the development of Unix meant that it had a huge (by the standards of the time) body of existing code and libraries by the time it was sprung upon an unsuspecting world. The very fact that you could use this portable, (moderately) high-level language for writing a complete OS without abandoning performance was a revelation. And the fact that Unix began invading universities shortly thereafter helped as well.
Since the rise of C, some loose compatibility with C has been a major factor too. When it came to powerful scripting languages, we had Rexx and Perl--and which one had a more C-like syntax? That's right, the one that succeeded, Perl. And Java is notable for it's C(++)-ness too.
It's rarely one or two simple factors, but usually a whole mess of things.
(As for functional programming, I think that's pretty much been a non-issue the whole time.)
A language succeeds or fails because the company building the language and/or the tools put on a dog and pony show for your company executives.
If that were true, PL/1 would have been a huge success. It had the backing of IBM, which was at the time, the computer company, and was heavily promoted by them, but it was rejected by the market as being too complex and hard to understand. (Ironically, by the standards of today's languages, it was remarkably straightforward, clean and elegant, and if anything, too simple.)
In which way are they tied, though?
Um, that's why I said "if it can be shown that they are tied."
Win8 on ARM doesn't run existing Windows applications, and it doesn't run on any existing Windows PC.
But does it have hooks that allow it to communicate better with Windows? Or with MS's office suite? Private protocols? Aren't they already trying to prevent other phones from talking to Exchange? It's that sort of thing that could get them into Antitrust trouble. If they start saying, "if you run Windows, this is the phone you need," that's certainly at least flirting with leveraging their monopoly, especially if they try to make it true.
You're partly right, but remember that they also didn't have a monopoly on browsers at the time. Yet it was browsers they got sued over. What got them into trouble was leveraging their existing monopoly in Intel-compatible PCs to limit the market in browsers. And they could easily get into similar trouble with ARM devices, if it can be shown that they are tied to the PC OS in any way.
As for Apple, the analogy is inapt because Apple hasn't (yet) been judged to have any relevant monopolies.
Note, I'm not saying Microsoft is going to get in trouble for any of this; I'm simply saying that your argument for why they can't is flawed.
Note that this song was nominated for a Hugo in 2011. Rachel even came and performed it live at the 2011 Worldcon.
That's funny--I don't hear that sort of screaming about OpenBSD, which is miles ahead of Apple on making a solid, secure system. Maybe it's not the greater security and stability that pisses people off. And it's not the reduced functionality, because OpenBSD has that too. Maybe it's the reduced ability to tinker and fiddle, and the fact that you don't actually own what you bought, and the fact that Apple really are arrogant and paternalistic.
(Actually, I think OSX is a perfectly adequate system. It's Apple's mobile devices that I avoid like the plague.)
So you won't be actually distributing the GPL libraries at all.
What you're overlooking is that the law takes intent into account, and if there's only one way to use your code--by installing the GPL libraries--the law will see your lack of distribution as an obvious ruse. Don't just take my word for it. NeXT tried it with their original ObjC backend for GCC, and ended up just giving the whole thing to the FSF.
Now if there's more than one implementation, then nobody can say your work is an obvious derivative of just one. But if there's only one implementation, then they can.
Of course, none of this applies to the Google case, because Google wasn't trying to link with Oracle's code at all. Your analogy isn't even close.
Which, since we've been unable to track down the actual results, may simply indicate that what he did is much less impressive than some news reporters are making it sound.
My sentences were not at odds. You were leaping to an incorrect assumption about my position, which is that math isn't an invention! It's a discovery of a law of nature. Therefore math patents are bad patents. That's why I explicitly mentioned "real inventions".
Obviousness is a separate issue, though of course, those patents are not real inventions either. But I wasn't limiting my argument to just one type of not-real-invention. I want to get rid of patents on everything that's not a real invention.
Math shouldn't be patentable because it's not something physical. Software, no matter how complex, is something you can, at least in theory, do in your head. It's not a physical process--it's math. It's a practical application of mathematics, based on the mathematical ideal of the universal Turing machine. It's a law of nature. And by the precedents set in In Re Bilski and Mayo v Prometheus (not to mention common sense), it shouldn't be patentable.
If you really thought I was saying that all math is obvious, you should learn to read more carefully, or think things through more, because that (imaginary) position really makes no sense. Of course, this is slashdot, where some people seem to think some silly things, so I can't blame you for considering the possibility I meant something that silly. But it really would have been more polite to ask if that's what I meant, instead of assuming I was proposing something so preposterous.
The patent has still been made public, and will enter the public domain after the patent expires. So there's no contradiction with the "original intent". It may not be promoting the Progress at the rate you would like, but it's still happening.
Part of the problem is that the speed of industry has increased, so the length of a patent should really be decreasing to match. Fourteen years used to be a fairly short length of time as far as product development was concerned; now it's an eternity. But instead of decreasing, the life of a patent has gone from fourteen years to twenty.
But the real problem remains bad patents. If only real inventions were patented, we wouldn't see so many trolls grabbing patents on basic (and obvious) technology and preventing others from using it. Patents on math, in particular, have to go.
You must not know many people, then. Since I started using test-driven development, I find I rarely turn to a debugger any more. Not that I ever used one much in the first place. In the early days, I found I was most likely to need a debugger when I started getting sloppy, so I tried to stop being sloppy, with reasonable success, and my use of a debugger dropped dramatically.
But it's partly a matter of style. Some people like to step through their code to make sure it's all doing what they expect. I find that tedious, so I like to write the code so that it tells me if it's not doing what I expect, so I don't have to bother stepping through it. I've also been programming long enough to be fairly confident in my understanding of my own code. (Other people's code is a different story, and my main use of a debugger these days is to step through other people's code.) Horses for courses.
Add in another $100 or so for a Windows license, at least in my case. And then, if you're going to connect it to the internet, you're probably going to need a bunch of security software as well. (Certainly I would, as I have no idea how to secure Windows. I haven't used an MS product since '97.)