Important question: Had he used Windows before GNOME?
I only ask because the skills learned in Windows are easily portable to any current GUI, and visa versa. I personally believe that I could sit down at any computer and figure out the GUI, but then again I was like this when I first started using computers with Windows 3.1 on them. So it's really important to look and see how GUIs are alike and how they are different.
Today, the main functionality of a GUI is virtually the same in any operating system, under any Windows Manager (minus a few frenge ones...); we are getting to the point that we are "desktop-agnostic". The only thing that remains in Linux is to get video accelleration up to Windows/MacOS X levels, and once there, start sprucing everything up with a bit of eye candy (drop shadows rock eye-candy wise, fast window transforms like in Mac OS X, etc). But I do have to admit that Linux, at current, is far more themeable than either Windows XP or Mac OS X, and I believe it will probably remain that way for a long time... (bad for new users, good for established users).
I don't think the Pentium M (basically a pentium 3 with a lot of p4-based enhancements) is bus-compatible with the Pentium 4 (lest we would be seeing PM-based desktop boards flying off the mills).
To the second question: Nobody in the open source world.
Microsoft's on the way to doing it, and there was a small project that existed for a few months that allowed GNOME to access a database as a file system (It was very nasty; involved a kernel patch (a CORBA orb) that nobody was too happy about, so the project never took off.)
I've thought about the problem a few times. It requires the kernel pass information back to user space, unless the database was actually incorporated into kernel space (and that won't blow over well for a number of reasons). Passing the data back to user space requires a messaging system. The problem is, there are very few messaging systems out there designed specifically for kernelspace-userspace communication. CORBA was one developers answer; my answer would to be to ground up a protocol (because I feel that a network messaging solution, i.e. TCP/IP, can't be secured well enough in the long run).
Lastly, a daemon needs to exist to listen to the calls from the kernel and interpret them into SQL. This could be built into the kernel itself, but once again you have to question the security of the kernel building an SQL query that would go directly to the database server. Also, one of the better parts about this daemon would be metadata extraction; since the daemon is virtually transparent to both the user and the database server, the metadata can be completely ripped from the data and stored in a seperate table to allow for much faster, more optimised searches. EXIF Tags can be copied from JPEGs, ID3 tags copied from MP3s, etc.
Ideally, the daemon would be pluggable, allowing for anyone's metadata extension to be added after compiliation, but I believe that it's important to have a functional system before having a featureful system.
If you'd like to talk more about it, I'm really open to the idea of finally having an SQL-based file system. A relational database file system is the future; if we get there before Windows, we can add yet another example of the speed of open source development.
Google's just trying to get their stock out there and in the news, any way possible. Kind of strange way of doing it since they could have won the lawsuit I'm sure, but still. This is very odd behavior from Google.
Shit... Always forget to use the preview button. Anyways...
I don't think they wanted to implement the whole command set, but since they had to, they did so as crudely as they could. I doubt they spent very much time trying to make this part of their chip fast; the same way they didn't try to make Itanium x86 emulation fast. The greater scheme of it all; they can say that this code is simply "flawed". Better than saying it, they can let people opinionate it ("hey, Intel's usually on top of the benchmarks.. there's gotta be something wrong with that code").
Too bad Netburst can't give them just a little more time.. I'd love to see either a dual-pentium m on-core chip, or even more nifty: a pentium m | pentium 4 on-core chip. Best of both worlds;).
I think the bigger part behind this is that Intel really didn't want to implement the whole AMD64 command-set. They just wanted to be "compatible enough". This is a defeat for Intel and they're not the kind of company that wants to own up to that. If worse comes to worse, they could ground up a X86-64 chip to compete, but I don't think they want to have to rely on it.
On the otherhand, Intel seems to be marketing these chips as a way to get more memory on your motherboard (aka the way Apple did at first, "Now you can have EIGHT gigs of ram instead of FOUR!!!"). They're hoping this will be enough for most people, considering where these chips will be marketed (low-medium range server).
Besides, Intel's said it plenty of times: Netburst is dying. It was a foolish hack in the first place, but at least it gave them enough time to breed the Pentium M into what it is today.
Most likely they'll continue to use phone numbers. It's too much of an investment to try to change the number system, and on top of that, it'd be much harder for a traditional telephone to call an IP number.
Basically, they're turning the voice data into packets and then sending the packets across their network, improving the effeciency of their lines. There's been a lot of discussion about this lately actually. Either way, I wish the american phone companies would get on the ball...
Because the human body can deal with the heat a lot better than the computer sitting on the lap can. That insulation is keeping the heat in the notebook.. I wouldn't be surprised if major laptop manufacturers voided warrantees due to the use of these pads.
hehe, old postits were a whole lot stickier, and it's aided by some tape.. the password's the local root password ( m30wm1x ) to a machine I'm not sure I even own anymore. It's stuck to my zenith low (ie, very high) radiation 14" monitor...
I've still got a three year old password on a postit note on the side of my monitor. It just goes to show you that passwords can sit anywhere.
The real question is, if a password's that old, what use SHOULD it still have? Hopefully, people adopt policies where they update passwords every month, or few months, especially if it's dealing with anything financial/uber personal (doctor's records.. etc).
Get real, stop trying to scare us with your security warnings; just educate people to change their passwords.
Anyone know where I can find decent information on the X protocol without druging through the source? I've been toying around with Y-Windows, and I've been wondering just how much work it'll take to make some kind of compatibility driver/subsystem.
I usually keep it as a policy not to respond to AC's; they don't have the balls to say it to my face, then it means nothing. But this time, I'm going to reply anyways.
Yes, there are cases where there will be no edges to find, but in those cases, it's usually okay to just keep trucking a-long. It's not just one technology that will win this race, it's the combination of all of them working together to solve a common problem.
As for speed, increasing the shutter rate of the camera, using multiple cameras, and faster computers deal with speed processing. The idea is to slowly ramp up speeds as it's safe, and the instant there's something in the way, begin to slow down and steer, noting the deviance against the path, and undoing it as soon as is convienient.
To end all, yes, the real world is different than the theoretical and the experimental world, but both worlds are based on the real world, and the rules are the same. Approximenting is what we usually do in the real world to make up for the inadaquacies of it. Since the world isn't perfect, neither can our machines be.
First of all I'd like to thank you for being so condesending.
Second of all, no, I'm not the first to invent, implement, design, or think about sensing. It's a _necessity_ for this project. All robots must be capable of this in order to complete the trek.
2D images to 3D mapping actually did work for me, though yes, I do know the limitations of it. My idea for the project would be to use many more cameras taking pictures one at a time at set intravals and from different angles and more or less do reverse raytracing to develop a 3D scene. While this is very computationally intensive, it does work. My webcams were Intel, and while they did provide pretty crappy pictures at time, it wasn't entirely impossible to use (though it was all I could afford). 3D scenes took about a minute to form on my P4 1.4 (willie) due to the degredation, and would often create objects based on hazy surfaces on the glossy desk I worked with.
Laser range finding I haven't had the pleasure to work with yet, but I do understand how it works, and do believe that it will add a key element to finding the best direction to take.
Acoustics will also be a great help; using above ground SONAR could be extremely useful at finding the differences between a rock and a bush; a rock will have a more dense auditory return and therefore will be detected as a rock, visa versa a bush will have a scattered return pattern, and not be as dense.
It's not like anything I'm saying here is revolutionary either. I'm simply stating that the technology is here, and we can make it work. I believe that we'll at least break the 100 mile mark next contest and that we would have last time too had the red car been better prepared.. I just don't believe the HumVee is a good platform.
The car's especially important because it has to be adapted for desert travel.. What we need is something that looks more like a kid's RC car, blended with a monster truck, and with a few installed tricks for dealing with mishaps and accidents: *flat tires automatic tire pressure balancing, possibly reinflating; a mechanism at the low points of the car where it may get stuck to push and get it back on driving sides, gyroscopes on board each wheel, the central vechicle, and a gyroscopic platform with the camera's mounted on them to maintain levels, etc*,. The car's really got to embody the spirit of James Bond, the intellegence of M, and the gracefulness of a tiger.
So no, none of my techniques are the holy grail. The grail is having them all come together perfectly.
Trust me, I understand that too, but that's when you have to get into surface approximentations and such. If a surface looks scattered like a clump of grass, then it's booleaned from a screen of black. The resultant image should be easy enough to pattern match to images of trees, rocks, brush, or anything else in a library. Dunno how well this would work in real-life, but this is what I did with my little toy model and it worked well.
Another way might be to test the density of the object, or to use color like we humans do.. If somethings green or yellow and sparce, it's more likely tumbleweed or a bush, otherwise it's a rock.
Lastly, at certain speeds, objects of certain sizes should be tossed out. If it's the size of a small mellon *smaller than a water mellon lets say*, then just throw the object out. It's not going to effect the car going at a speed of 35-65 MPH if the car's built right.
Just a few ideas. If I do get the chance to be in the project like I'm hoping, I'll get to test a few of them. Otherwise it's probably just idle chatter. Either way, it's something to think about.
I don't doubt it for a minute. Being a Florida Tech freshman in the fall, I want to try to get involved with this project. I've worked on stereo optics systems before using two webcams and I can tell you that this kind of system holds great promise at winning the race. In combination with great laser range-finding and possibly optical range finding (something like us humans do), even acustical systems, a machine has just as good of a chance to pilot a car as it can an aircraft or anything else.
Another thing: use the 2d images to build a 3d map on the fly, approximenting object sizes by finding the edges of the object in the pictures, and you should be able to navigate around and over them quite easily. The car also plays a key roll; it needs to be adapted into a dune buggy of sorts; huge soft tires and great suspension.
Scary that we're working on this for the government though..
Sure, but you could tie your little WiFi router into a satellite transceiver, launch a few satellites in geosync, and connect that way.
On that same point, we could use a lot of existing technologies to augment the Wireless revolution. Imagine converting an AM station (which DO have the kind of range) into a WiFi telephone system. Or even just using the antenna to get the kind of range. As for reliablity, battery backups, auxillary generators and solar power help. That helps with rural locations.
Slashdot Mirror
Yeah, well everyone's not giving away a free iPod 3rd gen when he (me) gets his fourth gen. ;)
(Yes, I know this post is very badly off topic).
Important question: Had he used Windows before GNOME?
I only ask because the skills learned in Windows are easily portable to any current GUI, and visa versa. I personally believe that I could sit down at any computer and figure out the GUI, but then again I was like this when I first started using computers with Windows 3.1 on them. So it's really important to look and see how GUIs are alike and how they are different.
Today, the main functionality of a GUI is virtually the same in any operating system, under any Windows Manager (minus a few frenge ones...); we are getting to the point that we are "desktop-agnostic". The only thing that remains in Linux is to get video accelleration up to Windows/MacOS X levels, and once there, start sprucing everything up with a bit of eye candy (drop shadows rock eye-candy wise, fast window transforms like in Mac OS X, etc). But I do have to admit that Linux, at current, is far more themeable than either Windows XP or Mac OS X, and I believe it will probably remain that way for a long time... (bad for new users, good for established users).
I don't think the Pentium M (basically a pentium 3 with a lot of p4-based enhancements) is bus-compatible with the Pentium 4 (lest we would be seeing PM-based desktop boards flying off the mills).
That, good sir, was the best /. post ever.
I will look into this. Thanks for the link!
To the second question: Nobody in the open source world.
Microsoft's on the way to doing it, and there was a small project that existed for a few months that allowed GNOME to access a database as a file system (It was very nasty; involved a kernel patch (a CORBA orb) that nobody was too happy about, so the project never took off.)
I've thought about the problem a few times. It requires the kernel pass information back to user space, unless the database was actually incorporated into kernel space (and that won't blow over well for a number of reasons). Passing the data back to user space requires a messaging system. The problem is, there are very few messaging systems out there designed specifically for kernelspace-userspace communication. CORBA was one developers answer; my answer would to be to ground up a protocol (because I feel that a network messaging solution, i.e. TCP/IP, can't be secured well enough in the long run).
Lastly, a daemon needs to exist to listen to the calls from the kernel and interpret them into SQL. This could be built into the kernel itself, but once again you have to question the security of the kernel building an SQL query that would go directly to the database server. Also, one of the better parts about this daemon would be metadata extraction; since the daemon is virtually transparent to both the user and the database server, the metadata can be completely ripped from the data and stored in a seperate table to allow for much faster, more optimised searches. EXIF Tags can be copied from JPEGs, ID3 tags copied from MP3s, etc.
Ideally, the daemon would be pluggable, allowing for anyone's metadata extension to be added after compiliation, but I believe that it's important to have a functional system before having a featureful system.
If you'd like to talk more about it, I'm really open to the idea of finally having an SQL-based file system. A relational database file system is the future; if we get there before Windows, we can add yet another example of the speed of open source development.
Google's just trying to get their stock out there and in the news, any way possible. Kind of strange way of doing it since they could have won the lawsuit I'm sure, but still. This is very odd behavior from Google.
Shit... Always forget to use the preview button. Anyways...
;).
I don't think they wanted to implement the whole command set, but since they had to, they did so as crudely as they could. I doubt they spent very much time trying to make this part of their chip fast; the same way they didn't try to make Itanium x86 emulation fast. The greater scheme of it all; they can say that this code is simply "flawed". Better than saying it, they can let people opinionate it ("hey, Intel's usually on top of the benchmarks.. there's gotta be something wrong with that code").
Too bad Netburst can't give them just a little more time.. I'd love to see either a dual-pentium m on-core chip, or even more nifty: a pentium m | pentium 4 on-core chip. Best of both worlds
I think the bigger part behind this is that Intel really didn't want to implement the whole AMD64 command-set. They just wanted to be "compatible enough". This is a defeat for Intel and they're not the kind of company that wants to own up to that. If worse comes to worse, they could ground up a X86-64 chip to compete, but I don't think they want to have to rely on it.
On the otherhand, Intel seems to be marketing these chips as a way to get more memory on your motherboard (aka the way Apple did at first, "Now you can have EIGHT gigs of ram instead of FOUR!!!"). They're hoping this will be enough for most people, considering where these chips will be marketed (low-medium range server).
Besides, Intel's said it plenty of times: Netburst is dying. It was a foolish hack in the first place, but at least it gave them enough time to breed the Pentium M into what it is today.
Technically, it already does.
Linus would be mutating into Tux. Evolution occurs as one produces offspring.
Most likely they'll continue to use phone numbers. It's too much of an investment to try to change the number system, and on top of that, it'd be much harder for a traditional telephone to call an IP number.
Basically, they're turning the voice data into packets and then sending the packets across their network, improving the effeciency of their lines. There's been a lot of discussion about this lately actually. Either way, I wish the american phone companies would get on the ball...
Because the human body can deal with the heat a lot better than the computer sitting on the lap can. That insulation is keeping the heat in the notebook.. I wouldn't be surprised if major laptop manufacturers voided warrantees due to the use of these pads.
hehe, old postits were a whole lot stickier, and it's aided by some tape.. the password's the local root password ( m30wm1x ) to a machine I'm not sure I even own anymore. It's stuck to my zenith low (ie, very high) radiation 14" monitor...
I've still got a three year old password on a postit note on the side of my monitor. It just goes to show you that passwords can sit anywhere.
The real question is, if a password's that old, what use SHOULD it still have? Hopefully, people adopt policies where they update passwords every month, or few months, especially if it's dealing with anything financial/uber personal (doctor's records.. etc).
Get real, stop trying to scare us with your security warnings; just educate people to change their passwords.
xorg is still pretty much to stock XF86, so you're not going to gain/lose anything by early adopting. Later, it'll become a big deal.
Anyone know where I can find decent information on the X protocol without druging through the source? I've been toying around with Y-Windows, and I've been wondering just how much work it'll take to make some kind of compatibility driver/subsystem.
Thanks in advance.
Actually, Xorg is just a fork of XFree86 right before the licence change.
I usually keep it as a policy not to respond to AC's; they don't have the balls to say it to my face, then it means nothing. But this time, I'm going to reply anyways.
Yes, there are cases where there will be no edges to find, but in those cases, it's usually okay to just keep trucking a-long. It's not just one technology that will win this race, it's the combination of all of them working together to solve a common problem.
As for speed, increasing the shutter rate of the camera, using multiple cameras, and faster computers deal with speed processing. The idea is to slowly ramp up speeds as it's safe, and the instant there's something in the way, begin to slow down and steer, noting the deviance against the path, and undoing it as soon as is convienient.
To end all, yes, the real world is different than the theoretical and the experimental world, but both worlds are based on the real world, and the rules are the same. Approximenting is what we usually do in the real world to make up for the inadaquacies of it. Since the world isn't perfect, neither can our machines be.
First of all I'd like to thank you for being so condesending.
Second of all, no, I'm not the first to invent, implement, design, or think about sensing. It's a _necessity_ for this project. All robots must be capable of this in order to complete the trek.
2D images to 3D mapping actually did work for me, though yes, I do know the limitations of it. My idea for the project would be to use many more cameras taking pictures one at a time at set intravals and from different angles and more or less do reverse raytracing to develop a 3D scene. While this is very computationally intensive, it does work. My webcams were Intel, and while they did provide pretty crappy pictures at time, it wasn't entirely impossible to use (though it was all I could afford). 3D scenes took about a minute to form on my P4 1.4 (willie) due to the degredation, and would often create objects based on hazy surfaces on the glossy desk I worked with.
Laser range finding I haven't had the pleasure to work with yet, but I do understand how it works, and do believe that it will add a key element to finding the best direction to take.
Acoustics will also be a great help; using above ground SONAR could be extremely useful at finding the differences between a rock and a bush; a rock will have a more dense auditory return and therefore will be detected as a rock, visa versa a bush will have a scattered return pattern, and not be as dense.
It's not like anything I'm saying here is revolutionary either. I'm simply stating that the technology is here, and we can make it work. I believe that we'll at least break the 100 mile mark next contest and that we would have last time too had the red car been better prepared.. I just don't believe the HumVee is a good platform.
The car's especially important because it has to be adapted for desert travel.. What we need is something that looks more like a kid's RC car, blended with a monster truck, and with a few installed tricks for dealing with mishaps and accidents: *flat tires automatic tire pressure balancing, possibly reinflating; a mechanism at the low points of the car where it may get stuck to push and get it back on driving sides, gyroscopes on board each wheel, the central vechicle, and a gyroscopic platform with the camera's mounted on them to maintain levels, etc*,. The car's really got to embody the spirit of James Bond, the intellegence of M, and the gracefulness of a tiger.
So no, none of my techniques are the holy grail. The grail is having them all come together perfectly.
Trust me, I understand that too, but that's when you have to get into surface approximentations and such. If a surface looks scattered like a clump of grass, then it's booleaned from a screen of black. The resultant image should be easy enough to pattern match to images of trees, rocks, brush, or anything else in a library. Dunno how well this would work in real-life, but this is what I did with my little toy model and it worked well.
Another way might be to test the density of the object, or to use color like we humans do.. If somethings green or yellow and sparce, it's more likely tumbleweed or a bush, otherwise it's a rock.
Lastly, at certain speeds, objects of certain sizes should be tossed out. If it's the size of a small mellon *smaller than a water mellon lets say*, then just throw the object out. It's not going to effect the car going at a speed of 35-65 MPH if the car's built right.
Just a few ideas. If I do get the chance to be in the project like I'm hoping, I'll get to test a few of them. Otherwise it's probably just idle chatter. Either way, it's something to think about.
I don't doubt it for a minute. Being a Florida Tech freshman in the fall, I want to try to get involved with this project. I've worked on stereo optics systems before using two webcams and I can tell you that this kind of system holds great promise at winning the race. In combination with great laser range-finding and possibly optical range finding (something like us humans do), even acustical systems, a machine has just as good of a chance to pilot a car as it can an aircraft or anything else.
Another thing: use the 2d images to build a 3d map on the fly, approximenting object sizes by finding the edges of the object in the pictures, and you should be able to navigate around and over them quite easily. The car also plays a key roll; it needs to be adapted into a dune buggy of sorts; huge soft tires and great suspension.
Scary that we're working on this for the government though..
Mind helping me navigate it? I mean come on.. the site's utterly innavigable..
Oh you didn't know? The submitter was James T. Kirk...
You can't WiFi across the Atlantic.
Sure, but you could tie your little WiFi router into a satellite transceiver, launch a few satellites in geosync, and connect that way.
On that same point, we could use a lot of existing technologies to augment the Wireless revolution. Imagine converting an AM station (which DO have the kind of range) into a WiFi telephone system. Or even just using the antenna to get the kind of range. As for reliablity, battery backups, auxillary generators and solar power help. That helps with rural locations.