Like I said, I'm only talking about *popular* languages and I didn't claim it was innovative in Python. Python does it and does it well, and unlike Haskell, Python enjoys wide real-world use.
LINQ is nice, except it's decades too late. Of the languages in common use today, Python and Ruby have much better alternatives to linq built in (and have had them for many years), and even new languages like Scala support similar functionality.
Your example in Python with a list comprehension, broken down into multiple lines for clarity:
monkeys = [
(animal.id, animal.name, animal.birthDay)
for animal in myAnimalsCollection
if animal.type is monkey ]
And a comprehension of multiple lists is similar:
pairs = [
(a, b)
for a in range(10)
for b in range(10)
if b == a * 2 ]
You have been able to do that for many years in Python, and yet Microsoft fanatics act like it's something new and innovative.
IronPython already works fine on Mono, but it doesn't have IDE support. PyDev in Eclipse is pretty nice for pure Python and Jython.
Personally I'd rather work directly in Python/Ruby on GTK/Qt than go through an extra layer that is.NET. Maybe Anjuta could stop sucking and support Python, or Eclipse could have Glade integration.
And while Mono's not horrible, but it's not nearly as fast as the Sun JVM, so if I want fast bytecode I'd rather use Java than C#.
OpenSSL is not from the OpenBSD camp, otherwise it would be BSD-licensed and a whole lot better. OpenSSH is from OpenBSD, yes, and a great number of its exploits in the past only affected other systems (running the pX versions).
How do you know it doesn't affect you? This particular case may not affect you, but security systems have had entropy weaknesses since the beginning of time. Windows has come under a lot of fire for having a pitiful entropy architecture in general, and Linux has in the past as well (Linux the kernel, that is, which is where we get/dev/random).
You need to generate a new CA if its private key is weak. Having that primary key, an attacker can sign his own certificates and have them join your PKI. Unless you're auditing every certificate authenticated against your systems, you'll never even notice. This isn't like an individual client certificate you can just revoke.
OpenVPN, etc. are extremely vulnerable to this. In fact, all of public key cryptography hinges entirely on the secrecy of private keys, so any vulnerability which reduces the search space is a really really big deal.
I'm very confident black hats have had this in their arsenal for a long time, leaving it unannounced while weak keys accumulate.
Only the private keys like RSA and DSA are affected. Unless you use that to protect an otherwise exposed key for cryptsetup, no, crypsetup is unrelated.
But another way of saying this is, because of this vulnerability, everyone is potentially harmed, and many machines have probably already been exploited. The vulnerability basically reduces a very large key search space to a small one. Given your public key, an attacker could find the private key in a relatively short time.
By the same logic, QEMU implements x86 if run in interpreter mode. It doesn't implement the hardware itself, but it does implement the instruction specifications. Modern physical CPUs run a sort of VM anyway, to support more instructions on top of a leaner core and still keep light pipelines.
"They've long had a history of getting corrupt as they grow in size, they're hard to search, and they don't have much in the way of built-in security controls"
You could say that about any corporation or government.
Comparable can be better than or lesser than, as long as it's close enough to bother comparing. I think you're just trying to pick holes in my brief report of what many many Java developers have already benchmarked for their own purposes, including myself.
What code did you compare? I said "regularly outperforms even finely optimised C/C++ code for many tasks", not *all* tasks. The plain fact is that runtime optimization can beat static optimization, and Java does it occasionally. It's safe to say that in Java 7 it will be even better, with more cases meeting or exceeding C/C++.
And keep in mind, while C/C++ *can* be optimized manually with tedium like moving code to headers (so it can be inlined), declaring constants (so they, and their resulting code, can be inlined too), etc., at runtime in the JVM this kind of work is automatic. You generally don't have to sacrifice your cleanliness and abstraction to make Java optimize well, except in currently lacking cases like boxed primitives (which will remain boxed and therefore slow - yes, I benchmarked that too).
Yes, it's much faster now. Now JVMs perform on-the-fly optimisations much like the ones C compilers do at compile time, but since they're done at runtime, they can very specifically target the runtime context like your CPU model. Even though a specific optimisation set in a static compiler can do the same or even better, at runtime you get more information and more flexibility like being able to turn off synchronization when there's no chance of contention anyway.
Version 6 of Sun's JVM now regularly outperforms even finely optimised C/C++ code for many tasks, and cuts through layers of abstraction and encapsulation so you don't have to clutter your code to speed it up. There are still many problems left for Java's performance, but they're going away, meanwhile C/C++ still have huge problems in language design and ease of development that are *not* going away.
As an aside, the fact that Java has constantly-on features like garbage collection, bounds checks, null pointer checks, type safety checks, JNI call checks, etc. and STILL performs comparably with C/C++ code lacking these features, is a strong sign that the JVM itself optimizes code *very* well. If you turn all of these things off it goes even faster, but as a developer I like to have as much confidence in my code's correctness as possible, and doing formal proofs isn't fun.
Sorry sorry, rushed my post and came out with IE instead of IIS. And I *know* WinNT has the same user ID switch as Unix, but the problem is that until recently even Microsoft didn't use it, so it's obvious that security engineering in the Windows world is pathetic. The exploits speak for themselves.
Lately I'm stuck on an IBM desktop with 512MB of RAM running Windows XP, JDK 6 and Eclipse 3.3, and I use it to develop and run AI experiments. Java's far from memory efficient compared to C/C++, but it's not nearly bad enough to offset the development effort required to write reliable, reusable C/C++.
I can easily justify using Java software if it really does save me time and effort compared to native code counterparts. Eclipse is vastly more useful than other open IDEs like KDevelop and Anjuta, and portable as a bonus.
That's exactly right, but the difference is whether the operating system kernel knows about this, or has to have it hacked into a lower layer. Xen kernels, modified to use the Xen host interface optimally, are much more efficient and flexible than unmodified kernels. It's a whole different kind of virtualisation, and yes, I should have been more clear.
Software works the same way - you can do it "right" by writing software intended for isolation and low privileges, or you can hack it on later at a lower layer and suffer tremendous penalties to functionality, usability and performance.
And keep in mind, in Windows, those penalties just add on to all of the *existing* handicaps of functionality, usability and performance that have accumulated from decades of doing things wrong.
Look up setuid() in POSIX standards. Go on, we'll wait.
I can't name a single common daemon in a modern Linux system that doesn't reduce its privileges straight after opening a privileged port (at which point no attacker data can be supplied yet). Even some regular programs drop privileges where practical "just in case". In modern Unix, the system protects YOU.
IE6's privilege requirements make an already insecure server a system-wide threat. You'd have to be incredibly ignorant to believe otherwise. It's not even a matter of opinion, it's a matter of history and hard numbers.
Having to virtualise components of Windows just for program separation just confirms the problems exist and are not being solved correctly.
It's like how you can't really run Linux and Windows in the same memory space, so we use machine virtualisation to carve up the memory space and trick one (or the other, or both) that they're isolated.
It's a hack to make up for the PC architecture assumption of one kernel at a time. Xen is just another hack for the same problem.
A disturbing amount of common Windows software makes the same mistake even in this modern day, and Vista users are suffering for it now that Microsoft is making some attempt at catching up to Unix' security model.
Put down the crack pipe and read http://en.wikipedia.org/wiki/Inferno_(operating_system). It's not even necessarily the first such effort, but it's incredibly "prior" art. And it's a completely working system that can run on bare hardware or on top of another system, not some MS Research project we'll never see released commercially*.
* Besides, if Microsoft releases any new operating system, it will have to be at least as bad as Vista (for compatibility) or break all backward compatibility and compete with the ever-growing and mature Linux and MacOSX platforms. Microsoft is up shit creek - they can't maintain what they have and if they move on from it, they have to compete with others who got it much more "right" long ago.
When the requirements for Vista exceed the requirements for Oblivion, and the Vista experience is much more challenging and less enjoyable than Oblivion, Vista more than qualifies as a game.
And additionally, if you "fix" it with third-party or home-made parts, it's illegal. In fact, the tools you use to fix it may even be illegal to distribute, under the DMCA circumvention clause.
The poster is twitter, whose karma has been buried very deep. It doesn't matter what he posts now, the moderation system automatically assumes it's trash. Similarly, we get +1 automatically for not being utter prats.
Slashdot Mirror
Like I said, I'm only talking about *popular* languages and I didn't claim it was innovative in Python. Python does it and does it well, and unlike Haskell, Python enjoys wide real-world use.
LINQ is nice, except it's decades too late. Of the languages in common use today, Python and Ruby have much better alternatives to linq built in (and have had them for many years), and even new languages like Scala support similar functionality.
Your example in Python with a list comprehension, broken down into multiple lines for clarity:
monkeys = [
(animal.id, animal.name, animal.birthDay)
for animal in myAnimalsCollection
if animal.type is monkey
]
And a comprehension of multiple lists is similar:
pairs = [
(a, b)
for a in range(10)
for b in range(10)
if b == a * 2
]
You have been able to do that for many years in Python, and yet Microsoft fanatics act like it's something new and innovative.
IronPython already works fine on Mono, but it doesn't have IDE support. PyDev in Eclipse is pretty nice for pure Python and Jython.
.NET. Maybe Anjuta could stop sucking and support Python, or Eclipse could have Glade integration.
Personally I'd rather work directly in Python/Ruby on GTK/Qt than go through an extra layer that is
And while Mono's not horrible, but it's not nearly as fast as the Sun JVM, so if I want fast bytecode I'd rather use Java than C#.
OpenSSL is not from the OpenBSD camp, otherwise it would be BSD-licensed and a whole lot better. OpenSSH is from OpenBSD, yes, and a great number of its exploits in the past only affected other systems (running the pX versions).
How do you know it doesn't affect you? This particular case may not affect you, but security systems have had entropy weaknesses since the beginning of time. Windows has come under a lot of fire for having a pitiful entropy architecture in general, and Linux has in the past as well (Linux the kernel, that is, which is where we get /dev/random).
You need to generate a new CA if its private key is weak. Having that primary key, an attacker can sign his own certificates and have them join your PKI. Unless you're auditing every certificate authenticated against your systems, you'll never even notice. This isn't like an individual client certificate you can just revoke.
OpenVPN, etc. are extremely vulnerable to this. In fact, all of public key cryptography hinges entirely on the secrecy of private keys, so any vulnerability which reduces the search space is a really really big deal.
I'm very confident black hats have had this in their arsenal for a long time, leaving it unannounced while weak keys accumulate.
Only the private keys like RSA and DSA are affected. Unless you use that to protect an otherwise exposed key for cryptsetup, no, crypsetup is unrelated.
But another way of saying this is, because of this vulnerability, everyone is potentially harmed, and many machines have probably already been exploited. The vulnerability basically reduces a very large key search space to a small one. Given your public key, an attacker could find the private key in a relatively short time.
By the same logic, QEMU implements x86 if run in interpreter mode. It doesn't implement the hardware itself, but it does implement the instruction specifications. Modern physical CPUs run a sort of VM anyway, to support more instructions on top of a leaner core and still keep light pipelines.
"They've long had a history of getting corrupt as they grow in size, they're hard to search, and they don't have much in the way of built-in security controls"
You could say that about any corporation or government.
Comparable can be better than or lesser than, as long as it's close enough to bother comparing. I think you're just trying to pick holes in my brief report of what many many Java developers have already benchmarked for their own purposes, including myself.
What code did you compare? I said "regularly outperforms even finely optimised C/C++ code for many tasks", not *all* tasks. The plain fact is that runtime optimization can beat static optimization, and Java does it occasionally. It's safe to say that in Java 7 it will be even better, with more cases meeting or exceeding C/C++.
And keep in mind, while C/C++ *can* be optimized manually with tedium like moving code to headers (so it can be inlined), declaring constants (so they, and their resulting code, can be inlined too), etc., at runtime in the JVM this kind of work is automatic. You generally don't have to sacrifice your cleanliness and abstraction to make Java optimize well, except in currently lacking cases like boxed primitives (which will remain boxed and therefore slow - yes, I benchmarked that too).
A true geek would use aptitude, which is much more advanced than apt-get.
A super true geek like me aliases with sudo and favorite flags included: alias apty='sudo aptitude -rPvV'.
A hyper geek would use zsh instead of bash, but I draw the line there.
Yes, it's much faster now. Now JVMs perform on-the-fly optimisations much like the ones C compilers do at compile time, but since they're done at runtime, they can very specifically target the runtime context like your CPU model. Even though a specific optimisation set in a static compiler can do the same or even better, at runtime you get more information and more flexibility like being able to turn off synchronization when there's no chance of contention anyway.
Version 6 of Sun's JVM now regularly outperforms even finely optimised C/C++ code for many tasks, and cuts through layers of abstraction and encapsulation so you don't have to clutter your code to speed it up. There are still many problems left for Java's performance, but they're going away, meanwhile C/C++ still have huge problems in language design and ease of development that are *not* going away.
As an aside, the fact that Java has constantly-on features like garbage collection, bounds checks, null pointer checks, type safety checks, JNI call checks, etc. and STILL performs comparably with C/C++ code lacking these features, is a strong sign that the JVM itself optimizes code *very* well. If you turn all of these things off it goes even faster, but as a developer I like to have as much confidence in my code's correctness as possible, and doing formal proofs isn't fun.
Wow, I thought I was going to pop a vein until it sunk in. Well played.
Sorry sorry, rushed my post and came out with IE instead of IIS. And I *know* WinNT has the same user ID switch as Unix, but the problem is that until recently even Microsoft didn't use it, so it's obvious that security engineering in the Windows world is pathetic. The exploits speak for themselves.
Lately I'm stuck on an IBM desktop with 512MB of RAM running Windows XP, JDK 6 and Eclipse 3.3, and I use it to develop and run AI experiments. Java's far from memory efficient compared to C/C++, but it's not nearly bad enough to offset the development effort required to write reliable, reusable C/C++.
I can easily justify using Java software if it really does save me time and effort compared to native code counterparts. Eclipse is vastly more useful than other open IDEs like KDevelop and Anjuta, and portable as a bonus.
That's exactly right, but the difference is whether the operating system kernel knows about this, or has to have it hacked into a lower layer. Xen kernels, modified to use the Xen host interface optimally, are much more efficient and flexible than unmodified kernels. It's a whole different kind of virtualisation, and yes, I should have been more clear.
Software works the same way - you can do it "right" by writing software intended for isolation and low privileges, or you can hack it on later at a lower layer and suffer tremendous penalties to functionality, usability and performance.
And keep in mind, in Windows, those penalties just add on to all of the *existing* handicaps of functionality, usability and performance that have accumulated from decades of doing things wrong.
Look up setuid() in POSIX standards. Go on, we'll wait.
I can't name a single common daemon in a modern Linux system that doesn't reduce its privileges straight after opening a privileged port (at which point no attacker data can be supplied yet). Even some regular programs drop privileges where practical "just in case". In modern Unix, the system protects YOU.
IE6's privilege requirements make an already insecure server a system-wide threat. You'd have to be incredibly ignorant to believe otherwise. It's not even a matter of opinion, it's a matter of history and hard numbers.
In conclusion, bwahahahahahahahahhaah
Having to virtualise components of Windows just for program separation just confirms the problems exist and are not being solved correctly.
It's like how you can't really run Linux and Windows in the same memory space, so we use machine virtualisation to carve up the memory space and trick one (or the other, or both) that they're isolated.
It's a hack to make up for the PC architecture assumption of one kernel at a time. Xen is just another hack for the same problem.
A disturbing amount of common Windows software makes the same mistake even in this modern day, and Vista users are suffering for it now that Microsoft is making some attempt at catching up to Unix' security model.
Put down the crack pipe and read http://en.wikipedia.org/wiki/Inferno_(operating_system). It's not even necessarily the first such effort, but it's incredibly "prior" art. And it's a completely working system that can run on bare hardware or on top of another system, not some MS Research project we'll never see released commercially*.
* Besides, if Microsoft releases any new operating system, it will have to be at least as bad as Vista (for compatibility) or break all backward compatibility and compete with the ever-growing and mature Linux and MacOSX platforms. Microsoft is up shit creek - they can't maintain what they have and if they move on from it, they have to compete with others who got it much more "right" long ago.
They're already merging in the form of IcedTea. However, this will be mostly unecessary when the full class library is opened.
When the requirements for Vista exceed the requirements for Oblivion, and the Vista experience is much more challenging and less enjoyable than Oblivion, Vista more than qualifies as a game.
And additionally, if you "fix" it with third-party or home-made parts, it's illegal. In fact, the tools you use to fix it may even be illegal to distribute, under the DMCA circumvention clause.
The poster is twitter, whose karma has been buried very deep. It doesn't matter what he posts now, the moderation system automatically assumes it's trash. Similarly, we get +1 automatically for not being utter prats.
It may not be enforceable. A lot of EULAs aren't, or aren't confirmed to be.
I'm sorry, I couldn't read your post. Can you follow up by posting the key?