I don't know how this technology works, but I can also imagine they may take several pictures with a normal CCD, with the lens going through a series of steps. Then in software, they may recombine the images, and compensate for the long shutter time by some kind of smart algorithm that tries to compensate for movement.
Web browsers are getting too damn complex. Why are we not using a simpler architecture?
Such as:
1. browser receives byte-code instead of HTML 2. security checks are performed on the byte-code 3. byte-code is translated (compiled) to machine code (LLVM engine) 4. checks are performed on the machine code (like NaCl's project) 5. machine code interfaces with OpenGL like layer for basic graphics and video 6. on top of that, a renderer is implemented in byte-code
Advantages:
1. Very secure, because of multiple layers of isolation. 2. Very secure, because code complexity is reduced at all levels (number of byte codes is small, javascript+html are much more complex) 3. Much easier to reach compliance between browsers (byte codes are much simpler). 4. Developers could use different languages than HTML and Javascript. 5. Heck, developers could even implement their own rendering engine. 6. Open-source developers could independently implement more interesting (and more efficient) applications/libraries. 7. Developers not wishing to dive into binary development could still use pre-made rendering engines.
Why not?
-- Moving to Madrid in 93 days! Place your bid on my old IP address!
I'm not sure about a browser-based OS, but here's what I think will happen to browsers:
1. Developers are annoyed by having to design their website/webapp for 5 different browsers. 2. Also, developers are annoyed by using javascript and HTML, and not their favorite languages. 3. Open-source developers create tools that compile from any language into javascript+HTML. 4. Developers and users complain about speed. 5. Developers start targeting google's NaCl platform. 6. Other vendors adopt NaCl. 7. But there's still HTML. Developers are still annoyed by differences between HTML implementations. 8. HTML gets more complex. Implementations grow even more apart. Developers go crazy. 9. Open-source developers start creating a rendering engine that runs on NaCl. 10. NaCl runtime api improves. Various open-source rendering engines will now run on NaCl. 11. Websites/webapps will include their own favorite rendering engine. 12. Caching techniques in the browser will prevent network overload. 13. ? 14. Profit!
(prediction could be slightly off, because I'm typing this at around 3:00 AM local time)
Just give us a good OpenGL-like API and a bytecode environment, with a JIT compiler, and open-source will build its own browser environment.
HTML5 is too complex to be used as a cross-platform application deployment tool.
Software needs to be built in easy to understand layers. And HTML5 just gives us one enormous complex and opaque layer. This is not how software should be built!
Just give us a bytecode environment, and if we want to, we'll build HTML5 on top of it, or we might choose our own rendering layer. But the choice should be the developer's.
Unfortunately, many programmers overlook the fact that, even in a completely memory managed environment, it is still very much possible to produce memory leaks. Maybe even more so because these programmers are not trained to think about memory management.
For example, in any language with automatic garbage collection, allocate an array, fill it up with 100MB worth of data, and then store the reference to the array somewhere in a global object. If you forget about that reference, well, there you go: a memory leak!
It amazes me how the whole computing community, including computer scientists and programmers, are being kept hostage by a small group of people who enforce their rules upon them (not only the Microsofts, Apples and Adobes of this world, but also standardization committees such as W3C).
While those ATMs are getting more and more sophisticated at detecting who WE are, us users are still often in doubt about the "identity" of the MACHINE. "Is it really the bank we are interacting with, or is it a skimming machine (or both)?"
Yes, but why don't browsers offer us a simple binary platform? The open-source community could then develop compilers for any domain-specific language we want. We could then even implement our own version of HTML and CSS.
I think W3C has done a good job, but they are unintentionally keeping us, (open-source) developers, hostage.
So it's like finding out information about a car by blindly throwing other cars at it and measuring the collision: you're gonna affect the thing you're measuring by the act of measuring it.
The point was that you could detect the position of the car by using much lighter objects (or objects with less energy), e.g. ping pong balls, and by deducing the position of the car from the interference pattern.
it would be more useful to improve existing open source VOIP clients so Skype can be replaced altogether.
As you know, for performing a telephone call, you need 2 ends. Try convincing the other end to install your open-source VOIP client of choice!
That's the problem!
IMHO, a much better approach against such lock-in would be to first develop an open-source binary compatibility layer inside web-browsers, like google is doing with native client (NaCl). That way, you could make a phone call by asking the other party to visit a website (assuming you have written your phone client software for that binary compatibility layer of course).
So, as I understand it, the uncertainty principle tells us that in order to determine the position of a particle, we'd have to make a photograph of it using a sufficiently high frequency of light, otherwise we'd get a severe interference pattern. However, this high frequency of photons is coupled to high energy, thus knocking the original particle out of its path (in other words changing its momentum). So far so good.
However, assume that the particle is perfectly symmetric, e.g. a sphere. Then the interference pattern will also be symmetric. The image we'd get by making a photograph would look like a bunch of concentric circles. Where is the original particle? Well, at the center of those cirlces of course!
So this is what I don't understand. We can actually deduce the position of the particle precisely from the interference pattern. So where is all the fuzz coming from?
Slashdot Mirror
Who cares about not being able to open your old files.
This software is made by Apple and looks very shiny and it's very hip. Whenever I want to make my friends jealous, I just open it up.
I don't know how this technology works, but I can also imagine they may take several pictures with a normal CCD, with the lens going through a series of steps. Then in software, they may recombine the images, and compensate for the long shutter time by some kind of smart algorithm that tries to compensate for movement.
For making movies, this would be very useful. Because when taking a movie, it is generally quite difficult to keep focus.
Isn't it possible to orthogonalize the space? For printing we need only 3 primary colors (or 4 if you count black).
Wouldn't it be possible to get a similarly small set of "primary odors"?
Web browsers are getting too damn complex. Why are we not using a simpler architecture?
Such as:
1. browser receives byte-code instead of HTML
2. security checks are performed on the byte-code
3. byte-code is translated (compiled) to machine code (LLVM engine)
4. checks are performed on the machine code (like NaCl's project)
5. machine code interfaces with OpenGL like layer for basic graphics and video
6. on top of that, a renderer is implemented in byte-code
Advantages:
1. Very secure, because of multiple layers of isolation.
2. Very secure, because code complexity is reduced at all levels (number of byte codes is small, javascript+html are much more complex)
3. Much easier to reach compliance between browsers (byte codes are much simpler).
4. Developers could use different languages than HTML and Javascript.
5. Heck, developers could even implement their own rendering engine.
6. Open-source developers could independently implement more interesting (and more efficient) applications/libraries.
7. Developers not wishing to dive into binary development could still use pre-made rendering engines.
Why not?
--
Moving to Madrid in 93 days! Place your bid on my old IP address!
Does it run on fossil fuel? If so, then this tech will only last until we run out of this fuel.
I think we need something that can fly on electricity.
I'm not sure about a browser-based OS, but here's what I think will happen to browsers:
1. Developers are annoyed by having to design their website/webapp for 5 different browsers.
2. Also, developers are annoyed by using javascript and HTML, and not their favorite languages.
3. Open-source developers create tools that compile from any language into javascript+HTML.
4. Developers and users complain about speed.
5. Developers start targeting google's NaCl platform.
6. Other vendors adopt NaCl.
7. But there's still HTML. Developers are still annoyed by differences between HTML implementations.
8. HTML gets more complex. Implementations grow even more apart. Developers go crazy.
9. Open-source developers start creating a rendering engine that runs on NaCl.
10. NaCl runtime api improves. Various open-source rendering engines will now run on NaCl.
11. Websites/webapps will include their own favorite rendering engine.
12. Caching techniques in the browser will prevent network overload.
13. ?
14. Profit!
(prediction could be slightly off, because I'm typing this at around 3:00 AM local time)
Will it also be the end of paginated layout?
Just give us a good OpenGL-like API and a bytecode environment, with a JIT compiler, and open-source will build its own browser environment.
HTML5 is too complex to be used as a cross-platform application deployment tool.
Software needs to be built in easy to understand layers. And HTML5 just gives us one enormous complex and opaque layer. This is not how software should be built!
Just give us a bytecode environment, and if we want to, we'll build HTML5 on top of it, or we might choose our own rendering layer. But the choice should be the developer's.
Well, now you understand where their hunger for more speed comes from.
And those banks will not pass the extra development costs on to their customers?
Those companies will just make it part of the EULA, which you'll have to accept anyway to use the app.
Unfortunately, many programmers overlook the fact that, even in a completely memory managed environment, it is still very much possible to produce memory leaks. Maybe even more so because these programmers are not trained to think about memory management.
For example, in any language with automatic garbage collection, allocate an array, fill it up with 100MB worth of data, and then store the reference to the array somewhere in a global object. If you forget about that reference, well, there you go: a memory leak!
Well this sounds similar to the kind of tricks Apple is pulling with its anti-competitive price-policies in the app store.
I thought Apple was the company doing all the innovation.
As long as javascript does not have strong typing, I don't think anybody will consider it a valid replacement for .NET languages.
if Apple continues to force their lock-in strategies upon their users, there will be a day when customers will unionize against Apple.
It amazes me how the whole computing community, including computer scientists and programmers, are being kept hostage by a small group of people who enforce their rules upon them (not only the Microsofts, Apples and Adobes of this world, but also standardization committees such as W3C).
Just wow.
While those ATMs are getting more and more sophisticated at detecting who WE are, us users are still often in doubt about the "identity" of the MACHINE. "Is it really the bank we are interacting with, or is it a skimming machine (or both)?"
Well, that condition is just part of the EULA, I guess. Or did you actually read it?
Yes, but why don't browsers offer us a simple binary platform? The open-source community could then develop compilers for any domain-specific language we want. We could then even implement our own version of HTML and CSS.
I think W3C has done a good job, but they are unintentionally keeping us, (open-source) developers, hostage.
Sure. Its main application is an insomnia treatment for mathematicians.
So it's like finding out information about a car by blindly throwing other cars at it and measuring the collision: you're gonna affect the thing you're measuring by the act of measuring it.
The point was that you could detect the position of the car by using much lighter objects (or objects with less energy), e.g. ping pong balls, and by deducing the position of the car from the interference pattern.
it would be more useful to improve existing open source VOIP clients so Skype can be replaced altogether.
As you know, for performing a telephone call, you need 2 ends. Try convincing the other end to install your open-source VOIP client of choice!
That's the problem!
IMHO, a much better approach against such lock-in would be to first develop an open-source binary compatibility layer inside web-browsers, like google is doing with native client (NaCl). That way, you could make a phone call by asking the other party to visit a website (assuming you have written your phone client software for that binary compatibility layer of course).
So, as I understand it, the uncertainty principle tells us that in order to determine the position of a particle, we'd have to make a photograph of it using a sufficiently high frequency of light, otherwise we'd get a severe interference pattern. However, this high frequency of photons is coupled to high energy, thus knocking the original particle out of its path (in other words changing its momentum). So far so good.
However, assume that the particle is perfectly symmetric, e.g. a sphere. Then the interference pattern will also be symmetric. The image we'd get by making a photograph would look like a bunch of concentric circles. Where is the original particle? Well, at the center of those cirlces of course!
So this is what I don't understand. We can actually deduce the position of the particle precisely from the interference pattern. So where is all the fuzz coming from?