>I am sorry but to me, really, Doom was just the >"step up" from Wolfenstein, nothing revolutionary.
...while Wolfenstein was in turn one step forward and two steps back from Castle Wolfenstein, circa 1984.
The step forward: moving from top-down map view to 3D first person shooter made the game feel much more immediate. Besides, at that time 3D, any kind of 3D, was just cool.
The steps back: in Castle Wolfenstein you needed a lot more stealth and cunning. For instance, if you found a german uniform and put it on you could fool most regular soldiers and just walk right by them (don't get too close though!). With the addition of some war medals you might even be able to fool the dreaded SS (again, don't get too close or act strange). Once you got the SS on your tail it was almost impossible to lose them, they just didn't give up. You could usually outrun them, but they would always catch up. Killing was the real way to make your self safe. However the more bodies you left lying around, the less likely your pilfered uniform (and inability to speak german) was likely to fool anybody.
And finally, you weren't just trying to escape Castle Wolfenstein, you were attempting to assinate Hitler and his top officials. This required:
getting a uniform,
getting medals,
acquiring an SS uniform,
pilfering some SS medals,
some other stuff I don't remember,
filling a briefcase full of explosives (which you had to find first),
attending the meeting of the top brass,
arming the briefcase bomb
hightailing it out of the castle before all hell broke loose.
Better said: technology relative to the data is easy, from our current place in GIS development. {Aside} As we refine our GIS technologies move into areas focussed more on the relationships between data nodes/collections the technology gets much more complicated. However, in the main, I agree with you, the data is hard.{/aside}
The data side of GIS is even harder for those who live outside the US and New Zealand. Most countries have placed cost recovery principles at the forefront of their geospatial data distribution polices. From an economic perspective this seems to make a lot of sense, building quality GIS data is *expensive* and recovering some of that expense is an attractive idea. However in practice it doesn't really work, at least not here in Canada, the area I am familiar with.
What happens in reality is that only big corporations and government have deep enough pockets to afford the data, so the smaller organizations either attempt to recreate it themselves (at varying levels of quality) or do without it. Then another project comes along which needs both datasets and the data has to be re-worked *again* in order to make the two datasets match each other. Of course so much money and effort goes into this data massage that nobody wants to give all that work away... and so the cycle repeats, bleeding money with every spin.
The other arm of this cost recovery pincer is the use and distribution license terms.
In order to keep charging for the data, users must not be able to redistribute the data. So if I use a watercourse described in the Canadian National Topographic Database digital base as a boundary polygon for my own data, under the terms of the NTDB license agreement I would not be able to distribute that boundary to anybody (eith or without a monetary transaction) without paying a royalty to Geomativcs Canada since the enduser would be able to extract the coordinate pairs from my poly boundary and recreate the original (copyrighted) NTDB watercourse.
Add to this recipe that the premier users of GIS data are governments it means that, in the Canadian case, tax dollars paid for the data collection in the first place, and then tax dollars are used again to allow other governments, and other branches of the same government, to use the data. The result is no cost recovery taking place.
Anyway, this is all an introduction as to why the The Canadian Free Geospatial Data Committee was created. There is a petition to help Geomatics Canada change their distribution policies as well as a comments page. If this issue interests you please visit the site and share your views.
-matt
>Really, I wish the GRASS project were moving faster (or moving at all).
It is moving, there is even a Cygwin version nearing the beta stage. You just have to watch the mailing list, also the European website is usually more up to date than the North American one.
>So if you want to open one of those, now standard file types, better be prepared to pony up some real cash.
There are libraries and utilities which allow you read and write native ArcInfo file formats. The best place to start looking at these is on FreeGIS.org in the conversion tools and libraries sections.
-matt
Minor correction: version 5 of GRASS was released under the GPL last November (1999). GRASS v0 - 4.x is public domain (still under minor development, mostly bug fixing).
Maybe old news for you, but this is the first I've heard of IPW (thanks for the link) and I try to keep an eye on these things. RS.org also hosts LIMP - Large Image Manipulation Project - which is not to be confused with LIMP - the Linux Montage Project. GRASS has already been mentioned, and there is also SPRING, TOPOG (almost but not quite Free Software) and OpenMap.
Another good place in addition to remotesensing.org to keep an eye on Libre RS/GIS software development and data is freegis.org.
Referring to your OT question, a few months ago I ran across a research project on this. In a nutshell, they are building a mainframe-like computer out of the reject commodity parts from the manufacturing plants.
On first boot the OS goes through and checks each chip/component piece by piece for reliability. If unreliable, it tries to assess exactly how/where it is unreliable and routes around the problems. The first boot and diagnose process takes about a week!
The end result is very reliable large computer (64 CPUs, IIRC) with awesome failover capabilities (since dealing with broken hardware is integral to the whole system). I don't remember the figures, but it was something like the final running computer might have %30 or 40% broken parts.
Oh and don't forget the bit about 'commodity parts' - broken cheap IBM clone hardware.
I'm sorry I can't give you a link, I'm not at home and my net connection is too slow/unreliable for search for it. However, the project is funded at least in part by HP and it is hosted at a university (Sanford? Cornell?).
They do have a working prototype, though which definition of "working" they are using... I'm in no position do judge. Cool pictures though. Cool project too.
Try the Map Server section at dmoz.org for a list o' links.
If you are a developer look at these OGDI specs, and this library for reading shape files which might work well with some of the toolkits listed at freegis.org.
You should also cross post this question to the GRASS (grasslist@baylor.edu) and Remotesensing.org (osrs@remotesensing.org) mailing lists.
I like slashdot and I spend a lot of time here, too much!:) One of the ideas I've played with, but lack the skills to implement is a kind of summary or synopsis of the slashdot comments on a story by story basis, and then on a theme by theme basis.
I figure this could be done initially and crudely using simple word count searches: index all words (skipping "the,and,a" etc.)in a forum and build a histogram. This by itself would be only so-so interesting, but if you expand it to include immediately adjacent words it gets more interesting. Think of a more developed and refined Operating System Sucks-Rules-O-Meter. And then two neighbouring words, etc.
Why is this interesting? Because it would be the closest thing to describing what the slashdot community as whole thinks. The meta-slashdot would be a sort of ongoing ballot or poll.
Although I've only mentioned Slashdot, there's no reason the same technique couldn't be brought to bear on any discussion group.
I originally tried to put this in my own words, but I just couldn't do it any better than Jakob Nielson, so here's his take on this issue (his emphasis):
"The "paradox of the active user" is a concept introduced by John M. Carroll and Mary Beth Rosson (then at IBM, now at Virginia Tech) to explain a common observation in several user studies done at the IBM User Interface Institute in the early 1980s (later confirmed by many other studies, including my own): Users never read manuals but start using the software immediately. They are motivated to get started and to get their immediate task done: they don't care about the system as such and don't want to spend time up front on getting established, set up, or going through learning packages.
The "paradox of the active user" [PDF,66k] is a paradox because users would save time in the long term by taking some initial time to optimize the system and learn more about it. But that's not how people behave in the real world, so we cannot allow engineers to build products for an idealized rational user when real humans are irrational: we must design for the way users actually behave."
The paper is old, but still very relevant. It was written before GooeyTarbabies achieved World Domination. I was really surprised to discover that many of my current user interface issues have actually been thoroughly documented and processes for (potentially) surmounting them outlined.
Why is it that since we've known about this for so long, so little apparent progress has been made? My short 2bit answer is the evil upgrade treadmill - everybody is so busy preparing for and researching the Next Big Thing, they don't have time to refine and polish the tools already under our noses.
I can't see how copyright would not be the issue, it's pretty a pretty blatant violation when you start copying other websites content and stick it on yours.
I can see that argument if you surrounded their page in a frame, or replaced their banners with yours, or something which somehow makes it unclear who the real owner/producer of the page is.
How about a script or program which:
-caches the linked page when the story is first posted -periodically checks the page for response time -if $lag > $unbearable then serve cached page with an inserted headline which says "the host server http://blahblah appears to be/.ttd. You are veiwing a cached page, it may not be up to date. Click here to try and fetch the original."
This way the big companies would host their own material (the assumption being they have enough money to have bigass servers and don't need to be cached) and only the little guy with the cool make-your-own-transmeta-chip page who actually _needs_ to get cached, will get cached.
To answer your question, there are two main reasons why this shouldn't be done. 1: Copyright could be infringed on the pages being cached
Okay, that makes a certain amount of sense and I can understand being cautious, but caching makes the web go around. It's already pervasive, or so I was given to understand. As another poster mentioned, what about Google?
I guess the size of the financial club is often more relevant than the technical legality of a something. {sigh}
2: Many sites get their revenue from click throughs and banner ads. If/. mirrors the info, are they going to mirror the banner ads as well?
Wouldn't bother me personally, I never seem 'em anyway, I use Junkbuster or turn autoloading images off. It's amazing how much more responsive surfing is then.:)
I found this discussion waaay too late for anybody to see this, but I'll post it anyway for my own satisfaction.:)
Could mainframe linux enable mainframe NT?
Install linux into a mainframe VM, then install VMWare under the linux host, then install NT under that.
It's sufficiently recursive to make me smile if nothing else. And we haven't even talked about squeezing Transmeta codemorphing in there somewhere. {chuckle}
Karma should decay. If I haven't posted anything of note, I should lose a point every 3 days.
Nope. I can't agree with this one. People should be encouraged to be thoughtful and only post when they truly have something to say. A karma decay as you've described it would encourage continous posting simply to keep your slashdot account "alive".
>at the command line, getting crap like RTFM (when, in fact, there is >no definitive M), and trying to configure ridiculously obfuscated >network settings, I'm ready to go back to windows.
You need to get over the hump; bro. A lot of your problem is probably learning where the docs are (they're there a plenty, just not in an expensively bound, nicely printed manual). You've also got to expect to pay some dues and learning how a different system works.
I'm in the position of the first poster, but not quite as disheartened (yet). While your response is meant to be encouraging (and it is), it would be even more cheering if it was informative. Eg. the FM is 'right here'. That you couldn't point to a location in your response is a concise illustration of the problem itself.:)
Anyway, I'm confident that the passage of time and a few million eyballs and few thousand hands documenting the eyeball travails will alleviate the situation. It's just that "instant gratification" is sufficiently engrained in me that I don't want to wait. {smiles}
Slashdot Mirror
>I am sorry but to me, really, Doom was just the
>"step up" from Wolfenstein, nothing revolutionary.
...while Wolfenstein was in turn one step forward and two steps back from Castle Wolfenstein, circa 1984.
The step forward: moving from top-down map view to 3D first person shooter made the game feel much more immediate. Besides, at that time 3D, any kind of 3D, was just cool.
The steps back: in Castle Wolfenstein you needed a lot more stealth and cunning. For instance, if you found a german uniform and put it on you could fool most regular soldiers and just walk right by them (don't get too close though!). With the addition of some war medals you might even be able to fool the dreaded SS (again, don't get too close or act strange). Once you got the SS on your tail it was almost impossible to lose them, they just didn't give up. You could usually outrun them, but they would always catch up. Killing was the real way to make your self safe. However the more bodies you left lying around, the less likely your pilfered uniform (and inability to speak german) was likely to fool anybody.
And finally, you weren't just trying to escape Castle Wolfenstein, you were attempting to assinate Hitler and his top officials. This required:
GRASS IS GPLed for years now
Minor correction: version 5 of GRASS was released under the GPL last November (1999). GRASS v0 - 4.x is public domain (still under minor development, mostly bug fixing).
Maybe old news for you, but this is the first I've heard of IPW (thanks for the link) and I try to keep an eye on these things. RS.org also hosts LIMP - Large Image Manipulation Project - which is not to be confused with LIMP - the Linux Montage Project. GRASS has already been mentioned, and there is also SPRING, TOPOG (almost but not quite Free Software) and OpenMap.
Another good place in addition to remotesensing.org to keep an eye on Libre RS/GIS software development and data is freegis.org.
I've long been wanting to check out Trinity, made by the some of the same people who were instrumental in developing the Amiga Video Toaster.
The base package is only ~$8k usd which is damn near affordable even for a hobbyist.
Referring to your OT question, a few months ago I ran across a research project on this. In a nutshell, they are building a mainframe-like computer out of the reject commodity parts from the manufacturing plants.
On first boot the OS goes through and checks each chip/component piece by piece for reliability. If unreliable, it tries to assess exactly how/where it is unreliable and routes around the problems. The first boot and diagnose process takes about a week!
The end result is very reliable large computer (64 CPUs, IIRC) with awesome failover capabilities (since dealing with broken hardware is integral to the whole system). I don't remember the figures, but it was something like the final running computer might have %30 or 40% broken parts.
Oh and don't forget the bit about 'commodity parts' - broken cheap IBM clone hardware.
I'm sorry I can't give you a link, I'm not at home and my net connection is too slow/unreliable for search for it. However, the project is funded at least in part by HP and it is hosted at a university (Sanford? Cornell?).
They do have a working prototype, though which definition of "working" they are using... I'm in no position do judge. Cool pictures though. Cool project too.
cheers,
-matt
I just had to tell you your tagline tickled my its-funny-and-also-true bone. cheers, -matt
Interestingly, on another thread today I found a site for the Vector Markup Language which looks promising.
The same conversation also lead to the university of Leicester's Virtual Field Course
Try the Map Server section at dmoz.org for a list o' links.
If you are a developer look at these OGDI specs, and this library for reading shape files which might work well with some of the toolkits listed at freegis.org.
You should also cross post this question to the GRASS (grasslist@baylor.edu) and Remotesensing.org (osrs@remotesensing.org) mailing lists.
cheers,
-matt
I like slashdot and I spend a lot of time here, too much! :) One of the ideas I've played with, but lack the skills to implement is a kind of summary or synopsis of the slashdot comments on a story by story basis, and then on a theme by theme basis.
I figure this could be done initially and crudely using simple word count searches: index all words (skipping "the,and,a" etc.)in a forum and build a histogram. This by itself would be only so-so interesting, but if you expand it to include immediately adjacent words it gets more interesting. Think of a more developed and refined Operating System Sucks-Rules-O-Meter. And then two neighbouring words, etc.
Why is this interesting? Because it would be the closest thing to describing what the slashdot community as whole thinks. The meta-slashdot would be a sort of ongoing ballot or poll.
Although I've only mentioned Slashdot, there's no reason the same technique couldn't be brought to bear on any discussion group.
-matt
I originally tried to put this in my own words, but I just couldn't do it any better than Jakob Nielson, so here's his take on this issue (his emphasis):
"The "paradox of the active user" is a concept introduced by John M. Carroll and Mary Beth Rosson (then at IBM, now at Virginia Tech) to explain a common observation in several user studies done at the IBM User Interface Institute in the early 1980s (later confirmed by many other studies, including my own): Users never read manuals but start using the software immediately. They are motivated to get started and to get their immediate task done: they don't care about the system as such and don't want to spend time up front on getting established, set up, or going through learning packages.
The "paradox of the active user" [PDF,66k] is a paradox because users would save time in the long term by taking some initial time to optimize the system and learn more about it. But that's not how people behave in the real world, so we cannot allow engineers to build products for an idealized rational user when real humans are irrational: we must design for the way users actually behave."
Source: http://www.useit.com/alertbox/ activeuserparadox.html
The paper is old, but still very relevant. It was written before Gooey Tarbabies achieved World Domination. I was really surprised to discover that many of my current user interface issues have actually been thoroughly documented and processes for (potentially) surmounting them outlined.
Why is it that since we've known about this for so long, so little apparent progress has been made?
My short 2bit answer is the evil upgrade treadmill - everybody is so busy preparing for and researching the Next Big Thing, they don't have time to refine and polish the tools already under our noses.
thanks
Will somebody please define what "reverse caching" is?
thanks
-matt
thanks!
For onlookers: The link is here.
And it doesn't say anything about copyright, just time and money (isn't it always?).
-matt
I can't see how copyright would not be the issue, it's pretty a pretty blatant violation when you start copying other websites content and stick it on yours.
/.ttd. You are veiwing a cached page, it may not be up to date. Click here to try and fetch the original."
I can see that argument if you surrounded their page in a frame, or replaced their banners with yours, or something which somehow makes it unclear who the real owner/producer of the page is.
How about a script or program which:
-caches the linked page when the story is first posted
-periodically checks the page for response time
-if $lag > $unbearable then serve cached page with an inserted headline which says "the host server http://blahblah appears to be
This way the big companies would host their own material (the assumption being they have enough money to have bigass servers and don't need to be cached) and only the little guy with the cool make-your-own-transmeta-chip page who actually _needs_ to get cached, will get cached.
Is there some reason this wouldn't work?
-matt
> Tangenital
ick
{chuckle}
To answer your question, there are two main reasons why this shouldn't be done.
1: Copyright could be infringed on the pages being cached
Okay, that makes a certain amount of sense and I can understand being cautious, but caching makes the web go around. It's already pervasive, or so I was given to understand. As another poster mentioned, what about Google?
I guess the size of the financial club is often more relevant than the technical legality of a something. {sigh}
2: Many sites get their revenue from click throughs and banner ads. If
Wouldn't bother me personally, I never seem 'em anyway, I use Junkbuster or turn autoloading images off. It's amazing how much more responsive surfing is then.
-matt
Tangenital topic: /. effect.
At least once per story, somebody suggests that slashdot cache or mirror sites they link to in order to avoid the dreaded
I have yet to hear an explanation of why this might not be a good idea. Anybody out there have one?
(honest question)
I found this discussion waaay too late for anybody to see this, but I'll post it anyway for my own satisfaction. :)
Could mainframe linux enable mainframe NT?
Install linux into a mainframe VM,
then install VMWare under the linux host,
then install NT under that.
It's sufficiently recursive to make me smile if nothing else. And we haven't even talked about squeezing Transmeta codemorphing in there somewhere. {chuckle}
hey thanks! (pun intended) I didn't know about 'apropos', I will assuredly check it out.
/etc)
WRT to #3: agreed, but first you have to *find* the configuration files which took me awhile.
(for the onlookers: look in
-matt
Karma should decay. If I haven't posted anything of note, I should lose a point every 3 days.
Nope. I can't agree with this one. People should be encouraged to be thoughtful and only post when they truly have something to say. A karma decay as you've described it would encourage continous posting simply to keep your slashdot account "alive".
You need to get over the hump; bro. A lot of your problem is probably learning where the docs are (they're there a plenty, just not in an expensively bound, nicely printed manual). You've also got to expect to pay some dues and learning how a different system works.
I'm in the position of the first poster, but not quite as disheartened (yet). While your response is meant to be encouraging (and it is), it would be even more cheering if it was informative. Eg. the FM is 'right here'. That you couldn't point to a location in your response is a concise illustration of the problem itself.
Anyway, I'm confident that the passage of time and a few million eyballs and few thousand hands documenting the eyeball travails will alleviate the situation. It's just that "instant gratification" is sufficiently engrained in me that I don't want to wait. {smiles}
-matt
with a last updated stamp of 01/01/97.
In light of the recent DoS stories I thought this might be interesting to some people.
with a last updated stamp of 01/01/97.
I'd rather Apple/Englightenment/KDE[/Gnome] spent their energy in developing a more usable *interface* than a prettier one.
This point needs to be emphasized. Many times.