Wow, cool! I've actually written a compiler for C++ in the past but I didn't look into index checking so this is cool to hear about. Yeah, I always wished that sizeof could be more useful for arrays.
It's interesting how C# had a lot of similar problems (well, not with arrays, though because of its fundamental design it's not exactly very fast for numerical stuff) but because it's owned by a single company it evolves so incredibly fast... I really love C# at this point (yeah so kill me, etc... I've recently concluded that extension methods are indeed awesome); I do sometimes wish that the C++ standard evolved much quicker. I guess MS kind of tried to evolve C++ on its own via Managed C++ but the managed C++ syntax (carrots (^) anyone?) makes me want to vomit.
Wow, how were you modded "Troll"? I'd mod you up if I could.
Yeah, array/pointer ambiguity is a key "broken" feature of C++, although at the same time it's exactly the kind of thing that makes it possible to use the same language for code running on a microcontroller and for a full-blown GUI. But yes, for most things it would be incredibly useful to have proper arrays with index checking and so on. Most templated solutions that I've seen (Boost?) are just butt-ugly and make the code that much more difficult to understand.
I think anyone that's used C++ a lot (this is probably a truism for all things) develops a strong love/hate feeling towards it. So it goes.
I really hope these guys make it as integrated MCU modules soon. I can't claim that I've ever designed *really* small stuff, but I have some experience designing rather compact sensors,etc: the external crystal that drives the (I'm talking something between 20 and 200Mhz) MCU/DSP in these settings is typically almost as big as chip itself! It gets worse since typically you have to add discrete caps specifically for the xtal type/frequency and the whole thing makes your pretty, tiny, elegant, simple circuit that much more needlessly complicated.
I, too, worked on the grand/urban challenges. At one of the post-competition conferences Ibeo (owned by SICK) claimed that they would be able to produce their 4-beam LIDARS (with builtin target tracking that works semi-OK in highway-type scenarios) for $300 by two years time. Of course the Ibeo ALASCAs and such still have moving parts and work in only specific situations, but they're getting pretty good.. or at least better.
Having said that, a *huge* problem with LIDARS (like RADARs or any other active sensors) in a military environment is that carrying a LIDAR is the same as carrying a homing device for any basic IR-targeted bomb/missile.
"Where's that convoy, Sam?" "Put on your IR goggles and look for the huge disco light in the middle of the desert, Bob!" "Wow, Sam, thats WICKED!"
So I'm not sure how they're addressing that, or if they're hoping for an application niche that doesn't deal with being shot at altogether.
I haven't seen the 3.0 spec but from the diagrams in TFA it seems that the 5 new pins do the following:
1 pin (middle) - ground (I suspect that with the higher bandwidth they're adding a signal ground separate from the already existing shared signal/power ground. this may be completely false). 2 pins (probably differential twisted pair) - "USB3_TX" - is USB3 departing from the shared-differential-bus setup? 2 pins (also probably a diff. TP) - "USB3_RX"
USB1/2 was somewhat special in contrast to Ethernet or IEEE1394 in that it used a single bus and everyone connected to it had to figure out how to share it (each device in turn takes control of the data lines when it needs to transmit). It looks like USB3 is changing this a bit (makes sense for higher bandwidth - the taking control of/releasing the data lines wasted precious data line cycles and makes the interface hardware/firmware/software do extra work). From the RX/TX markings it would seem that for two devices sharing a cable, one TP will always be driven by one device and the other by the other device. However from the little I know about the USB1/2 spec this doesn't make too much sense (currently the USB host has to poll a peripheral for it to transmit any data back the the host), so I'll be looking forward to hearing the details.
If the above guess is right then I'd expect to see a much more advanced family of USB controllers than the current (quite straight-forward) iteration. Maybe USB3 will be significantly changing the USB topology and becoming more like Firewire.. it seems somewhat logical.. who knows.
Too bad they're adding the 5 new pins (given, 1 of them is in theory good old GND but still). As an EE, the one thing I liked about USB over Firewire is its physical simplicity... power, ground, and a differential bus. With 1394c heading towards RJ45 it's like USB and 1394 have traded places in terms of physical convenience (I'm sure a number of people have had the pleasure of dealing with ultra-over-engineered (and consequently overpriced) 1394a/b cables and repeaters.. oh the repeaters).
..Not like the host-heavy USB stack made it a much-liked protocol for me in the first place.
I'm from team Cornell, #26. We finished the race (although slowly due to what looks like a buggy throttle controller). C# was used exclusively in our system for the strategic planner. It was also used quite a bit for the behavior/operational systems.
I'm very much a C++ programmer, and with a strong focus on micros to add to that, so yeah, I was a bit... skeptical.
At one point in development we did have a "memory leak" issue but it was entirely our fault (while obviously there are no "new"/"delete"'s around, if you don't dereference things then essentially you get a nice "memory leak" with all of the associated symptoms).
I think that C# really sped up our development time, and, in the end, our car finished. I'm sure that there are other fully valid languages/IDEs/etc, but we happened to be most proficient in MSVS; we tested the crap out of C#'s compiler's performance on our machine for our specific application; we used it and that part of the system performed admirably. C# also let us write numerous support utilities quickly.
Microsoft may have many faults but I'm pretty sure that C# / the Visual Studio IDE environment as a whole aren't it.
Princeton seemed to have a number of issues outside of "slowing down" during runs. They completely scrapped their first two qualification runs, ran maybe once, and then left.
P.S. No, i'm not paid by microsoft or such. Aside from the usual departmental benefits like free copies of MSVS and winXP, we didn't get any kind of sponsorship from them.
(Preface: I'm a member of one of the DUC teams. I'm at the NQE right now.)
There *is* a traffic circle, although not really a roundabout. 2 lanes all around, moving in the same direction. Several merges and exits. Seems like teams are OK with it so far but that course currently doesn't seem to include moving traffic.
I completely agree with you. Each time I read about these "robots" i visualize a somewhat autonomous vehicle that can at least navigate from pt A to pt B in flat terrain with minimal human assistance. I imagine that for patrolling missions it would be quite useful to be able to tell a robot to go to a point, say, 30 meters away, across a courtyard, and be able to focus on sweeping the camera around while not worrying about the robot's movements.
The recent developments from Northrup / Lockheed / Talon / iRobot / etc are a tremendous disappointment. Just think about how much money is going into these programs; what we get in return is functionally only slightly more advanced than the WW2 RC tanks as linked to in the grandparent (those things were incredibly awesome - controlled by pneumatics with 20 relays; a side effect of using a shared compressor was that when you turned a turret your turn rate went down, etc!). The main real innovation (yes, i'm being something of an asshole here) between then and now is the ability to use videocameras on the robot.
On the other hand the recent advancements in actual autonomous robotics are quite amazing; its too bad that so few of these advancements seem to make it to production ground robots. Just compare the production AGV's to the UAV's out there. I'm not advocating for implementing a crazy ground vehicle AI and such and letting it loose in Baghdad -- you can start small - how about some basic SLAM (hell, integrating from odometry would work quite well with minimal human supervision) in nicely defined urban environments with some GPS availability and being able to autonomously navigate flat ground?
Then again the idea of tasking robots to assure control of other people (no matter who those people are) does depress me.:( It's a shame, really.
It's a funny coincidence, but the may 14th issue of the New Yorker also had an article on the LHC.
It's much much much lighter on the details, but I found it to be a much more interesting read -- in particular because the author appears to have tried to talk to a number of people there and get a general feel for what people think about experimental physics these days.
There's a company commercializing a similar concept called splashpower. I don't work for them, although I have worked with them. It's really cool technology and, suprisingly enough, it's not vaporware.
Hopefully they'll actually have their modules out for public use sometime soon...
I'm glad to hear that someone has said it. Yes, this is by far not the first dynamically balancing robot; and in this case, to be honest, i'd probably wait a bit and improve the bot's look/performance before announcing anything.
The Sony SDR 4X/QRIO has one of the more impressive ZMP implementations that i've seen in a while. Too bad that the project got killed.
Re:My Grandfather the watchmaker...
on
Caller ID Watches
·
· Score: 1
They should incorporate a piezo rate gyro.. If you shake your hand, the caller gets voicemail... and an accelerometer too, so that if you bring your hand to your ear when you get the call, your BT headset automatically accepts it. Both are availible in low-power, ultra-small packages.
Of course this would mean that the crazy mumbling people outside would also start waving frantically... but hey, it's progress.
Oh and by the way if you like the above idea then you should know that i may have a patent pending for it:)
Just wondering, if it's a power drive chip, why does it have so many pins (i'd look up a data sheet, but i can't read the chip's number from the photos) (i can read SMOOTH, ??250E, 1.2, VH, 505 or 50S) (looks like a 64-pin TQFP package)? Or can you get IC's that combine some kind of PID control or whatever and the actual power FET's in a single package these days?
The samsung chip next to it appears to be a DRAM chip, so (being completely ignorant of HDD-specific IC's), my first guess would be that this is an micro of some sort. If, say, the Vcc and GND pins got shortened (yea, someone trimmed those damn pins again!) then i think it'd be possible for a chip to blow up like that. On the other hand when I see MCU's die, even when it's due to high-current shorts, they seem to just heat up and... quietly dispatch their tiny smelly blue souls.
This only relates to "OS" ideas, not TFA. I saw the "a new kind of OS" title and the first thing that came to mind was this idea I had about improving the way running instances of applications are manipulated and managed: I think that each active window (independent of if it's N windows of a single app or not) should keep track of the last time the user voluntarily interacted with it and that windows with similar timestamps should be assumed to be implicitly linked together to form a sort of hiearchial workspace session.
It may be easier to explain using an example: User is working on some project that involves a schematic editor (lets say OrCAD), five instances of Firefox (looking up IC specs, etc), and some sort of a code editor (vi!).
Now someone comes in and asks for some help with some completely different project. I know that what I do is I usually open up N more instances of firefox, another one or two apps, etc. Suddenly I'm burried under 20+ different windows having to do with some horrifyingly large number of projects.
Here's the catch: when I switch back to my original instance of the schematic editor the OS should automatically bump up the windows that I last touched when I was last using the schem. editor app. So those five original Firefox windows should magically emerge from the pile of active firefox sessions (windows, tabs, you get the idea). All of a sudden, you CAN keep those hundreds of idle windows open in the background, a dynamic world of your own creation that lets you access all the information that you need... and having this kind of prioritized taskbar/ tool I, for one, think would be incredibly helpful.
Too bad i hate software coding and dont know the internals of KDE:(. Someone go code it up, pretty please
We were recently discussing CT scanners in a class... those things spin pretty damn fast, with all of the electronics experiencing something like 20G's... for hours and hours and hours. And the gantry is these days pretty damn heavy and insanely complex (i wonder how they get the data from the spinning sensors? surely not a million sliprings?) I suppose still maybe MRI is more impressive with its multi-tesla QUICKLY changing magnetic fields.
so i have a question. why is the population of slashdot comparing macs to dells? DELLS?
i think the greatest *general* hardware advantage that PC users have is that they can build their computers from scratch. Build one like that and compare it to a Dell with the same specs... last time I checked, Dell was ripping people off right and left. As far as I know you can't do this with a Mac. (Mac users feel free to correct me. And no, I'm not talking about reusing a monitor or a keyboard or a hard drive here... can you buy new bare chassis mac systems?)
Oh right. We dont want to build computers because we don't know anything about computers. You're telling me that you can't screw a couple screws in?? Connect some damn cables? Oh right, grandmother/grandpa. Anywayz, in my opinion most of the population is perfectly capable of assembling a computer (obviously some people have shaky hands or very bad vision etc). OK, what the hell was I talking about.
Right. So it's strange to me that no one is pointing out the build-it-yourself advantage of PC's (some would say disadvantage; i can see that but let's talk about semi-technical people in 2006 here...)..
disclamer: i just got a boxful of salmon,candy and crackers from microsoft. i kid you not. actually this is enough info to probably find out who i am.. fun. so i think that i need to give out a military secret to make this really fun: they're making Scaled' Proteus into a UAV series. That plane is so beautiful..
This service is cool and all of that, but an accuracy of 20-40 meters???
Modern civilian GPS (been using the OmniStar HP service recently.. granted, its subscription-based) has a (real, tested, this-is-not-a-fucking ad) optimal-condition accuracy of 10cm. Even good old vanilla-plain non-SA GPS is at least 10m accurate (horiz position (lat/lon), 95% conf). Src: http://users.erols.com/dlwilson/gpsacc.htm
Anywayz, definitely don't forget GPS... yet?
WHOOSH... is that the sound of my sense of humo(u)r flying off? Blah.
We share the lab with these people. And we've been wondering why there were making all of these sounds for the past few days. Guess I know why now. Now everyone should go lobby Cornell to give them/us more lab space:)
So t/Space sounds cool and all of that.. but does anyone know what Red is doing on t/Space? The company doesnt have a web site so I can't check.
It was weird seeing his name there as I was under the impression that he was 100% committed to CMU's Red Team DARPA GC efforts. Is Red Team giving up on desert vehicles and going into the aerospace industry? (joke.. or is it?)
At cornell. It looks quite cute, but unfortunately i've never seen it run:(. It had a huge number of batteries in it. And it has this really cool induction-based charger port in front.
If anyone from cornell is reading this, its the car that used to be in the back of Rhodes Hall all the time (red, really small). It's at a top-secret storage location now.
I'm not a linux zealot and i hate linux zealots. However i recently got factual proof that linux is "there" for workspace environments.
The case: we are using a four-way opteron machine (pre-release, ty AMD!) and we need to run ieee1394 DCAM cameras on it.
we tried win64 (betas), since our software was written for windows. installed fine, everything fine, proceeded to install camera drivers.... except that of course 32bit drivers dont work in 64bit windows!!!
So ok, no problem, i've got the source, i'll recompile things and everything will be fine. So after digging around i end up trying to compile the 64bit beta DDK examples... which dont run because they are "not 64bit compatible!" (even with win2003 32bit check manually turned off)
So, quickly running out of options, we installed FC3.x86_64... and in 5 hours we had the whole damn setup working, code ported over, etc.
it was awesome.
so this is a really crappy "switch"-type story (btw macs can go to hell), but all i want to say is that i'm impressed, and other people are too. and i like it.
i have no clue what this Dvorak guy says and from his past articles i really dont give damn. it is very weird to me that this is the case, but it seems that in the x86_64 bit area, microsoft's OS's are simply much worse off currently. enough to make people spend the time to use linux. i guess its a nice side effect of the compile-install organization of linux, and therefore OSS. i never would have guessed things would work this way.
Slashdot Mirror
I'm pretty sure that picture is of a draganflyer X6.
Not impossible they've installed custom additions (custom autopilot, radio links, etc)
Perhaps the "flying saucer" is a mis-translation on FARS' part..
Wow, cool! I've actually written a compiler for C++ in the past but I didn't look into index checking so this is cool to hear about. Yeah, I always wished that sizeof could be more useful for arrays.
It's interesting how C# had a lot of similar problems (well, not with arrays, though because of its fundamental design it's not exactly very fast for numerical stuff) but because it's owned by a single company it evolves so incredibly fast... I really love C# at this point (yeah so kill me, etc... I've recently concluded that extension methods are indeed awesome); I do sometimes wish that the C++ standard evolved much quicker. I guess MS kind of tried to evolve C++ on its own via Managed C++ but the managed C++ syntax (carrots (^) anyone?) makes me want to vomit.
Wow, how were you modded "Troll"? I'd mod you up if I could.
Yeah, array/pointer ambiguity is a key "broken" feature of C++, although at the same time it's exactly the kind of thing that makes it possible to use the same language for code running on a microcontroller and for a full-blown GUI. But yes, for most things it would be incredibly useful to have proper arrays with index checking and so on. Most templated solutions that I've seen (Boost?) are just butt-ugly and make the code that much more difficult to understand.
I think anyone that's used C++ a lot (this is probably a truism for all things) develops a strong love/hate feeling towards it. So it goes.
I really hope these guys make it as integrated MCU modules soon. I can't claim that I've ever designed *really* small stuff, but I have some experience designing rather compact sensors,etc: the external crystal that drives the (I'm talking something between 20 and 200Mhz) MCU/DSP in these settings is typically almost as big as chip itself! It gets worse since typically you have to add discrete caps specifically for the xtal type/frequency and the whole thing makes your pretty, tiny, elegant, simple circuit that much more needlessly complicated.
I, too, worked on the grand/urban challenges. At one of the post-competition conferences Ibeo (owned by SICK) claimed that they would be able to produce their 4-beam LIDARS (with builtin target tracking that works semi-OK in highway-type scenarios) for $300 by two years time. Of course the Ibeo ALASCAs and such still have moving parts and work in only specific situations, but they're getting pretty good.. or at least better.
Having said that, a *huge* problem with LIDARS (like RADARs or any other active sensors) in a military environment is that carrying a LIDAR is the same as carrying a homing device for any basic IR-targeted bomb/missile.
"Where's that convoy, Sam?"
"Put on your IR goggles and look for the huge disco light in the middle of the desert, Bob!"
"Wow, Sam, thats WICKED!"
So I'm not sure how they're addressing that, or if they're hoping for an application niche that doesn't deal with being shot at altogether.
I haven't seen the 3.0 spec but from the diagrams in TFA it seems that the 5 new pins do the following:
1 pin (middle) - ground (I suspect that with the higher bandwidth they're adding a signal ground separate from the already existing shared signal/power ground. this may be completely false).
2 pins (probably differential twisted pair) - "USB3_TX" - is USB3 departing from the shared-differential-bus setup?
2 pins (also probably a diff. TP) - "USB3_RX"
USB1/2 was somewhat special in contrast to Ethernet or IEEE1394 in that it used a single bus and everyone connected to it had to figure out how to share it (each device in turn takes control of the data lines when it needs to transmit). It looks like USB3 is changing this a bit (makes sense for higher bandwidth - the taking control of/releasing the data lines wasted precious data line cycles and makes the interface hardware/firmware/software do extra work). From the RX/TX markings it would seem that for two devices sharing a cable, one TP will always be driven by one device and the other by the other device. However from the little I know about the USB1/2 spec this doesn't make too much sense (currently the USB host has to poll a peripheral for it to transmit any data back the the host), so I'll be looking forward to hearing the details.
If the above guess is right then I'd expect to see a much more advanced family of USB controllers than the current (quite straight-forward) iteration. Maybe USB3 will be significantly changing the USB topology and becoming more like Firewire.. it seems somewhat logical.. who knows.
Too bad they're adding the 5 new pins (given, 1 of them is in theory good old GND but still). As an EE, the one thing I liked about USB over Firewire is its physical simplicity... power, ground, and a differential bus. With 1394c heading towards RJ45 it's like USB and 1394 have traded places in terms of physical convenience (I'm sure a number of people have had the pleasure of dealing with ultra-over-engineered (and consequently overpriced) 1394a/b cables and repeaters.. oh the repeaters).
..Not like the host-heavy USB stack made it a much-liked protocol for me in the first place.
I'm from team Cornell, #26. We finished the race (although slowly due to what looks like a buggy throttle controller). C# was used exclusively in our system for the strategic planner. It was also used quite a bit for the behavior/operational systems.
I'm very much a C++ programmer, and with a strong focus on micros to add to that, so yeah, I was a bit... skeptical.
At one point in development we did have a "memory leak" issue but it was entirely our fault (while obviously there are no "new"/"delete"'s around, if you don't dereference things then essentially you get a nice "memory leak" with all of the associated symptoms).
I think that C# really sped up our development time, and, in the end, our car finished. I'm sure that there are other fully valid languages/IDEs/etc, but we happened to be most proficient in MSVS; we tested the crap out of C#'s compiler's performance on our machine for our specific application; we used it and that part of the system performed admirably. C# also let us write numerous support utilities quickly.
Microsoft may have many faults but I'm pretty sure that C# / the Visual Studio IDE environment as a whole aren't it.
Princeton seemed to have a number of issues outside of "slowing down" during runs. They completely scrapped their first two qualification runs, ran maybe once, and then left.
P.S. No, i'm not paid by microsoft or such. Aside from the usual departmental benefits like free copies of MSVS and winXP, we didn't get any kind of sponsorship from them.
(Preface: I'm a member of one of the DUC teams. I'm at the NQE right now.)
There *is* a traffic circle, although not really a roundabout. 2 lanes all around, moving in the same direction. Several merges and exits. Seems like teams are OK with it so far but that course currently doesn't seem to include moving traffic.
I completely agree with you. Each time I read about these "robots" i visualize a somewhat autonomous vehicle that can at least navigate from pt A to pt B in flat terrain with minimal human assistance. I imagine that for patrolling missions it would be quite useful to be able to tell a robot to go to a point, say, 30 meters away, across a courtyard, and be able to focus on sweeping the camera around while not worrying about the robot's movements.
:( It's a shame, really.
The recent developments from Northrup / Lockheed / Talon / iRobot / etc are a tremendous disappointment. Just think about how much money is going into these programs; what we get in return is functionally only slightly more advanced than the WW2 RC tanks as linked to in the grandparent (those things were incredibly awesome - controlled by pneumatics with 20 relays; a side effect of using a shared compressor was that when you turned a turret your turn rate went down, etc!). The main real innovation (yes, i'm being something of an asshole here) between then and now is the ability to use videocameras on the robot.
On the other hand the recent advancements in actual autonomous robotics are quite amazing; its too bad that so few of these advancements seem to make it to production ground robots. Just compare the production AGV's to the UAV's out there. I'm not advocating for implementing a crazy ground vehicle AI and such and letting it loose in Baghdad -- you can start small - how about some basic SLAM (hell, integrating from odometry would work quite well with minimal human supervision) in nicely defined urban environments with some GPS availability and being able to autonomously navigate flat ground?
Then again the idea of tasking robots to assure control of other people (no matter who those people are) does depress me.
It's a funny coincidence, but the may 14th issue of the New Yorker also had an article on the LHC.
5 14fa_fact_kolbert
It's much much much lighter on the details, but I found it to be a much more interesting read -- in particular because the author appears to have tried to talk to a number of people there and get a general feel for what people think about experimental physics these days.
You can read the whole text legally and for free (no reg) here:
http://www.newyorker.com/reporting/2007/05/14/070
There's a company commercializing a similar concept called splashpower. I don't work for them, although I have worked with them. It's really cool technology and, suprisingly enough, it's not vaporware.
Hopefully they'll actually have their modules out for public use sometime soon...
I'm glad to hear that someone has said it. Yes, this is by far not the first dynamically balancing robot; and in this case, to be honest, i'd probably wait a bit and improve the bot's look/performance before announcing anything.
The Sony SDR 4X/QRIO has one of the more impressive ZMP implementations that i've seen in a while. Too bad that the project got killed.
They should incorporate a piezo rate gyro.. If you shake your hand, the caller gets voicemail... and an accelerometer too, so that if you bring your hand to your ear when you get the call, your BT headset automatically accepts it. Both are availible in low-power, ultra-small packages.
:)
Of course this would mean that the crazy mumbling people outside would also start waving frantically... but hey, it's progress.
Oh and by the way if you like the above idea then you should know that i may have a patent pending for it
Cool man, thanks! Yes, of course you're absolutely right... pid motor drivers have in around forever. I feel like such a noob :-)
Just wondering, if it's a power drive chip, why does it have so many pins (i'd look up a data sheet, but i can't read the chip's number from the photos) (i can read SMOOTH, ??250E, 1.2, VH, 505 or 50S) (looks like a 64-pin TQFP package)? Or can you get IC's that combine some kind of PID control or whatever and the actual power FET's in a single package these days?
The samsung chip next to it appears to be a DRAM chip, so (being completely ignorant of HDD-specific IC's), my first guess would be that this is an micro of some sort. If, say, the Vcc and GND pins got shortened (yea, someone trimmed those damn pins again!) then i think it'd be possible for a chip to blow up like that. On the other hand when I see MCU's die, even when it's due to high-current shorts, they seem to just heat up and... quietly dispatch their tiny smelly blue souls.
This only relates to "OS" ideas, not TFA. I saw the "a new kind of OS" title and the first thing that came to mind was this idea I had about improving the way running instances of applications are manipulated and managed: I think that each active window (independent of if it's N windows of a single app or not) should keep track of the last time the user voluntarily interacted with it and that windows with similar timestamps should be assumed to be implicitly linked together to form a sort of hiearchial workspace session.
:(. Someone go code it up, pretty please
It may be easier to explain using an example:
User is working on some project that involves a schematic editor (lets say OrCAD), five instances of Firefox (looking up IC specs, etc), and some sort of a code editor (vi!).
Now someone comes in and asks for some help with some completely different project. I know that what I do is I usually open up N more instances of firefox, another one or two apps, etc. Suddenly I'm burried under 20+ different windows having to do with some horrifyingly large number of projects.
Here's the catch: when I switch back to my original instance of the schematic editor the OS should automatically bump up the windows that I last touched when I was last using the schem. editor app. So those five original Firefox windows should magically emerge from the pile of active firefox sessions (windows, tabs, you get the idea). All of a sudden, you CAN keep those hundreds of idle windows open in the background, a dynamic world of your own creation that lets you access all the information that you need... and having this kind of prioritized taskbar/ tool I, for one, think would be incredibly helpful.
Too bad i hate software coding and dont know the internals of KDE
We were recently discussing CT scanners in a class... those things spin pretty damn fast, with all of the electronics experiencing something like 20G's... for hours and hours and hours. And the gantry is these days pretty damn heavy and insanely complex (i wonder how they get the data from the spinning sensors? surely not a million sliprings?) I suppose still maybe MRI is more impressive with its multi-tesla QUICKLY changing magnetic fields.
so i have a question. why is the population of slashdot comparing macs to dells? DELLS?
i think the greatest *general* hardware advantage that PC users have is that they can build their computers from scratch. Build one like that and compare it to a Dell with the same specs... last time I checked, Dell was ripping people off right and left. As far as I know you can't do this with a Mac. (Mac users feel free to correct me. And no, I'm not talking about reusing a monitor or a keyboard or a hard drive here... can you buy new bare chassis mac systems?)
Oh right. We dont want to build computers because we don't know anything about computers. You're telling me that you can't screw a couple screws in?? Connect some damn cables? Oh right, grandmother/grandpa. Anywayz, in my opinion most of the population is perfectly capable of assembling a computer (obviously some people have shaky hands or very bad vision etc). OK, what the hell was I talking about.
Right. So it's strange to me that no one is pointing out the build-it-yourself advantage of PC's (some would say disadvantage; i can see that but let's talk about semi-technical people in 2006 here...)..
disclamer: i just got a boxful of salmon,candy and crackers from microsoft. i kid you not. actually this is enough info to probably find out who i am.. fun. so i think that i need to give out a military secret to make this really fun: they're making Scaled' Proteus into a UAV series. That plane is so beautiful..
Of course, n00b. Slashdot is about precision.
This service is cool and all of that, but an accuracy of 20-40 meters???
Modern civilian GPS (been using the OmniStar HP service recently.. granted, its subscription-based) has a (real, tested, this-is-not-a-fucking ad) optimal-condition accuracy of 10cm. Even good old vanilla-plain non-SA GPS is at least 10m accurate (horiz position (lat/lon), 95% conf). Src: http://users.erols.com/dlwilson/gpsacc.htm
Anywayz, definitely don't forget GPS... yet?
WHOOSH... is that the sound of my sense of humo(u)r flying off? Blah.
We share the lab with these people. And we've been wondering why there were making all of these sounds for the past few days. Guess I know why now. Now everyone should go lobby Cornell to give them/us more lab space :)
So t/Space sounds cool and all of that.. but does anyone know what Red is doing on t/Space? The company doesnt have a web site so I can't check.
It was weird seeing his name there as I was under the impression that he was 100% committed to CMU's Red Team DARPA GC efforts. Is Red Team giving up on desert vehicles and going into the aerospace industry? (joke.. or is it?)
At cornell. It looks quite cute, but unfortunately i've never seen it run :(. It had a huge number of batteries in it. And it has this really cool induction-based charger port in front.
If anyone from cornell is reading this, its the car that used to be in the back of Rhodes Hall all the time (red, really small). It's at a top-secret storage location now.
So, this is slightly off topic, but somewhat on.
I'm not a linux zealot and i hate linux zealots. However i recently got factual proof that linux is "there" for workspace environments.
The case: we are using a four-way opteron machine (pre-release, ty AMD!) and we need to run ieee1394 DCAM cameras on it.
we tried win64 (betas), since our software was written for windows. installed fine, everything fine, proceeded to install camera drivers.... except that of course 32bit drivers dont work in 64bit windows!!!
So ok, no problem, i've got the source, i'll recompile things and everything will be fine. So after digging around i end up trying to compile the 64bit beta DDK examples... which dont run because they are "not 64bit compatible!" (even with win2003 32bit check manually turned off)
So, quickly running out of options, we installed FC3.x86_64... and in 5 hours we had the whole damn setup working, code ported over, etc.
it was awesome.
so this is a really crappy "switch"-type story (btw macs can go to hell), but all i want to say is that i'm impressed, and other people are too. and i like it.
i have no clue what this Dvorak guy says and from his past articles i really dont give damn. it is very weird to me that this is the case, but it seems that in the x86_64 bit area, microsoft's OS's are simply much worse off currently. enough to make people spend the time to use linux. i guess its a nice side effect of the compile-install organization of linux, and therefore OSS. i never would have guessed things would work this way.