Python is way more of a functional language than Ruby, but Ruby's brilliant use of modules and its object/type system makes it pretty functional nonetheless, in that you can reuse functions like in a functional language but you call them and can override them like in an OO language.
However, the very OO-centric approach falls flat on its face sometimes. Functional really does fit the bill better, and there, Python's more balanced approach is nice. For instance:
genome11.mateWith(genome2) # Ruby/Java style vs mate(genome1, genome2) # Python style
In the first case, you're implying genome1 has the correct implementation, which could have been overriden. In the second case, you're implying mating is not a function of either genome, but a function of the pair itself, which is what most accurately represents the real relationship.
It's a pretty big difference to how your code ends up being structured. I personally prefer Python's approach.
PS: Yes, a "real" OO architecture would have a Mater object with a mate(genome1, genome2) method. This just makes it a much more verbose and clunky version of the functional style, where the mating function *is* the object.
Once again, "if you have the technical means". It's exhausting repeating the same thing over and over while you're arguing with something I didn't even say.
The source being available deosn't make it perfect, but it does give you perfect control over it, which is the big difference versus proprietary software. You can use that control to assert privacy and security, if you have the technical means. I really don't understand how people can misunderstand my original post so badly.
It's perfectly fine to play unprotected media on Vista, for now at least. If Microsoft seriously blocked all unprotected content, the public outcry would destroy Microsoft overnight. I sincerely hope they try.
The problem is that, to protect content that media distributors want protected, Microsoft implemented layers upon layers of complicated, heavyweight measures all throughout Vista. These are partly responsible for its terrible performance and stability problems. All of this is a futile effort to solve an unsolvable cryptographic problem, where the recipient and attacker are the same person.
The very fact that the DRM scheme is built into the kernel means that, no, you can't just use DLL injection. If you're developing a kernel injection to disable it, you won't get your driver signed. And if you use an unsigned driver, the kernel will enter Defcon 6. The only route left is to find an exploit and use that, at which point you're literally attacking your own machine just to cut out the built-in malware.
Which is pretty reasonable because there's no way to validate a benchmark submission like that. Professional benchmarkers actually go on-site to your server and certify their work in person. That's why nobody bothers with professional benchmarkers.
I know that already. That's why it could have easily led to a high profile compromise. A lot of web sites can be modified just by logging in via SSH, which you'd be able to do if you hit the right key for the right user. And with a search space of that many keys, it's easier than a brute force password search.
Ironically it's exactly the people who were careful about using only private keys (myself included) that were affected, and password-only users were much less affected. Of course everyone is affected to some degree, but you wouldn't have to regenerate a password.
Hey, is there any word if diffie hellman key generation was also weak? That could potentially be much much worse than the private key problem because that means ephemeral keys aren't ephemeral after all, and old tcpdump archives could be decrypted.
Yes, and that's still much better than when much worse mistakes are made in proprietary systems. At least in the open source case the mistake *was* found, and because of the heterogeny of the open source space, it only affected "some" distributions, and the fix was released in a matter of hours. I haven't heard of a single high profile target compromised because of that error. Many Windows bugs have affected over 80% of the world's desktops at a time, and there have been *plenty* of those, not just one.
And if you want to play this game, why not bring up the case where an actual blackhat tampered with the Linux upstream CVS repository and his clever backdoor was still caught before it was even released. http://kerneltrap.org/node/1584 Just because a single error occured in Debian's process does not damn the entire open source world.
The license does guarantee you have control over it, whether or not you have the practical means to assert the control you want. If a feature violates your privacy, you're welcome to remove it. If that would deny you some functionality, such as a protocol feature, that's your decision, and a free software license won't get in your way.
It's splitting hairs at this point, but the difference between libre software and closed software is so large in this case that I am comfortable using generalisations like "complete" and "guarantee".
Like I just replied to the other AC, of course you have no way to verify that it's secure, but at least with the source you still have power over it. If you don't want DRM integrated into the kernel, you don't have to have it. Go ahead and remove the DRM from Vista. I'll wait right here.
That's a useless argument. Having the source and having a community built around the source is already infinitely better than having neither. The very tangible result of this is that Windows Vista is covered in DRM and privacy leaks from the ground up, while you can get a wide range of modern Linux and BSD distros with neither of those problems.
If you have complete control over your software, as free (as in freedom) software guarantees by definition, you can enforce your own privacy and security. If you have a solution you cannot modify, you are completely restricted to its ideas of privacy and security.
Human freedom has to extend to freedom of information and freedom of control over our own tools, including software and hardware. If we allow our corporations and governments to control our tools, they move on to controlling our media (DRM's already here) and eventually our legal freedom (DMCA raids?!)
You'll see some similar things from Java in the next few years. The JVM is sufficiently advanced that a DLR is not necessary for it. JRuby in particular is already generally faster, by no small margin, than the C Ruby 1.8 it is compatible with. I repeat, the Java version is faster than the C version and delivers compatible functionality. From what I've seen that's far far ahead of any DLR language. The DLR is solving problems Java doesn't have.
What I don't get is, what happened to RubyCLR? This IronRuby has the same name as an old IronRuby. Microsoft hired RubyCLR developers and now is developing yet another IronRuby instead? Are they seriously starting over just to get it under a different license?!
Out of curiosity, what's a modern audio codec that outperforms Vorbis in compression rates for the same level of fidelity? From all the experimentation I've done, no *popular* codec actually beats Vorbis, but that's not to say I know about and tested every codec available.
Alright, let me rephrase: the problem has been solved as best as possible given that Unicode is what we've got and it's not going away. Ruby hasn't even gotten that far yet, which is one of my main reasons for preferring Python and Java for serious projects.
I really don't know how Ruby gets away with having such bad encoding support. Java and Python both solved that problem long ago, and Python 3 gets even more Java-like by having the standard string type be unicode. Heck, even C++ frameworks solved it. Meanwhile Ruby makes encodings just as hard as in C, if not harder.
IANAL, but I think until a distribution settlement or injunction applies to Mono, it's free for all. Even if Microsoft made threats, unless they were willing to prove it in court, there'd be no legal issue with distributing Mono.
Anyway, who needs Mono? Now we have OpenJDK which is a much better implementation of a managed static language platform. It's just plain better, and with no patent threats.
What does that have to do with software licensing? I think you're responding to the wrong post entirely. I made no mention of support vendors. I said that if you have code without a company willing to support it (in a timely and economical manner), open source lets you fix it and closed source generally makes it illegal to even try.
I'm talking about the population at large, not specific companies. A company can go to great lengths to hire people, they don't have to be already in the company. Contracts are a very common way to get work done without taking somebody on board permanently.
If you're going to break backwards compatibility with Windows, why not just run Linux? Like you said, you can have adequate legacy support via WINE et al.
That's Microsoft's problem actually. Their only real value now is legacy compatibility. They can't keep going with Windows because it's become broken and unmanagable even for its end users, much less its own developers. They can't break away from Windows, because without the compatibility, they're suddenly in direct competition with vastly superior systems like Linux and MacOSX which now have their own ecosystems and maturity. The best Microsoft could do is release their own compliant Unix based on BSD, essentially a Microsoft OSX, and even then they'd be years behind.
And now we have an announcement that Windows 7 will be at best an incremental evolution of Vista, which means they're sticking with backwards compatibility, the one thing that's becoming less and less important in an increasingly heterogenous industry.
This is the single most important reason why Microsoft can only die from here on. To dig its way out of this hole, it'll have to replace its entire business model and corporate culture.
Slashdot Mirror
Python is way more of a functional language than Ruby, but Ruby's brilliant use of modules and its object/type system makes it pretty functional nonetheless, in that you can reuse functions like in a functional language but you call them and can override them like in an OO language.
However, the very OO-centric approach falls flat on its face sometimes. Functional really does fit the bill better, and there, Python's more balanced approach is nice. For instance:
genome11.mateWith(genome2) # Ruby/Java style
vs
mate(genome1, genome2) # Python style
In the first case, you're implying genome1 has the correct implementation, which could have been overriden. In the second case, you're implying mating is not a function of either genome, but a function of the pair itself, which is what most accurately represents the real relationship.
It's a pretty big difference to how your code ends up being structured. I personally prefer Python's approach.
PS: Yes, a "real" OO architecture would have a Mater object with a mate(genome1, genome2) method. This just makes it a much more verbose and clunky version of the functional style, where the mating function *is* the object.
H.263 is probably older than you are. Look it up.
ReactOS can already be used as a server. Well, if you own any of the 5 devices it supports.
Alright alright I'm just kidding.
3 devices.
Once again, "if you have the technical means". It's exhausting repeating the same thing over and over while you're arguing with something I didn't even say.
The source being available deosn't make it perfect, but it does give you perfect control over it, which is the big difference versus proprietary software. You can use that control to assert privacy and security, if you have the technical means. I really don't understand how people can misunderstand my original post so badly.
It's perfectly fine to play unprotected media on Vista, for now at least. If Microsoft seriously blocked all unprotected content, the public outcry would destroy Microsoft overnight. I sincerely hope they try.
The problem is that, to protect content that media distributors want protected, Microsoft implemented layers upon layers of complicated, heavyweight measures all throughout Vista. These are partly responsible for its terrible performance and stability problems. All of this is a futile effort to solve an unsolvable cryptographic problem, where the recipient and attacker are the same person.
It'd be hilarious if it was fiction.
The very fact that the DRM scheme is built into the kernel means that, no, you can't just use DLL injection. If you're developing a kernel injection to disable it, you won't get your driver signed. And if you use an unsigned driver, the kernel will enter Defcon 6. The only route left is to find an exploit and use that, at which point you're literally attacking your own machine just to cut out the built-in malware.
"Completely trivial" indeed.
Which is pretty reasonable because there's no way to validate a benchmark submission like that. Professional benchmarkers actually go on-site to your server and certify their work in person. That's why nobody bothers with professional benchmarkers.
I know that already. That's why it could have easily led to a high profile compromise. A lot of web sites can be modified just by logging in via SSH, which you'd be able to do if you hit the right key for the right user. And with a search space of that many keys, it's easier than a brute force password search.
Ironically it's exactly the people who were careful about using only private keys (myself included) that were affected, and password-only users were much less affected. Of course everyone is affected to some degree, but you wouldn't have to regenerate a password.
Hey, is there any word if diffie hellman key generation was also weak? That could potentially be much much worse than the private key problem because that means ephemeral keys aren't ephemeral after all, and old tcpdump archives could be decrypted.
Yes, and that's still much better than when much worse mistakes are made in proprietary systems. At least in the open source case the mistake *was* found, and because of the heterogeny of the open source space, it only affected "some" distributions, and the fix was released in a matter of hours. I haven't heard of a single high profile target compromised because of that error. Many Windows bugs have affected over 80% of the world's desktops at a time, and there have been *plenty* of those, not just one.
And if you want to play this game, why not bring up the case where an actual blackhat tampered with the Linux upstream CVS repository and his clever backdoor was still caught before it was even released. http://kerneltrap.org/node/1584 Just because a single error occured in Debian's process does not damn the entire open source world.
The license does guarantee you have control over it, whether or not you have the practical means to assert the control you want. If a feature violates your privacy, you're welcome to remove it. If that would deny you some functionality, such as a protocol feature, that's your decision, and a free software license won't get in your way.
It's splitting hairs at this point, but the difference between libre software and closed software is so large in this case that I am comfortable using generalisations like "complete" and "guarantee".
Like I just replied to the other AC, of course you have no way to verify that it's secure, but at least with the source you still have power over it. If you don't want DRM integrated into the kernel, you don't have to have it. Go ahead and remove the DRM from Vista. I'll wait right here.
That's a useless argument. Having the source and having a community built around the source is already infinitely better than having neither. The very tangible result of this is that Windows Vista is covered in DRM and privacy leaks from the ground up, while you can get a wide range of modern Linux and BSD distros with neither of those problems.
If you have complete control over your software, as free (as in freedom) software guarantees by definition, you can enforce your own privacy and security. If you have a solution you cannot modify, you are completely restricted to its ideas of privacy and security.
Human freedom has to extend to freedom of information and freedom of control over our own tools, including software and hardware. If we allow our corporations and governments to control our tools, they move on to controlling our media (DRM's already here) and eventually our legal freedom (DMCA raids?!)
My point stands - it's one optimisation, not a whole separate project.
What I don't get is, what happened to RubyCLR? This IronRuby has the same name as an old IronRuby. Microsoft hired RubyCLR developers and now is developing yet another IronRuby instead? Are they seriously starting over just to get it under a different license?!
Out of curiosity, what's a modern audio codec that outperforms Vorbis in compression rates for the same level of fidelity? From all the experimentation I've done, no *popular* codec actually beats Vorbis, but that's not to say I know about and tested every codec available.
Alright, let me rephrase: the problem has been solved as best as possible given that Unicode is what we've got and it's not going away. Ruby hasn't even gotten that far yet, which is one of my main reasons for preferring Python and Java for serious projects.
I really don't know how Ruby gets away with having such bad encoding support. Java and Python both solved that problem long ago, and Python 3 gets even more Java-like by having the standard string type be unicode. Heck, even C++ frameworks solved it. Meanwhile Ruby makes encodings just as hard as in C, if not harder.
You can replace the machine for the cost of a fancy dinner. I'd say it's time to move on. That hardware is going to fail soon anyway.
IANAL, but I think until a distribution settlement or injunction applies to Mono, it's free for all. Even if Microsoft made threats, unless they were willing to prove it in court, there'd be no legal issue with distributing Mono.
Anyway, who needs Mono? Now we have OpenJDK which is a much better implementation of a managed static language platform. It's just plain better, and with no patent threats.
What does that have to do with software licensing? I think you're responding to the wrong post entirely. I made no mention of support vendors. I said that if you have code without a company willing to support it (in a timely and economical manner), open source lets you fix it and closed source generally makes it illegal to even try.
I'm talking about the population at large, not specific companies. A company can go to great lengths to hire people, they don't have to be already in the company. Contracts are a very common way to get work done without taking somebody on board permanently.
If you're going to break backwards compatibility with Windows, why not just run Linux? Like you said, you can have adequate legacy support via WINE et al.
That's Microsoft's problem actually. Their only real value now is legacy compatibility. They can't keep going with Windows because it's become broken and unmanagable even for its end users, much less its own developers. They can't break away from Windows, because without the compatibility, they're suddenly in direct competition with vastly superior systems like Linux and MacOSX which now have their own ecosystems and maturity. The best Microsoft could do is release their own compliant Unix based on BSD, essentially a Microsoft OSX, and even then they'd be years behind.
And now we have an announcement that Windows 7 will be at best an incremental evolution of Vista, which means they're sticking with backwards compatibility, the one thing that's becoming less and less important in an increasingly heterogenous industry.
This is the single most important reason why Microsoft can only die from here on. To dig its way out of this hole, it'll have to replace its entire business model and corporate culture.