Or frequency hopping. Indeed, I don't see why you need a "special card" or a central server, so long as the machines involved can agree on an IP sequence and the timing.
If you wanted to get fancy you could simultaneously assign several IPs and spread the packets amongst them (as well as periodically changing the IPs), to really confuse someone doing traffic analysis.
I'd be seriously worried about any highrise window that couldn't support a mere 230 pounds. Consider that such windows (especially the near-floor to ceiling type) have to be proof against people accidentally falling against them, and even more, proof against pressure differentials (in either direction) caused by high winds. For, say, a 5ft by 5ft window, a mere 1/10th PSI pressure differential gives you 360 pounds of force on the window -- and pressures can be quite a bit higher than this with a good wind.
Now, true enough, windows have been known to pop off of highrises in strong winds (ouch!) but rarely, and that in newer buildings where installation was sloppy.
But this whole suction cup thing has been done in countless movies and old Mission: Impossible episodes using the two-suction-cups-and-a-handle device used for pulling floor tiles in raised-floor computer rooms.
Take a look at Cavor (http://sourceforge.net/projects/cavor/). It isn't exactly VISION*, but the overall architecture is similar and that's my model (as much as I can remember, anyway).
Cheers,
-- Alastair
(Another ex-GeoVisioner -- and yes, the architecture beat heck out of what ESRI was peddling back then. I haven't been close enough to it lately to know about now.)
Yep, and it used to be that that data was very expensive -- involving lots of hand labor digitizing maps and aerial photos. That's still true to a certain extent, but much less so.
I've gone from one elegant-but-buggy GIS product (VISION*) to just doing "GIS" by connecting my CAD maps (Microstation) to databases,
I'm curious as to when you were using VISION* and it what context. It's been nearly a decade since my involvement with it (I did a lot of the requirements analysis and design for 2.0 -> 2.1).
And connecting CAD to a database is a nightmare -- I was once involved in converting a hybrid AutoCAD+dBase system to VISION*'s forerunner. Yuck!
Oh, and PS, that bodes ill for Open Source GIS software outside the academic world, because big organizations have a positive fondness for the "Microsofts" of any industry they buy from, and an aversion to "unsupported" products.
Sure, that's AutoDesk (who currently own VISION*) isn't going to be worried about CAVOR. Were I major telco or power company or large regional government I'd go with them for the support, training, handholding, etc. (Heck, when I was with GeoVision we wouldn't talk to anyone with less than a quarter million to spend).
But there's still a niche for open source GIS. Heck, look at the "travel map" software out there -- that's a rather simplistic GIS, to be sure, but it shares common elements. Think of what, say, real estate agents could do with a GIS system.
And beyond that, think of the other application domains that share characteristics with GIS. You mention trying to tie a CAD system and a DB together. How about a CAD system with a built-in DB interface? Or any number of other applications that have both a spatial or graphical aspect and a database aspect -- software diagramming tools (UML, other CASE tools), project management (PERT charts), various sorts of CAD, and so on. (This is part of what the CAVOR project is all about -- I always felt that GeoVision never quite understood the potential of their technology. I once prototyped a CASE tool (DFD's, ERD's and the like) on VISION* in about a day.)
Give folks a free toolkit like that and the uses and applications will come, and they won't all (by a long shot) require gigabytes of data. It's when the tool cost is high that it's only used by those with a lot of data to manage.
One open source project not mentioned is CAVOR, ("Creating A Vision Of Reality" if you insist that stand for something). (See the Cavor project page at SourceForge)
This is primarily the engine for a GIS, the database, graphics display, user interface, scripting, etc, that developers or end-users can further tailor to their specific application. The same engine can be used for other applications that include both a spatial/graphic part and a database part (eg CAD, UML diagrams, PERT charts, etc).
It's still in development -- the display list manager is working (and used in a spin-off, 'cvv'), the database interface and scripting language is in progress.
The architecture is based loosely on GeoVision/SHL/AutoDesk's high end "VISION*" system. (In its time -- before bankruptcy and transfer of the technology to SHL then AutoDesk -- GeoVision pioneered several of the technolgies widely used in GIS systems today, such as storing the spatial data in a relational database.)
The home page is at http://www.cavor.org although I'm not sure the server is up to a slashdot effect.
Whoever marked that as a troll obviously didn't read it, or doesn't understand money, or both.
Sure, MSFT may have had a better earnings/share, but look at their revenue growth: 18% over the last year vs RHAT's 106% growth. Indeed, RHAT had more growth between quarters (20%) than MSFT did all year.
I know where I'd put my money. (Of course, when you're small, it's easier to get large percentage gains. That works against you when you're large. The rolling average (filters out daily fluctuations) on MSFT's share price has been steadily downward for the last year.)
Only if the USPTO has to start paying back the patent registration fees they collected. Preferably with interest and penalties.
There's no incentive for the USPTO to care about prior art -- they get paid more when they issue a patent than when they turn it down, and doing their own search is just added overhead. We'll keep getting these bogus patents until some branch of the government slaps them silly and stops rewarding the practise. (And the PTO operates on the funds it collects, it doesn't just pass it through to the general fund.)
I'm assuming EFF is a 501(c)3 (read 'your contributions are tax deductable') organization. They'd instantly piss away their tax-exempt status if they start giving money to political campaigns, or even just strongly advocating one candidate over another. (Education on the issues, though, is another matter.)
However, donating to the EFF is always a good thing.
On my desk as I type this, I have a laptop with a nice, crisp (but jaggy) non-anti-aliased display, and another machine running an older version of Linux and X displayed on a cheap 14" monitor that achieves anti-aliasing but the simple method of having a slightly out-of-focus display. (Dang cheap magnet coils, or something). I can read either at length without bother.
However, when I look at a screen shot of an antialiased display on this nice crisp LCD, it bugs me. I think the problem is that because the rest of the screen has sharp lines and text, my eyes keep trying to bring the AA'd text into focus -- obviously without success. On the CRT, however, the whole screen is "soft focus" so my eyes just give up and go with the flow.
Shrug. As long as it's something I can turn off (by font, perhaps?), I like the idea. Maybe its just that my eyes burned out long ago reading dot-matrix printouts and 80x25 character dumb terminal screens. They expect anything on a monitor to be jaggy:)
NeWS was based on Display Postscript -- something I believe Apple is doing with MacOS X. X Windows at the time was mostly Version 10.
Like most nostalgia, the wonderous tales you may have heard about NeWS leave out all the gritty bits that people would rather forget. Was it better than X at the time? Possibly -- except that it locked you into Sun. Was it better than the latest version of X as realized by, say, XFree86 4.0.x? No way.
Java compiled to native code (rather than interpreted bytecode) might not be a bad idea. It'll still be a bit slower than badly written C code, because of the internal bounds-checking, but probably about the same as securely-written C.
I say let the compiler do the work, wherever possible. Isn't that the whole point of compilers?
I agree. The problem with BIND prevalence is the problem with any monoculture -- any bug that its susceptible too can take out the whole population.
However, part of the problem is that the RFC's don't quite adequately specify everything, and the prevalence of BIND means that other DNS software has to take BIND's own quirks and interpretations of the specs into account. (Sound familiar? Like dealing with the products of a certain large and widely disliked software company?)
Personally I think anyone running critical services like a DNS ought to not only have hardware backups, but back up software written by different authors. This is (or was, I don't know if they still do) the approach taken in the Space Shuttle computers: five identical computers, four of them running software by one vendor and the fifth, the emergency backup for the emergency backup, running software by a different vendor.
As for myself, I'm switching to djbdns. I don't have the time to keep up with the BIND bug-of-the-month club.
Build a display into a set of contact lenses. Display the irises of the person whom you're pretending to be. Complete with whatever dynamic changes the scanner is looking for to tell a "real" iris from a photograph of one.
Or, on a less insidious level, for the fashion concious: contact lenses that can display funky dynamic patterns.
The only way to find it was to dis-assemble the compiler and codewalk the result.
You're assuming that the disassembler wasn't also in on the joke, and that it it wouldn't recognize that it was disassembling the compiler and casually omit the incriminating code. For that matter, you're assuming that the C compiler wasn't smart enough to recognize when it was compiling a disassembler and insert the appropriate code to implement the above.
There are two questions to ask yourself: "am I being paranoid?" and "am I being paranoid enough?".
Yeah, I hacked my C64, I hacked a couple of VIC-20s, built an Apple-II clone, etched my own circuit boards, yadda yadda. Nobody does this anymore because all the chips and components are SMD, the bus frequencies run at multiples of 33MHz (and the CPU is basically a tiny microwave oven), and the circuit board traces are too small and too close together.
Back when the ICs were all DIPs with 0.1" lead spacing, you could tell the resistors and capacitors apart (and tell them from grains of sand) and you could debug the signals with a cheap 10 MHz 'scope, that kind of hardware hacking was fun.
Of course now I'm sounding like my father, grousing about winding his own coils and finding the sweet spot on a galena crystal.
Why are Canadians always treated differently from other NATO members (e.g. with the encryption ban)?
Because Canada is also part of NORAD (NORth American [Air?] Defense). I don't recall all the details of the arrangment, but it goes back to the early cold war days with the setting up of the DEW (Distant Early Warning) line across northern Alaska and Canada, and various other arrangements that had to do mainly with protecting the US from Russian bombers (and later missiles) that might take the direct route over the North Pole and Canada.
There are even a few Canadian officers routinely posted to the NORAD facility in Cheyenne Mountain, although I don't recall seeing any US military in the "Diefenbunker" underground facility north of Ottawa when I was posted there.
All that said, however, there are plenty of US secrets that Canadians don't have access to.
There's also the recognition that the border between the US and Canada is pretty open both to people and information, and that strong encryption can benefit the many companies that do business and have offices in both countries.
What the hell were they doing releasing data to be analyzed from a period when the gear was broken in the first place?
Sounds a bit odd to me. The tin foil hat brigade would probably think they were trying to cover something up with that lame explanation. I think they're just being a bit too cavalier (read "incompetent") about the whole process.
I think what he's referring to is the X distinction of "client" and "server." The "X server" is the piece of software that display on, and it renders the data coming from the "X client," which you connect to, and which is actually running the program. This seems like backwards terminology to me
Think of it as "display server" and it starts making more sense. Especially since you can (and frequently do) have multiple X clients displaying to that same display server simultaneously -- although granted usually they are local rather than remote clients in a typical workstation setup.
Wouldn't it be more accurate to describe the rendering portion as a "client," since it connects to another computer, requests data, and renders that data, while the portion which accepts connections, runs programs at request accurately called a "server"?
You're mixing things up here. The rendering portion (X) doesn't connect to another computer, the other computer connects to it. (The confusion may arise if you're using say a telnet client program within X to initiate the connection to the other computer; but when you start an X client program on that computer it has to request and be granted access to your X server). Further, X doesn't "request data" -- the client sends it data, it's a push process not a pull process.
Slashdot Mirror
..in one spot and the problem will rapidly take care of itself.
Well, at least, it won't be plutonium anymore.
Or frequency hopping. Indeed, I don't see why you need a "special card" or a central server, so long as the machines involved can agree on an IP sequence and the timing.
If you wanted to get fancy you could simultaneously assign several IPs and spread the packets amongst them (as well as periodically changing the IPs), to really confuse someone doing traffic analysis.
I'd be seriously worried about any highrise window that couldn't support a mere 230 pounds. Consider that such windows (especially the near-floor to ceiling type) have to be proof against people accidentally falling against them, and even more, proof against pressure differentials (in either direction) caused by high winds. For, say, a 5ft by 5ft window, a mere 1/10th PSI pressure differential gives you 360 pounds of force on the window -- and pressures can be quite a bit higher than this with a good wind.
Now, true enough, windows have been known to pop off of highrises in strong winds (ouch!) but rarely, and that in newer buildings where installation was sloppy.
But this whole suction cup thing has been done in countless movies and old Mission: Impossible episodes using the two-suction-cups-and-a-handle device used for pulling floor tiles in raised-floor computer rooms.
Hi Paul!
Take a look at Cavor (http://sourceforge.net/projects/cavor/). It isn't exactly VISION*, but the overall architecture is similar and that's my model (as much as I can remember, anyway).
Cheers,
-- Alastair
(Another ex-GeoVisioner -- and yes, the architecture beat heck out of what ESRI was peddling back then. I haven't been close enough to it lately to know about now.)
GIS just involves a lot of data
Yep, and it used to be that that data was very expensive -- involving lots of hand labor digitizing maps and aerial photos. That's still true to a certain extent, but much less so.
I've gone from one elegant-but-buggy GIS product (VISION*) to just doing "GIS" by connecting my CAD maps (Microstation) to databases,
I'm curious as to when you were using VISION* and it what context. It's been nearly a decade since my involvement with it (I did a lot of the requirements analysis and design for 2.0 -> 2.1).
And connecting CAD to a database is a nightmare -- I was once involved in converting a hybrid AutoCAD+dBase system to VISION*'s forerunner. Yuck!
Oh, and PS, that bodes ill for Open Source GIS software outside the academic world, because big organizations have a positive fondness for the "Microsofts" of any industry they buy from, and an aversion to "unsupported" products.
Sure, that's AutoDesk (who currently own VISION*) isn't going to be worried about CAVOR. Were I major telco or power company or large regional government I'd go with them for the support, training, handholding, etc. (Heck, when I was with GeoVision we wouldn't talk to anyone with less than a quarter million to spend).
But there's still a niche for open source GIS. Heck, look at the "travel map" software out there -- that's a rather simplistic GIS, to be sure, but it shares common elements. Think of what, say, real estate agents could do with a GIS system.
And beyond that, think of the other application domains that share characteristics with GIS. You mention trying to tie a CAD system and a DB together. How about a CAD system with a built-in DB interface? Or any number of other applications that have both a spatial or graphical aspect and a database aspect -- software diagramming tools (UML, other CASE tools), project management (PERT charts), various sorts of CAD, and so on. (This is part of what the CAVOR project is all about -- I always felt that GeoVision never quite understood the potential of their technology. I once prototyped a CASE tool (DFD's, ERD's and the like) on VISION* in about a day.)
Give folks a free toolkit like that and the uses and applications will come, and they won't all (by a long shot) require gigabytes of data. It's when the tool cost is high that it's only used by those with a lot of data to manage.
One open source project not mentioned is CAVOR, ("Creating A Vision Of Reality" if you insist that stand for something). (See the Cavor project page at SourceForge)
This is primarily the engine for a GIS, the database, graphics display, user interface, scripting, etc, that developers or end-users can further tailor to their specific application. The same engine can be used for other applications that include both a spatial/graphic part and a database part (eg CAD, UML diagrams, PERT charts, etc).
It's still in development -- the display list manager is working (and used in a spin-off, 'cvv'), the database interface and scripting language is in progress.
The architecture is based loosely on GeoVision/SHL/AutoDesk's high end "VISION*" system. (In its time -- before bankruptcy and transfer of the technology to SHL then AutoDesk -- GeoVision pioneered several of the technolgies widely used in GIS systems today, such as storing the spatial data in a relational database.)
The home page is at http://www.cavor.org although I'm not sure the server is up to a slashdot effect.
Whoever marked that as a troll obviously didn't read it, or doesn't understand money, or both.
Sure, MSFT may have had a better earnings/share, but look at their revenue growth: 18% over the last year vs RHAT's 106% growth. Indeed, RHAT had more growth between quarters (20%) than MSFT did all year.
I know where I'd put my money. (Of course, when you're small, it's easier to get large percentage gains. That works against you when you're large. The rolling average (filters out daily fluctuations) on MSFT's share price has been steadily downward for the last year.)
Only if the USPTO has to start paying back the patent registration fees they collected. Preferably with interest and penalties.
There's no incentive for the USPTO to care about prior art -- they get paid more when they issue a patent than when they turn it down, and doing their own search is just added overhead. We'll keep getting these bogus patents until some branch of the government slaps them silly and stops rewarding the practise. (And the PTO operates on the funds it collects, it doesn't just pass it through to the general fund.)
I'm assuming EFF is a 501(c)3 (read 'your contributions are tax deductable') organization. They'd instantly piss away their tax-exempt status if they start giving money to political campaigns, or even just strongly advocating one candidate over another. (Education on the issues, though, is another matter.)
However, donating to the EFF is always a good thing.
I think I see the problem. (Er, no pun intended.)
:)
On my desk as I type this, I have a laptop with a nice, crisp (but jaggy) non-anti-aliased display, and another machine running an older version of Linux and X displayed on a cheap 14" monitor that achieves anti-aliasing but the simple method of having a slightly out-of-focus display. (Dang cheap magnet coils, or something). I can read either at length without bother.
However, when I look at a screen shot of an antialiased display on this nice crisp LCD, it bugs me. I think the problem is that because the rest of the screen has sharp lines and text, my eyes keep trying to bring the AA'd text into focus -- obviously without success. On the CRT, however, the whole screen is "soft focus" so my eyes just give up and go with the flow.
Shrug. As long as it's something I can turn off (by font, perhaps?), I like the idea. Maybe its just that my eyes burned out long ago reading dot-matrix printouts and 80x25 character dumb terminal screens. They expect anything on a monitor to be jaggy
NeWS was based on Display Postscript -- something I believe Apple is doing with MacOS X. X Windows at the time was mostly Version 10.
Like most nostalgia, the wonderous tales you may have heard about NeWS leave out all the gritty bits that people would rather forget. Was it better than X at the time? Possibly -- except that it locked you into Sun. Was it better than the latest version of X as realized by, say, XFree86 4.0.x? No way.
Java compiled to native code (rather than interpreted bytecode) might not be a bad idea. It'll still be a bit slower than badly written C code, because of the internal bounds-checking, but probably about the same as securely-written C.
I say let the compiler do the work, wherever possible. Isn't that the whole point of compilers?
I agree. The problem with BIND prevalence is the problem with any monoculture -- any bug that its susceptible too can take out the whole population.
However, part of the problem is that the RFC's don't quite adequately specify everything, and the prevalence of BIND means that other DNS software has to take BIND's own quirks and interpretations of the specs into account. (Sound familiar? Like dealing with the products of a certain large and widely disliked software company?)
Personally I think anyone running critical services like a DNS ought to not only have hardware backups, but back up software written by different authors. This is (or was, I don't know if they still do) the approach taken in the Space Shuttle computers: five identical computers, four of them running software by one vendor and the fifth, the emergency backup for the emergency backup, running software by a different vendor.
As for myself, I'm switching to djbdns. I don't have the time to keep up with the BIND bug-of-the-month club.
Al Gore.
Just start in asking them "are you making all the money you'd like to make?". This usually gets a confused pause, "uh, no, but.."
Continue on with "let me tell you about a great business opportunity. Ever heard of Amway?"....
(And if you're actually in Amway, who knows, you might pick up another distributer.)
Build a display into a set of contact lenses. Display the irises of the person whom you're pretending to be. Complete with whatever dynamic changes the scanner is looking for to tell a "real" iris from a photograph of one.
Or, on a less insidious level, for the fashion concious: contact lenses that can display funky dynamic patterns.
Hence, you need a display, and some lensing, before dumping the image into a combiner in the main lens.
Yeah, I was thinking the same thing. Neato high-tech X-ray specs just aren't the same thing when they're bulked up like night-vision goggles.
But then I thought...holographic optics. The right interference pattern on a thin film will do the job that a set of lenses would.
Heh. An old girlfriend of mine, less than well-endowed, had one that read Minifloppies.
They weren't really (floppy, that is).
The only way to find it was to dis-assemble the compiler and codewalk the result.
You're assuming that the disassembler wasn't also in on the joke, and that it it wouldn't recognize that it was disassembling the compiler and casually omit the incriminating code. For that matter, you're assuming that the C compiler wasn't smart enough to recognize when it was compiling a disassembler and insert the appropriate code to implement the above.
There are two questions to ask yourself: "am I being paranoid?" and "am I being paranoid enough?".
Yeah, I hacked my C64, I hacked a couple of VIC-20s, built an Apple-II clone, etched my own circuit boards, yadda yadda. Nobody does this anymore because all the chips and components are SMD, the bus frequencies run at multiples of 33MHz (and the CPU is basically a tiny microwave oven), and the circuit board traces are too small and too close together.
Back when the ICs were all DIPs with 0.1" lead spacing, you could tell the resistors and capacitors apart (and tell them from grains of sand) and you could debug the signals with a cheap 10 MHz 'scope, that kind of hardware hacking was fun.
Of course now I'm sounding like my father, grousing about winding his own coils and finding the sweet spot on a galena crystal.
Because Canada is also part of NORAD (NORth American [Air?] Defense). I don't recall all the details of the arrangment, but it goes back to the early cold war days with the setting up of the DEW (Distant Early Warning) line across northern Alaska and Canada, and various other arrangements that had to do mainly with protecting the US from Russian bombers (and later missiles) that might take the direct route over the North Pole and Canada.
There are even a few Canadian officers routinely posted to the NORAD facility in Cheyenne Mountain, although I don't recall seeing any US military in the "Diefenbunker" underground facility north of Ottawa when I was posted there.
All that said, however, there are plenty of US secrets that Canadians don't have access to.
There's also the recognition that the border between the US and Canada is pretty open both to people and information, and that strong encryption can benefit the many companies that do business and have offices in both countries.
... thirteen mortgage payments a year.
Sounds a bit odd to me. The tin foil hat brigade would probably think they were trying to cover something up with that lame explanation. I think they're just being a bit too cavalier (read "incompetent") about the whole process.
Just a very, very short joystick.
I think what he's referring to is the X distinction of "client" and "server." The "X server" is the piece of software that display on, and it renders the data coming from the "X client," which you connect to, and which is actually running the program. This seems like backwards terminology to me
Think of it as "display server" and it starts making more sense. Especially since you can (and frequently do) have multiple X clients displaying to that same display server simultaneously -- although granted usually they are local rather than remote clients in a typical workstation setup.
Wouldn't it be more accurate to describe the rendering portion as a "client," since it connects to another computer, requests data, and renders that data, while the portion which accepts connections, runs programs at request accurately called a "server"?
You're mixing things up here. The rendering portion (X) doesn't connect to another computer, the other computer connects to it. (The confusion may arise if you're using say a telnet client program within X to initiate the connection to the other computer; but when you start an X client program on that computer it has to request and be granted access to your X server). Further, X doesn't "request data" -- the client sends it data, it's a push process not a pull process.