So you're asking for all open-write-close operations to do an fsync at the end? Or only if a rename is done?
If the former, then that's not very efficient. If the latter, then I'd rather write an fsync than a rename, and not just because it works, because it's less hackish (the rename method assumes that a rename will 'trick' the OS into writing to disk so there is something to rename).
With EXT3 the risk window was 5 seconds. Now its 150 seconds.
Its ridiculous to move what should be a low-level data integrity function
out of the File System and inflict it on user-land code.
But even 5 seconds of risk is unacceptable! Ext4 makes the problem much more apparent, but it was there all along. Userspace apps should be written to not have even a 5 second risk window.
Developers are entrenched in DX development, and Microsoft will try to keep it that way. That's the real problem that needs to be solved.
Is that still true? All the major 3D engines - Gamebryo, CryEngine, id Tech (5), Unity, etc., can output to DirectX, OpenGL and various console graphic systems. And at the low end even open source engines like Ogre and Irrlicht can output to multiple renderers.
Are there still a lot of Windows games that write raw DirectX code?
True enough. But the fundamental problem remains: the more information is available statically, the better you can compile it. Javascript has relatively little information available statically, and so is hard to compile.
Emphasis mine.
JavaScript, as a dynamic language, can't be statically compiled - just as you say. But, at runtime a lot more information is available (in fact, perhaps more than at compile time with a static language). That information is used by modern JavaScript engines, e.g., TraceMonkey utilitizes Trace Trees to optimize such things. So it can detect that a loop iterates over an integer value - even though that isn't obvious from looking at the code - and generates native code for that.
Static information does make compilation optimizations easy, but isn't necessary for performance, if you have a suitably sophisticated runtime environment - which we are now finally starting to have.
Javascript just isn't a good language for massive computation. It only supports one kind of number (double), has no vectorization or multicore capabilities, has no unboxed arrays, and even for basically scalar code is some 40x slower than C, let alone optimized ASM compute kernels. (This is for crypto on Google Chrome. Other browsers are considerably slower on this benchmark. YMMV.)
YMMV is true. I see speed differences of x5-x10 between -O3 C code and V8 - significant, but far from x40.
As for having only doubles, that is true for the language, but not for engines, which can implement an integer type as well. This is a little tricky to do, but certainly possible: Anything that starts out as an integer will remain one over addition, subtraction and multiplication; you need to add checks for overflows and to handle division. In other words, developers have the convenience of only working with doubles - something Python 3.0 sort of agrees with, as division now returns float values by default - but a clever engine can make a lot of code as fast as if it were using integers.
With compilers like GWT [google.com], Pyjamas [pyjs.org], and HotRuby [accelart.jp], I sometimes wonder if JavaScript is starting to emerge as a "portable assembly language" for dynamic languages, the way C is often used by higher-level language compilers. I mean, when it comes down to it JS is basically just hash tables and closures, some of the basic elements required for dynamic language execution.
However, a language is more than hash tables and closures, and even the great similarity between most dynamic languages isn't enough.
For example, in JavaScript all you have are doubles - no integers. That means that if you are using Pyjamas, and you write some math stuff in what appears to be Python, it won't behave like Python. Because of a lot of stuff like this, a straightforward translation of syntax-to-syntax will never work.
Instead, you can do more complicated stuff - like compile code using integers into code that converts back to integers in JavaScript (via rounding, etc.) - but that's not trivial, you'll need to do some of that compiling at runtime, since by looking at the source you don't know what is an integer value and what isn't!
If you want true compatibility with Python, the only solution is really to run a virtual machine for it. You can write such a thing in JavaScript - PyPy have. It's a cool idea, but with obvious drawbacks.
Or, you can do what the Pyjamas etc. people do - be ok with writing the syntax of Python but having the semantics of JavaScript. It's a hybrid language, and you'll always run into corners and bugs that are hard to figure out if you do anything interesting, but stick to conventional code and you might do ok.
I'm glad to see they got native compilation in there. It just seems ridiculously stupid, once your program's working nicely, not to provide the efficiency of a good native compilation.
Well, actually there are plenty of disadvantage to native compilation. For one, it becomes tied to a particular arch (and possibly OS). Also, it removes the possibility for various JIT optimizations (like enabling certain CPU features if present at runtime - that's possible with static compilation, but almost never done). It also makes some security and debugging features less useful. But, yeah, it has obvious advantages as well, and having it as an option is great.
The question isn't why don't I have faith that Mono is the right direction, it's more, why should I?
You make a lot of valid points. Clearly Mono isn't for everyone, and if its advantages don't speak to you, then that's fine - don't use it.
Even without answering it, it's obvious that there is a good answer, because Mono is seeing uptake by serious projects. For example, the Unity game engine and the popular virtual world Second Life.
As for a concrete answer: For starters, if you want something like Java - a virtual machine, with a nice language that manages memory for you, and can also run multiple scripting languages as well - then Java vs. Mono is somewhat like GTK vs. Qt. Yeah, for a long time Qt was arguably better, but Qt was GPL while GTK was LGPL, so just because of that GTK saw a lot of use (there were other reasons as well, but this was a major one). Ditto here, Java is GPLed while Mono is LGPL (with class libs as MIT and a few other details), which makes corporate adoption much simpler. Yeah, technically Java has better performance - say by a factor of 2 - but licensing is also a serious consideration.
Other reasons: Some people prefer C# to Java (I'm not arguing either way, just pointing out that some people think that way - and some think the opposite), some people want to leverage existing C# code that they have, some people want an implementation of Python with native threads (IronPython on Mono does that; Jython on Java was inferior for a while, but might finally be catching up just recently), etc.
Just fork out the $$ for VS and you've instantly saved yourself weeks of development. But Mono.... just give up now. Unless things have changed over the past 2 or 3 years. But I doubt it.
So basically, you're ranting against something you haven't tested for close to 3 years. But you 'doubt' it has changed, so you are sure your opinion is still valid.
And you've been modded Informative!
Re:Ruby/Python in JVM/CLR not a Silver Bullet
on
Ruby 1.9.1 Released
·
· Score: 1
If you have benchmarks showing V8/TM/SFE perform within an order of magnitude of C on something general-purpose (not a bloody fib benchmark) I'd love to see them as well. I have not seen such numbers in my searching.
The benchmarks tend to be either bloody fibonacci tests;) or 'general-purpose' JavaScript tests, which end up testing DOM etc. quite heavily (well, that is what most JavaScript does). So both are debatable. The fibonacci ones are more relevant to a cross-language comparison IMO, and those tend to show basically what I said. You can also run the code yourself and see.
So it's a matter of what you can get done with what code; if JS is 10x faster than Python but you have to write 10x as much code to get the same things done, where does that put you?
I agree Python requires less code, but 10x is a gross exaggeration. But yeah, there's a tradeoff obviously.
Re:Ruby/Python in JVM/CLR not a Silver Bullet
on
Ruby 1.9.1 Released
·
· Score: 1
I am more familiar with the Python side - Jython, etc. - then Ruby. Perhaps JRuby is extremely different than Jython, I don't know, but on the Python side, performance of Jython is on par with CPython, and has no hope in the foreseeable future of surpassing it.
V8 and Tracemonkey do a lot to optimize JavaScript, but there's an important detail missing in almost all benchmarks of them: they make JavaScript less slow, but do not in any way bring it to the performance level of Java.
Well, all benchmarks are problematic, but overall I don't think what you said is accurate. In my experience, and also based on other people's testing, V8, TraceMonkey and SquirrelFish Extreme actually do bring JavaScript closer to Java in performance than to Python/Ruby/old JavaScript engines. It is typical for us to see something like V8/TM/SFE being around 4 times slower than C, and 10 times faster than CPython.
JVMs like Hotspot are the best hope for fast dynamic languages in the near future.
Well, we'll have to disagree about that one:) I have far more hope placed in the V8/TM/SFE approach than the JVM/CLR. Another approach I think is more likely to succeed is that of PyPy.
Again, perhaps in Ruby things are different than for Python. If you have benchmarks showing JRuby ourperforms V8/TM/SFE, I'd be curious to see that.
Re:Ruby/Python in JVM/CLR not a Silver Bullet
on
Ruby 1.9.1 Released
·
· Score: 1
In theory they might do that. However, AFAIK the 'dynamic optimizations' they are applying are similar to Microsoft's DLR. These are useful, but not in the same area as what we have seen in JavaScript engines in the last 6 months.
It isn't even clear how to create a generic JIT for all dynamic languages. For example, the latest JavaScript engines are great for JavaScript, but as Python and Ruby are even more dynamic, a different approach might be needed for them.
Ruby/Python in JVM/CLR not a Silver Bullet
on
Ruby 1.9.1 Released
·
· Score: 3, Informative
I am not familiar with Rubinius. But regarding all the others - Ruby on Java, on the CLR, etc., none of those are anywhere close to approaching the speed of recent JavaScript engines.
The typical situation is that something like JRuby or Jython are implementations of a dynamic language in Java/C#/etc. instead of in C/C++, but they have the same architecture as the C/C++ engines. This leads to about the same performance - the Java VM does excellent JITing, but as we know, it brings Java into about the same area as C/C++, not faster.
So, these implementations end up being about as fast as the original C/C++ ones (but they have various other advantages, which are their real value).
The latest-generation JavaScript engines - and we are talking about the last 6 months here! - are very different in their architecture. They use techniques like trace trees and hidden classes, along with native code generation using JITs specializing in JavaScript, to generate performance that can, in some cases, be closer to C/C++ than to Python/Ruby.
The PyPy project has been saying this all along, in fact - that to make dynamic languages fast, you can't just implement them in the JVM or such and expect 'magic' to happen with that VM's JIT. It doesn't work that way. Even if you JIT an architecture that does hash table lookups or type checking for each assignment, performance will be poor; the JIT can't fix your algorithm. Fixing the algorithm is exactly what latest-generation Javascript engines like V8 and TraceMonkey do.
Ok, it seems you are right, this does allow limited reverse engineering of the non-LGPLed app, in order to see how it works with the LGPLed library. This might scare GPL-averse companies, in theory, that's a valid point. But hopefully it won't.
Yeah, didn't see that did ya? Almost every boiler plate EULA includes a clause prohibiting reverse engineering
It is my understanding that you can reverse-engineer the LGPLed library, but nothing else. And that isn't much of an issue: the LGPLed part should come with the complete source (or equivalent), so being able to debug/disassemble binaries for which you have the source isn't a big deal. In fact the purpose of this clause (again, to my understanding) is simply to be able to ensure that the source of the LGPLed library indeed corresponds to the binary of said LGPLed library.
So yes, EULAs might need to change - good point. But the change should only be "you can reverse-engineer the LGPLed library X, but nothing else," and that would appear after "you can get the source code to the LGPLed library X from here."
Bottom line, if you are ok with using an LGPLed library - and many otherwise GPL-averse corporations are - then this should not be an issue.
Possibly. But my desktop is 5 yo and Mrs Smidge's desktop is going on 10...! The reason? We don't game, just appliance the heck out of it. No need to upgrade. Same thing with our vehicles, we just fix 'em and take xtra care with preventive maintenance.
=Smidge=
Very sensible, and the economic crisis is pushing more and more people to be like you.
Tech-wise, this crisis is going to put the most pressure on those companies whose fortunes are tied to computer sales, as opposed to use. Microsoft and Intel are the best examples of the former - almost every computer sold includes a Microsoft OS (+Office) and an Intel processor (+supporting chips). Fewer sales means that, for the first time in the history of both companies (except perhaps their very early years) they may experience significant declines in revenue and possibly even losses (the latter might be avoidable through layoffs - which we have been hearing are in the works).
Google is the best example of the latter type of company, whose fortune is tied to use. Simply put, that people use an old machine as opposed to a shiny new one doesn't matter to Google, as long as that machine can show ads on google.com. Looking at it another way, even a steep decline in computer sales doesn't mean fewer eyeballs on ads - just that those eyeballs are using older machines to see those ads. It's not like people are going to stop using the web. Now, clearly the economic crisis won't be all roses for Google - ad budgets are down, which will hurt. But overall, I'd say the model of tying yourself to computer sales - which worked well through forced upgrades - is finally (and deservedly!) under serious pressure, and Google and Google-like companies will benefit in comparison.
Companies sell, eg transfer, software developed with Qt all the time, it's what is made for after all. Obviously the license allow it.
Not what I meant by 'transfer'. You can copy the software, but not transfer the license. In other words, you can distribute your product, but others are not free to fork your product and redistribute it. The forkers would need to purchase a license as well.
I am aware of this, but not entirely sure about what it means. After all, you can already link GPL code with BSD code (that's how the BSDs use ext2/3 code, for example). That's because the BSD license is compatible with the GPL, which means BSD can be relicensed to GPL - the overall project is then considered as GPL. The same is true for almost all the licenses in the list there (except perhaps for Apache, last I heard).
In other words, at worst Google would need to GPL the entire app. But even so they could dual-license their own code, under the GPL and the BSD, so they could still say the code was BSD in a sense. And at best, they could just release it under the BSD, as it's compatible anyhow. Yet, in both cases they are releasing a product with a lot of GPL code in it - Qt itself - which means it can't be forked in a non-GPL manner (there are other implications as well). This is something that I believe Google wants to avoid when possible. With the Linux kernel, it isn't avoidable - there is no replacement. But GTK is a respectable replacement for Qt, and isn't GPL (it's LGPL). The same thinking goes on in a lot of other places, leading to high adoption rates for GTK. Again, Nokia can stop this, and I wish they would, simply by relicensing Qt under the LGPL.
If I were Google (that is a great sentence) I would base it on QT 4. Fast, customizable, cross-platform, modern and integrated with WebKit.
Qt is nice, but its licensing prevents Google from using it in this way. To use Qt, Google would need to either pay for a license, but it wouldn't be transferable to others, or Chrome would need to be GPLed. Google goes to great effort to license it's code under the Apache/BSD/etc. licenses whenever possible, as it considers this better for it's business (and that's a reasonable position to take).
Until Nokia relicenses Qt to something like the LGPL - many of us would welcome that! - GTK will remain the library of choice in situations like this.
I always though bzr had the edge on git in terms of being a better DVCS. Is there a reason why the article seems to think that git is the default?
No such thing as 'better' here.
Bazaar was the runner-up DVCS, and rightfully so, but it has both advantages and disadvantages. Git is faster and currently more popular. Bazaar has an easier interface, better GUIs, is more easily extensible (Python), and runs better on non-Linux platforms.
So which you prefer is a matter of what you are looking for.
I've seriously never understood the classical religious position on this stuff. I don't believe it would take a God to steer evolution; based on all available evidence, it would take a God to stop it.
Please don't mistake the ramblings of a minority of fundamentalists for the 'classical religious position'. For example, the catholic church officially recognizes the validity of evolution. Most intelligent religious people do as well, and many scientists are religious.
To make glow in the dark yogurt that responds to melamine would be fairly simple if you had the right set of genes: a melamine sensor that, when bound to melamine, binds to a specific DNA sequence (a promoter) that drives expression of a fluorescent protein such as green fluorescent protein ("GFP", a widely used fluorescent marker derived from a jellyfish). It's not difficult, and it's not unsafe
I think the question is, unsafe for *what*? Maybe a glow-in-the-dark yogurt would be edible, which is what you focus on. But consider for example a glow-in-the-dark weed. Perhaps by some fluke this weed will survive better than other common weeds, e.g. because some parasite is turned off by the glowing. We might end up with our entire environment full of these glowing weeds, instead of our normal ones. This might end up good, or bad, for insects/pets/etc., and at the least will be somewhat disconcerting.
If this sort of thing does ever become so easy that people can do it in their garages, we'll eventually have problems like these, I suspect.
The team discovered that the HSV1 DNA is located very specifically in amyloid plaques: 90% of plaques in Alzheimer's disease sufferers' brains contain HSV1 DNA, and most of the viral DNA is located within amyloid plaques. The team had previously shown that HSV1 infection of nerve-type cells induces deposition of the main component, beta amyloid, of amyloid plaques.
100% might have been a clincher. If anti-virals help, I might have rto eat my worlds.
Most people have HSV1. HSV1 DNA locates in the amyloids. So most people expressing the amyloids would have HSV1 DNA in them.
What's up with the 10% of alzhemier amyloids without the HSV1. It sounds like amyloid metabolism is the problem and HSV1 is along for the ride.
That's possible. Further research is needed. However, 90% is still suggestive enough to motivate future research, consider for example the case of HPV, which is now well-known to cause cervical cancer (and a few others). The initial results were much the same as these: 90% or thereabouts of tumors contained HPV DNA.
So this is a promising starting point, but of course only time and future work will tell whether it is an actual causal factor.
Ah, it's even worse. A person might have no history of symptoms but still be infected, and have asymptomatic shedding. So it makes little sense to inquire about a history, at least as far as asymptomatic shedding is considered (you might inquire for other reasons).
That said, it still makes sense to avoid sharing food, kissing, etc. people who have active symptoms. The amount of virus particles is much, much higher than asymptomatic shedding in such a case.
Slashdot Mirror
So you're asking for all open-write-close operations to do an fsync at the end? Or only if a rename is done?
If the former, then that's not very efficient. If the latter, then I'd rather write an fsync than a rename, and not just because it works, because it's less hackish (the rename method assumes that a rename will 'trick' the OS into writing to disk so there is something to rename).
With EXT3 the risk window was 5 seconds. Now its 150 seconds.
Its ridiculous to move what should be a low-level data integrity function out of the File System and inflict it on user-land code.
But even 5 seconds of risk is unacceptable! Ext4 makes the problem much more apparent, but it was there all along. Userspace apps should be written to not have even a 5 second risk window.
Developers are entrenched in DX development, and Microsoft will try to keep it that way. That's the real problem that needs to be solved.
Is that still true? All the major 3D engines - Gamebryo, CryEngine, id Tech (5), Unity, etc., can output to DirectX, OpenGL and various console graphic systems. And at the low end even open source engines like Ogre and Irrlicht can output to multiple renderers.
Are there still a lot of Windows games that write raw DirectX code?
True enough. But the fundamental problem remains: the more information is available statically, the better you can compile it. Javascript has relatively little information available statically, and so is hard to compile.
Emphasis mine.
JavaScript, as a dynamic language, can't be statically compiled - just as you say. But, at runtime a lot more information is available (in fact, perhaps more than at compile time with a static language). That information is used by modern JavaScript engines, e.g., TraceMonkey utilitizes Trace Trees to optimize such things. So it can detect that a loop iterates over an integer value - even though that isn't obvious from looking at the code - and generates native code for that.
Static information does make compilation optimizations easy, but isn't necessary for performance, if you have a suitably sophisticated runtime environment - which we are now finally starting to have.
Javascript just isn't a good language for massive computation. It only supports one kind of number (double), has no vectorization or multicore capabilities, has no unboxed arrays, and even for basically scalar code is some 40x slower than C, let alone optimized ASM compute kernels. (This is for crypto on Google Chrome. Other browsers are considerably slower on this benchmark. YMMV.)
YMMV is true. I see speed differences of x5-x10 between -O3 C code and V8 - significant, but far from x40.
As for having only doubles, that is true for the language, but not for engines, which can implement an integer type as well. This is a little tricky to do, but certainly possible: Anything that starts out as an integer will remain one over addition, subtraction and multiplication; you need to add checks for overflows and to handle division. In other words, developers have the convenience of only working with doubles - something Python 3.0 sort of agrees with, as division now returns float values by default - but a clever engine can make a lot of code as fast as if it were using integers.
With compilers like GWT [google.com], Pyjamas [pyjs.org], and HotRuby [accelart.jp], I sometimes wonder if JavaScript is starting to emerge as a "portable assembly language" for dynamic languages, the way C is often used by higher-level language compilers. I mean, when it comes down to it JS is basically just hash tables and closures, some of the basic elements required for dynamic language execution.
However, a language is more than hash tables and closures, and even the great similarity between most dynamic languages isn't enough.
For example, in JavaScript all you have are doubles - no integers. That means that if you are using Pyjamas, and you write some math stuff in what appears to be Python, it won't behave like Python. Because of a lot of stuff like this, a straightforward translation of syntax-to-syntax will never work.
Instead, you can do more complicated stuff - like compile code using integers into code that converts back to integers in JavaScript (via rounding, etc.) - but that's not trivial, you'll need to do some of that compiling at runtime, since by looking at the source you don't know what is an integer value and what isn't!
If you want true compatibility with Python, the only solution is really to run a virtual machine for it. You can write such a thing in JavaScript - PyPy have. It's a cool idea, but with obvious drawbacks.
Or, you can do what the Pyjamas etc. people do - be ok with writing the syntax of Python but having the semantics of JavaScript. It's a hybrid language, and you'll always run into corners and bugs that are hard to figure out if you do anything interesting, but stick to conventional code and you might do ok.
I'm glad to see they got native compilation in there. It just seems ridiculously stupid, once your program's working nicely, not to provide the efficiency of a good native compilation.
Well, actually there are plenty of disadvantage to native compilation. For one, it becomes tied to a particular arch (and possibly OS). Also, it removes the possibility for various JIT optimizations (like enabling certain CPU features if present at runtime - that's possible with static compilation, but almost never done). It also makes some security and debugging features less useful. But, yeah, it has obvious advantages as well, and having it as an option is great.
The question isn't why don't I have faith that Mono is the right direction, it's more, why should I?
You make a lot of valid points. Clearly Mono isn't for everyone, and if its advantages don't speak to you, then that's fine - don't use it.
What's the point of Mono?
Reasonable question.
Even without answering it, it's obvious that there is a good answer, because Mono is seeing uptake by serious projects. For example, the Unity game engine and the popular virtual world Second Life.
As for a concrete answer: For starters, if you want something like Java - a virtual machine, with a nice language that manages memory for you, and can also run multiple scripting languages as well - then Java vs. Mono is somewhat like GTK vs. Qt. Yeah, for a long time Qt was arguably better, but Qt was GPL while GTK was LGPL, so just because of that GTK saw a lot of use (there were other reasons as well, but this was a major one). Ditto here, Java is GPLed while Mono is LGPL (with class libs as MIT and a few other details), which makes corporate adoption much simpler. Yeah, technically Java has better performance - say by a factor of 2 - but licensing is also a serious consideration.
Other reasons: Some people prefer C# to Java (I'm not arguing either way, just pointing out that some people think that way - and some think the opposite), some people want to leverage existing C# code that they have, some people want an implementation of Python with native threads (IronPython on Mono does that; Jython on Java was inferior for a while, but might finally be catching up just recently), etc.
Just fork out the $$ for VS and you've instantly saved yourself weeks of development. But Mono.... just give up now. Unless things have changed over the past 2 or 3 years. But I doubt it.
So basically, you're ranting against something you haven't tested for close to 3 years. But you 'doubt' it has changed, so you are sure your opinion is still valid.
And you've been modded Informative!
If you have benchmarks showing V8/TM/SFE perform within an order of magnitude of C on something general-purpose (not a bloody fib benchmark) I'd love to see them as well. I have not seen such numbers in my searching.
The benchmarks tend to be either bloody fibonacci tests ;) or 'general-purpose' JavaScript tests, which end up testing DOM etc. quite heavily (well, that is what most JavaScript does). So both are debatable. The fibonacci ones are more relevant to a cross-language comparison IMO, and those tend to show basically what I said. You can also run the code yourself and see.
So it's a matter of what you can get done with what code; if JS is 10x faster than Python but you have to write 10x as much code to get the same things done, where does that put you?
I agree Python requires less code, but 10x is a gross exaggeration. But yeah, there's a tradeoff obviously.
V8 and Tracemonkey do a lot to optimize JavaScript, but there's an important detail missing in almost all benchmarks of them: they make JavaScript less slow, but do not in any way bring it to the performance level of Java.
Well, all benchmarks are problematic, but overall I don't think what you said is accurate. In my experience, and also based on other people's testing, V8, TraceMonkey and SquirrelFish Extreme actually do bring JavaScript closer to Java in performance than to Python/Ruby/old JavaScript engines. It is typical for us to see something like V8/TM/SFE being around 4 times slower than C, and 10 times faster than CPython.
JVMs like Hotspot are the best hope for fast dynamic languages in the near future.
Well, we'll have to disagree about that one :) I have far more hope placed in the V8/TM/SFE approach than the JVM/CLR. Another approach I think is more likely to succeed is that of PyPy.
Again, perhaps in Ruby things are different than for Python. If you have benchmarks showing JRuby ourperforms V8/TM/SFE, I'd be curious to see that.
In theory they might do that. However, AFAIK the 'dynamic optimizations' they are applying are similar to Microsoft's DLR. These are useful, but not in the same area as what we have seen in JavaScript engines in the last 6 months.
It isn't even clear how to create a generic JIT for all dynamic languages. For example, the latest JavaScript engines are great for JavaScript, but as Python and Ruby are even more dynamic, a different approach might be needed for them.
I am not familiar with Rubinius. But regarding all the others - Ruby on Java, on the CLR, etc., none of those are anywhere close to approaching the speed of recent JavaScript engines.
The typical situation is that something like JRuby or Jython are implementations of a dynamic language in Java/C#/etc. instead of in C/C++, but they have the same architecture as the C/C++ engines. This leads to about the same performance - the Java VM does excellent JITing, but as we know, it brings Java into about the same area as C/C++, not faster.
So, these implementations end up being about as fast as the original C/C++ ones (but they have various other advantages, which are their real value).
The latest-generation JavaScript engines - and we are talking about the last 6 months here! - are very different in their architecture. They use techniques like trace trees and hidden classes, along with native code generation using JITs specializing in JavaScript, to generate performance that can, in some cases, be closer to C/C++ than to Python/Ruby.
The PyPy project has been saying this all along, in fact - that to make dynamic languages fast, you can't just implement them in the JVM or such and expect 'magic' to happen with that VM's JIT. It doesn't work that way. Even if you JIT an architecture that does hash table lookups or type checking for each assignment, performance will be poor; the JIT can't fix your algorithm. Fixing the algorithm is exactly what latest-generation Javascript engines like V8 and TraceMonkey do.
No need to be insulting.
Ok, it seems you are right, this does allow limited reverse engineering of the non-LGPLed app, in order to see how it works with the LGPLed library. This might scare GPL-averse companies, in theory, that's a valid point. But hopefully it won't.
Yeah, didn't see that did ya? Almost every boiler plate EULA includes a clause prohibiting reverse engineering
It is my understanding that you can reverse-engineer the LGPLed library, but nothing else. And that isn't much of an issue: the LGPLed part should come with the complete source (or equivalent), so being able to debug/disassemble binaries for which you have the source isn't a big deal. In fact the purpose of this clause (again, to my understanding) is simply to be able to ensure that the source of the LGPLed library indeed corresponds to the binary of said LGPLed library.
So yes, EULAs might need to change - good point. But the change should only be "you can reverse-engineer the LGPLed library X, but nothing else," and that would appear after "you can get the source code to the LGPLed library X from here."
Bottom line, if you are ok with using an LGPLed library - and many otherwise GPL-averse corporations are - then this should not be an issue.
Yes, it's almost as if Nokia read my post from last week and took my advice ;)
People are probably just buying laptops...
Possibly. But my desktop is 5 yo and Mrs Smidge's desktop is going on 10...! The reason? We don't game, just appliance the heck out of it. No need to upgrade. Same thing with our vehicles, we just fix 'em and take xtra care with preventive maintenance.
=Smidge=
Very sensible, and the economic crisis is pushing more and more people to be like you.
Tech-wise, this crisis is going to put the most pressure on those companies whose fortunes are tied to computer sales, as opposed to use. Microsoft and Intel are the best examples of the former - almost every computer sold includes a Microsoft OS (+Office) and an Intel processor (+supporting chips). Fewer sales means that, for the first time in the history of both companies (except perhaps their very early years) they may experience significant declines in revenue and possibly even losses (the latter might be avoidable through layoffs - which we have been hearing are in the works).
Google is the best example of the latter type of company, whose fortune is tied to use. Simply put, that people use an old machine as opposed to a shiny new one doesn't matter to Google, as long as that machine can show ads on google.com. Looking at it another way, even a steep decline in computer sales doesn't mean fewer eyeballs on ads - just that those eyeballs are using older machines to see those ads. It's not like people are going to stop using the web. Now, clearly the economic crisis won't be all roses for Google - ad budgets are down, which will hurt. But overall, I'd say the model of tying yourself to computer sales - which worked well through forced upgrades - is finally (and deservedly!) under serious pressure, and Google and Google-like companies will benefit in comparison.
Companies sell, eg transfer, software developed with Qt all the time, it's what is made for after all. Obviously the license allow it.
Not what I meant by 'transfer'. You can copy the software, but not transfer the license. In other words, you can distribute your product, but others are not free to fork your product and redistribute it. The forkers would need to purchase a license as well.
No need for GPL, you can freely use Qt with a wide range of open source licenses like Apache/BSD/etc Please check your facts. http://doc.trolltech.com/4.4/license-gpl-exceptions.html [trolltech.com]
I am aware of this, but not entirely sure about what it means. After all, you can already link GPL code with BSD code (that's how the BSDs use ext2/3 code, for example). That's because the BSD license is compatible with the GPL, which means BSD can be relicensed to GPL - the overall project is then considered as GPL. The same is true for almost all the licenses in the list there (except perhaps for Apache, last I heard).
In other words, at worst Google would need to GPL the entire app. But even so they could dual-license their own code, under the GPL and the BSD, so they could still say the code was BSD in a sense. And at best, they could just release it under the BSD, as it's compatible anyhow. Yet, in both cases they are releasing a product with a lot of GPL code in it - Qt itself - which means it can't be forked in a non-GPL manner (there are other implications as well). This is something that I believe Google wants to avoid when possible. With the Linux kernel, it isn't avoidable - there is no replacement. But GTK is a respectable replacement for Qt, and isn't GPL (it's LGPL). The same thinking goes on in a lot of other places, leading to high adoption rates for GTK. Again, Nokia can stop this, and I wish they would, simply by relicensing Qt under the LGPL.
If I were Google (that is a great sentence) I would base it on QT 4. Fast, customizable, cross-platform, modern and integrated with WebKit.
Qt is nice, but its licensing prevents Google from using it in this way. To use Qt, Google would need to either pay for a license, but it wouldn't be transferable to others, or Chrome would need to be GPLed. Google goes to great effort to license it's code under the Apache/BSD/etc. licenses whenever possible, as it considers this better for it's business (and that's a reasonable position to take).
Until Nokia relicenses Qt to something like the LGPL - many of us would welcome that! - GTK will remain the library of choice in situations like this.
The video is from almost two years ago. Back then, Git and Mercurial really were the main options.
I always though bzr had the edge on git in terms of being a better DVCS. Is there a reason why the article seems to think that git is the default?
No such thing as 'better' here.
Bazaar was the runner-up DVCS, and rightfully so, but it has both advantages and disadvantages. Git is faster and currently more popular. Bazaar has an easier interface, better GUIs, is more easily extensible (Python), and runs better on non-Linux platforms.
So which you prefer is a matter of what you are looking for.
I've seriously never understood the classical religious position on this stuff. I don't believe it would take a God to steer evolution; based on all available evidence, it would take a God to stop it.
Please don't mistake the ramblings of a minority of fundamentalists for the 'classical religious position'. For example, the catholic church officially recognizes the validity of evolution. Most intelligent religious people do as well, and many scientists are religious.
To make glow in the dark yogurt that responds to melamine would be fairly simple if you had the right set of genes: a melamine sensor that, when bound to melamine, binds to a specific DNA sequence (a promoter) that drives expression of a fluorescent protein such as green fluorescent protein ("GFP", a widely used fluorescent marker derived from a jellyfish). It's not difficult, and it's not unsafe
I think the question is, unsafe for *what*? Maybe a glow-in-the-dark yogurt would be edible, which is what you focus on. But consider for example a glow-in-the-dark weed. Perhaps by some fluke this weed will survive better than other common weeds, e.g. because some parasite is turned off by the glowing. We might end up with our entire environment full of these glowing weeds, instead of our normal ones. This might end up good, or bad, for insects/pets/etc., and at the least will be somewhat disconcerting.
If this sort of thing does ever become so easy that people can do it in their garages, we'll eventually have problems like these, I suspect.
The team discovered that the HSV1 DNA is located very specifically in amyloid plaques: 90% of plaques in Alzheimer's disease sufferers' brains contain HSV1 DNA, and most of the viral DNA is located within amyloid plaques. The team had previously shown that HSV1 infection of nerve-type cells induces deposition of the main component, beta amyloid, of amyloid plaques.
100% might have been a clincher. If anti-virals help, I might have rto eat my worlds.
Most people have HSV1. HSV1 DNA locates in the amyloids. So most people expressing the amyloids would have HSV1 DNA in them.
What's up with the 10% of alzhemier amyloids without the HSV1. It sounds like amyloid metabolism is the problem and HSV1 is along for the ride.
That's possible. Further research is needed. However, 90% is still suggestive enough to motivate future research, consider for example the case of HPV, which is now well-known to cause cervical cancer (and a few others). The initial results were much the same as these: 90% or thereabouts of tumors contained HPV DNA.
So this is a promising starting point, but of course only time and future work will tell whether it is an actual causal factor.
Ah, it's even worse. A person might have no history of symptoms but still be infected, and have asymptomatic shedding. So it makes little sense to inquire about a history, at least as far as asymptomatic shedding is considered (you might inquire for other reasons).
That said, it still makes sense to avoid sharing food, kissing, etc. people who have active symptoms. The amount of virus particles is much, much higher than asymptomatic shedding in such a case.
But otherwise, there isn't much you can do.