Why does this crap get posted? I'd venture that most of the/. readership are out-and-out geeks who give less than half a rat's ass about marketing hoo-ha. If you're gonna post a story about the new iMac, why not talk about the obvious technical superiorities: Altivec (leaves MMX in the dust at over a gigaflop), full vector graphics, a solid BSD kernel, fully pluggable filesystems, etc. etc.
From above, a whopping 1.2 gigabytes of aggregate data could
potentially cross everyone's networks, just to relay an 18 byte search
query. This is of course where Gnutella suffers greatly from being
fully distributed.
Actually, I think the RIAA suffers more, since there's no one to sue.
The moon's orbit varies by far more than 1 millimeter all the time. There are all sorts of influences, including the earth's gravity, the sun's gravity, Jupiter's gravity -- as well as factors that will introduce error into the measurements, such as refraction of the laser in the earth's atmosphere.
Therefore, by measuring the distance to an accuracy of a millemeter, we might be able to gain some insight about: earth's gravity, the sun's gravity, and Jupiter's gravity. The point of this experiment is not to know how far it is to the moon. The point is to better understand the moon's orbit, and the various influences which affect it.
I'd have to say one of the cooler things happening more and more, and something you might want to think about playing with, is mouse gestures. The user makes a certain gesture with the mouse pointer to trigger a certain action. The Opera web browser does this, and it comes in fantastically handy. While holding the right button down, drag left and release. This is the "back" function. Dragging right instead goes forward. Right-left-right kills the current frame. Down, and you open a new frame.
I've found that these gestures decrease my command-time by a huge amount. I'm navigating all over the place without moving more than 50 pixels in any direction!
The actual technology they are using isn't mentioned in the article, but I have a hunch it is some form of field emission. This is the same principle used in electron microscopy. A narrow emission tip is placed in a large potential gradient (electric field), and the electrons simply tunnel out of the tip. Their secret is probably the material the tip is made of: different materials have widely different tunneling rates.
The article brings up a good point. Using thermoionic emission (as is done now) is a little outdated and almost barbaric:)
Hasn't anyone noticed...
on
Bionic Eyes
·
· Score: 2
that they don't say anything whatsoever about how they are going to hook this device up to the optic nerve? Without that, everything is for nothing. Do they really know how to do this? If so, why wasn't it mentioned in the article? If not, why was the article written at all?
Here's some simple physics to show why this idea is great. If a force acts between two bodies, one of mass M1 (the spacecraft) and one of mass M2 (the exhaust gas, or in this case, the earth and launcher), then the energy efficiency of the process is M2 / (M1 + M2). In other words, the more massive the launcher, the more efficient the launch. (For physicists in the audience, I will get into detail if you wish.)
Consider a gas-exhaust rocket. Say that the rocket has a mass of 1000 kg and the fuel has a total mass of 100 kg (don't know if it's realistic, just an example). The efficiency of this process (neglecting heat losses) is 100 / (1000 + 100) = 0.091 = 9.1%. Now, consider the earth/launcher system, with enormous mass compared to the spacecraft. The efficiency of this process is M2 / (M1 + M2) where M2 is a huge number compared to M1. This efficiency is close to 1, or 100%!
What this means is that the vast majority of the energy you put in ends up accelerating the craft. This is opposed to the gas-exhaust system where only 9% of the energy goes into the spacecraft -- the remainder is carried away in the exhaust kinetic energy.
During my company's battle with Tumbleweed, we looked long and hard for prior art. We found none. Their patent is very carefully worded so as to exclude any of the prior art. Some previous projects come close to the patent description, but none seem to match it.
We were screwed, and had to change our design. I hate these assholes.
Tumbleweed are real bitches. My company (I won't name it) had to deal with them a year ago. We were constructing a secure document delivery system with notification, etc. All the cool features. Well, our original idea turned out to be covered by TW's patent, so we had to do some things ass-backwards in order to stay free and clear. As a result our product doesn't operate as cleanly as it should, but at least we don't have the assholes at TW breathing down our necks. We're a smaller company and can't afford to license it.
The patent in question seems to be the same one mentioned in this article. It's one of their older patents, at least two years old I think.
Thanks for your reply. I was under the impression that MITSHM supported shared memory images, but that shared memory pixmaps were something different. Thanks for clarifying, I'll have to look into that!
As for GLX... Haven't played with it, now I will.
Finally, I must disagree about the UNIX socket. 5*10^-4 seconds seems short, but if that is the time it takes to draw several pixels (assuming the draw requests are buffered in Xlib), then you are in trouble. In that amount of time, a 500 MHz CPU goes through 250,000 cycles. Imagine how many pixels you could draw into a framebuffer in that amount of time...
You're right in the general case, but there are a few areas where X has difficulty:
The protocol is unavoidable overhead: even if client and server are running on the same host, a call to, for example, XPutPixel() still has to pack a protocol request and send it over a UNIX socket, where it is then unpacked, validated, and executed. This is tremendous overhead for something as simple as drawing a single pixel on the screen. If you're in the business of drawing pixels at a time, you probably want to use your own drawing routines, an X image, and a double-buffered window. However, doing this is a pain:
Double-buffering is tricky to implement, and can be slow. Unless your server supports shared-memory pixmaps, in order to do double buffering you must:
Allocate an X image of the appropriate size and depth.
Draw the contents of the back-buffer onto the image using your own routines.
Translate the image into a pixmap.
Blit the pixmap to the window.
Repeat from step 2.
This process can be very slow.
Basically, X is great for usual GUI applications, but if you want to do something like, for example, an xmms plugin, you are incurring much overhead as opposed to direct access to some type of framebuffer device.
The 150 KW is a gain, regardless of how small. Before, they simply burned the CH4 since it is a greenhouse gas, and CH4 is much worse than CO2 in terms of warming potential. At least this way they are getting something out of it.
On the flip side, since these signals would require massive antenae, you can triangulate the source in a matter of seconds, and send some guys (cops, navy, army, etc) over to shut them down.
Actually it wouldn't be quite so simple. A directional antenna doesn't spill much, and a good directional antenna hardly spills at all. Remember, the radio beam is directed into space, not overland. Triangulation is used for locating omnidirectional point sources, not small-angle beams.
I suppose they might be able to work with the signal reflected from the ionosphere, but it would be very weak, phase shifted out of recognition, polarized out of recognition, etc. It certainly wouldn't be easy, and perhaps impossible.
A matter of perspective - my only major gripe with gnome is that its API re-invents the wheel over and over (C is not an object-oriented language, and gtk's attempt at emulating an object oriented language just isn't as good as the real thing, IMO).
Exactly. The biggest problem, I think, is that calling a method is done differently depending on whether that method is virtual. If object Z has standard method A and virtual method B, then to invoke A you must say A(Z), but to invoke B you must say Z->B(Z). This disparity is ugly and would be solved by using C++ which they should have done in the first place.
The city of Portland, Oregon has had a large methanol fuel cell for a few years now. It produces about 150 kilowatts and runs off methanol converted from methane released from landfill gas. In the past the excess gas was flared off but it is now collected and used to power the cell.
The interesting thing about this device is its incredibly small size.
This is terribly OT, but I'm hung-over, in a bad mood, and I think you're hilarious, so here goes:
You've learned about computers completely backwards. You downloaded "toolz," then wrote "nukes" and "game cheaters" and you somehow think this qualifies you as a "programmer?" You're kidding yourself.
Don't you realize that you'll be slaving in some code-shop for the rest of your life? Don't you ever want to do anything exciting? Why not go to school and do the work and actually get a clue about what is going on with computers.
Do you know what a red-black tree is? How about a context-free grammar? What is Chomsky normal form? For that matter what is conjunctive normal form? Can you describe the LALR algorithm? How about operator precedence parsing? What is the difference between a synthetic attribute and in inherited attribute? What does TLB stand for, and what does it do? What is the meaning of the term "re-entrant?" Why would a fully re-entrant Linux kernel kick ass? What would be difficult about doing it? What is the meaning of the term "cryptographically secure hash?" Describe alpha-beta game-tree pruning. How about STRIPS planning? Go and implement a backprop neural network with weight decay and momentum. Tell me the time-complexity of the last algorithm you wrote. And finally, what does it mean for a problem to be NP-complete?
Look, this is not Ancient Lore known only to the oldest and wisest code-wizards. This is stuff that every CS graduate, even from the crappiest school in the country, knows. Without this sort of knowledge you'll just be another code-monkey.
That isn't exactly what they are doing here. The gravitic maps of Earth show how the static G-field varies as a function of latitude/longitude. What they are attempting to measure here are dynamic variations in the background G-field due to the propogation of gravitational waves. These waves are generated by accelerating masses in the same way that accelerating charges radiate electromagnetic waves. For instance a black hole and a star orbiting each other will emit G-waves, and by doing so lose orbital energy.
"Screw around with a while loop?" What is so screwy about it? What is so hard to understand about this:
for(;;) {
status = select(...);
if(state != EINTR)
break;
}
Don't bitch about branch optimization. That select() call is trapping into kernel mode. Who cares about a branch in the face of that?
Your second situation makes more sense. I usually never have loops nested that deep, though. The only time I really use goto is for progressive unrolling after error:
Of course these unrolling sequences can be much longer and more complex. It's really the best you can do in a language that has no exceptions. In C++ you would use exceptions and destructors for this.
KDE startup times depend heavily on the performance of the dynamic linker. This issue has been discussed at length in the KDE community for some time now. Some solutions have been proposed and put into effect (e.g., kdeinit). Don't blame KDE for these problems. Any C++ application that is dynamically linked to many C++ libraries will suffer the same slow startup times. This is an issue with the dynamic linker, not with KDE.
I didn't mean that the trajectory is parabolic. I meant that the equation which describes the position of the missile (under the influence of a thruster) after some given amount of time is quadratic: x(t) = 1/2*a*t^2+v*t+x0.
Yes, this does not account for the fact that the missile's mass is changing as the fuel is consumed. I don't feel like working it out right now but that also has a closed-form solution if you assume that the fuel is burned at a constant rate.
I really don't understand all the responses to my post: I was merely pointing out that when one is writing a freaking video game, it is a waste of time to use such methods to perform accurate physical simulation. How does a "flat earth," or "intercontinental ballistics" have anything to do with space missiles?
Really, who cares? Those companies smart enough to be running Linux already know its capabilities and strengths (and yes, its weaknesses). They don't need Microsoft to tell them what to do, and they don't listen to bullshit like this. Recently, the president of my company came to be and said: "I don't want to use AIM anymore. I already have to run enough of Microsoft's crap. What can we do around here that runs in Linux?" Immediately I suggested IRC, and since then we've had a company IRC server for the engineers and tech support folks to chat on.
Most mid- and upper-level managers who end up choosing Linux are intelligent people, and they chose Linux because they see the light. For people stuck working at companies where the management are idiots, that's just too bad. Deal with it.
To the companies who chose Linux over the past years: way to go! Keep ignoring MS, as it should be.
To those companies who actually buy this FUD: I'll laugh when you vanish into extinction.
In this case, the joystick is essentially controlling acceleration of the spaceship, through the forces created by the thrusters.
Ok. Well, I had taken this part somewhat as a given. "Press left go left" is so simplistic I hadn't even thought of it. I've written a few space shooters (with graphics so bad I'm embarrassed to mention it), and the various objects in the universe were modelled with the following properties: mass, velocity (vector), position (vector), angular momentum (vector), moment of rotational inertia (assumed to be isotropic). Spacecraft in this model have linear thrusters that can change the linear momentum -- i.e., they produce a force line that passes through the center of mass. They also had rotational thrusters which provided torque (force line perpendicular to center of mass). In fact all forces were calculated relative to the center of mass. Projectiles impacting the spacecraft produced linear and angular accelerations which were quite easy to compute. To be more complex than that seems like a waste of time.
I never ran into problems with this method. I integrated four times per frame, and it worked quite well. Actually, I've never played a space shooter that really took account for angular momentum. Once you got spinning out of control in my stupid little game, it was quite difficult to get back into a sane orientation:)
Do we need high-order simulation of planetary orbits in a space shooter? These attractors and other phenomena only emerge after immense periods of time -- much longer than the time periods in a typical game of blow-the-crap-out-of-Buster.
Not quite sure how to take your comment on my degree:) I'm also getting a degree in CS so it's a lot of juggling to be doing. I'm putting the priority on CS.
Slashdot Mirror
Why does this crap get posted? I'd venture that most of the /. readership are out-and-out geeks who give less than half a rat's ass about marketing hoo-ha. If you're gonna post a story about the new iMac, why not talk about the obvious technical superiorities: Altivec (leaves MMX in the dust at over a gigaflop), full vector graphics, a solid BSD kernel, fully pluggable filesystems, etc. etc.
From above, a whopping 1.2 gigabytes of aggregate data could potentially cross everyone's networks, just to relay an 18 byte search query. This is of course where Gnutella suffers greatly from being fully distributed.
Actually, I think the RIAA suffers more, since there's no one to sue.
Therefore, by measuring the distance to an accuracy of a millemeter, we might be able to gain some insight about: earth's gravity, the sun's gravity, and Jupiter's gravity. The point of this experiment is not to know how far it is to the moon. The point is to better understand the moon's orbit, and the various influences which affect it.
I've found that these gestures decrease my command-time by a huge amount. I'm navigating all over the place without moving more than 50 pixels in any direction!
The article brings up a good point. Using thermoionic emission (as is done now) is a little outdated and almost barbaric :)
that they don't say anything whatsoever about how they are going to hook this device up to the optic nerve? Without that, everything is for nothing. Do they really know how to do this? If so, why wasn't it mentioned in the article? If not, why was the article written at all?
Consider a gas-exhaust rocket. Say that the rocket has a mass of 1000 kg and the fuel has a total mass of 100 kg (don't know if it's realistic, just an example). The efficiency of this process (neglecting heat losses) is 100 / (1000 + 100) = 0.091 = 9.1%. Now, consider the earth/launcher system, with enormous mass compared to the spacecraft. The efficiency of this process is M2 / (M1 + M2) where M2 is a huge number compared to M1. This efficiency is close to 1, or 100%!
What this means is that the vast majority of the energy you put in ends up accelerating the craft. This is opposed to the gas-exhaust system where only 9% of the energy goes into the spacecraft -- the remainder is carried away in the exhaust kinetic energy.
We were screwed, and had to change our design. I hate these assholes.
The patent in question seems to be the same one mentioned in this article. It's one of their older patents, at least two years old I think.
As for GLX... Haven't played with it, now I will.
Finally, I must disagree about the UNIX socket. 5*10^-4 seconds seems short, but if that is the time it takes to draw several pixels (assuming the draw requests are buffered in Xlib), then you are in trouble. In that amount of time, a 500 MHz CPU goes through 250,000 cycles. Imagine how many pixels you could draw into a framebuffer in that amount of time...
- The protocol is unavoidable overhead: even if client and server are running on the same host, a call to, for example, XPutPixel() still has to pack a protocol request and send it over a UNIX socket, where it is then unpacked, validated, and executed. This is tremendous overhead for something as simple as drawing a single pixel on the screen. If you're in the business of drawing pixels at a time, you probably want to use your own drawing routines, an X image, and a double-buffered window. However, doing this is a pain:
- Double-buffering is tricky to implement, and can be slow. Unless your server supports shared-memory pixmaps, in order to do double buffering you must:
Basically, X is great for usual GUI applications, but if you want to do something like, for example, an xmms plugin, you are incurring much overhead as opposed to direct access to some type of framebuffer device.- Allocate an X image of the appropriate size and depth.
- Draw the contents of the back-buffer onto the image using your own routines.
- Translate the image into a pixmap.
- Blit the pixmap to the window.
- Repeat from step 2.
This process can be very slow.The 150 KW is a gain, regardless of how small. Before, they simply burned the CH4 since it is a greenhouse gas, and CH4 is much worse than CO2 in terms of warming potential. At least this way they are getting something out of it.
Actually it wouldn't be quite so simple. A directional antenna doesn't spill much, and a good directional antenna hardly spills at all. Remember, the radio beam is directed into space, not overland. Triangulation is used for locating omnidirectional point sources, not small-angle beams.
I suppose they might be able to work with the signal reflected from the ionosphere, but it would be very weak, phase shifted out of recognition, polarized out of recognition, etc. It certainly wouldn't be easy, and perhaps impossible.
Exactly. The biggest problem, I think, is that calling a method is done differently depending on whether that method is virtual. If object Z has standard method A and virtual method B, then to invoke A you must say A(Z), but to invoke B you must say Z->B(Z). This disparity is ugly and would be solved by using C++ which they should have done in the first place.
The interesting thing about this device is its incredibly small size.
You've learned about computers completely backwards. You downloaded "toolz," then wrote "nukes" and "game cheaters" and you somehow think this qualifies you as a "programmer?" You're kidding yourself.
Don't you realize that you'll be slaving in some code-shop for the rest of your life? Don't you ever want to do anything exciting? Why not go to school and do the work and actually get a clue about what is going on with computers.
Do you know what a red-black tree is? How about a context-free grammar? What is Chomsky normal form? For that matter what is conjunctive normal form? Can you describe the LALR algorithm? How about operator precedence parsing? What is the difference between a synthetic attribute and in inherited attribute? What does TLB stand for, and what does it do? What is the meaning of the term "re-entrant?" Why would a fully re-entrant Linux kernel kick ass? What would be difficult about doing it? What is the meaning of the term "cryptographically secure hash?" Describe alpha-beta game-tree pruning. How about STRIPS planning? Go and implement a backprop neural network with weight decay and momentum. Tell me the time-complexity of the last algorithm you wrote. And finally, what does it mean for a problem to be NP-complete?
Look, this is not Ancient Lore known only to the oldest and wisest code-wizards. This is stuff that every CS graduate, even from the crappiest school in the country, knows. Without this sort of knowledge you'll just be another code-monkey.
That isn't exactly what they are doing here. The gravitic maps of Earth show how the static G-field varies as a function of latitude/longitude. What they are attempting to measure here are dynamic variations in the background G-field due to the propogation of gravitational waves. These waves are generated by accelerating masses in the same way that accelerating charges radiate electromagnetic waves. For instance a black hole and a star orbiting each other will emit G-waves, and by doing so lose orbital energy.
"Screw around with a while loop?" What is so screwy about it? What is so hard to understand about this:
...
for(;;) {
status = select(...);
if(state != EINTR)
break;
}
Don't bitch about branch optimization. That select() call is trapping into kernel mode. Who cares about a branch in the face of that?
Your second situation makes more sense. I usually never have loops nested that deep, though. The only time I really use goto is for progressive unrolling after error:
mem1 = malloc(10);
if(!mem1) goto fail_mem1;
mem2 = malloc(10);
if(!mem2) goto fail_mem2;
fail_mem2:
free(mem1);
fail_mem1:
return -1;
Of course these unrolling sequences can be much longer and more complex. It's really the best you can do in a language that has no exceptions. In C++ you would use exceptions and destructors for this.
Solutions to the problem are in the works:
objprelink
ELF prelinking by Jakub Jelinek
See a discussion on why Gnome is having similar problems
x(t)=(b^2*(v0*t+x0)+F*(b*t+(ln(M/(M-b*t)))*(b*t-M) ))/b^2
Where F is the constant force produced by the thruster and b is the rate of fuel burn in kg/s.
Yes, this does not account for the fact that the missile's mass is changing as the fuel is consumed. I don't feel like working it out right now but that also has a closed-form solution if you assume that the fuel is burned at a constant rate.
Most mid- and upper-level managers who end up choosing Linux are intelligent people, and they chose Linux because they see the light. For people stuck working at companies where the management are idiots, that's just too bad. Deal with it.
To the companies who chose Linux over the past years: way to go! Keep ignoring MS, as it should be.
To those companies who actually buy this FUD: I'll laugh when you vanish into extinction.
Ok. Well, I had taken this part somewhat as a given. "Press left go left" is so simplistic I hadn't even thought of it. I've written a few space shooters (with graphics so bad I'm embarrassed to mention it), and the various objects in the universe were modelled with the following properties: mass, velocity (vector), position (vector), angular momentum (vector), moment of rotational inertia (assumed to be isotropic). Spacecraft in this model have linear thrusters that can change the linear momentum -- i.e., they produce a force line that passes through the center of mass. They also had rotational thrusters which provided torque (force line perpendicular to center of mass). In fact all forces were calculated relative to the center of mass. Projectiles impacting the spacecraft produced linear and angular accelerations which were quite easy to compute. To be more complex than that seems like a waste of time.
I never ran into problems with this method. I integrated four times per frame, and it worked quite well. Actually, I've never played a space shooter that really took account for angular momentum. Once you got spinning out of control in my stupid little game, it was quite difficult to get back into a sane orientation :)
Not quite sure how to take your comment on my degree :) I'm also getting a degree in CS so it's a lot of juggling to be doing. I'm putting the priority on CS.