Well.. the US based GSM providers should be able to interoperate using the GSM network, right? Otherewise they're not playing ball with GSM.
From memory, I was able while in the US to send SMS home to New Zealand. (From memory, Verizon and AT&T are two GSM providers over there - it was a while ago, all I do is just pick provider from the on-phone menu - I can't remember..)
Amazingly, in NZ, it's possible (and even trivial) to send a message to and from the GSM provider (Vodafone) to the CDMA and DAMPS networks run by Telecom NZ - there was that much public demand for interoperability.
Heck, I've sent a SMS message to people in Europe using GSM network interconnections from my phone for 20c NZ. (10c US or so).
And, hey, I can send SMS to and from ICQ without any problems. (Handy when I am at the keyboard and I want to msg a friend.)
As for your question, well, that's why T9 predicitve messaging was invented, averaging only slightly more than one keypress per letter. Once it's trained up, it's pretty fast.
It's flawed, simply because those things don't affect me. If somebody posts a copyright violating HTML file on a server I never look at, it doesn't directly waste my time, money or resources.
If they send me annoying email telling me they're doing this, it does.
(And, yes, wasting my time and money and resources because they're being used for something I don't want them to be used for. )
Oh, and subscribe to NTBUGTRAQ. That's pretty much an abosoulte must - heads up as to which patches (like MS 03-010) it might be a good idea to hold off on.
SUS lets the admin specify which patches the workstations are to download and install. It uses the same (more or less) client software as the standard windows auto-update, but you use Group Policies to connect to your own, internal, controlled, server.
And, yes, you *do* need to automatically install the patches, because there's no way several hundred (or more) users are going to install the patches themselves. The Admin just has to test them (or at least, wait for NTBUGTRAQ posts) before setting the server to distribute them.
Install a copy of
Software Update Services and then use group policies to configure your workstations to use and automatically install the patches.
It's a partial solution, while it doesn't upgrade Internet Explorer itself, it *does* apply all relevant patches to IE and the OS.
You do use Group Policies, right? This is one managment area where Windows 2000 out-of-the-box beats any Linux managment system hands down.
Generally.. the patches aren't that important, but notable exceptions exist. (Such as Outlook Express opening certain mime types automatically! - virus writers were quick to take advantage of *that* one..) The problem is that you never quite know which ones are going to be important.
Really, you're arguing that robots.txt is just a special case of "Terms of Use" that you see around the place.
(Don't get me started on the so-called "justice" system.:-)
I would perfer to hope that it becomes accepted knowledge that putting anything on a website is considered publication of that information.. but this could just be idle hope.
Ironically, it takes *more* effort to not "break in" in this case.
Yeah, it's a bit of a strech though, I know.
But, thinking that "reading links on your site that you don't want them to even though you didn't try and stop them is an invasion" is just niaeve and stupid.
This guy is a bit stupid, right?
on
Meet Cyveillancebot
·
· Score: 5, Informative
This guy is a moron, right?
Anyone that has *anything* on a public web server that isn't protected with a username and password (and that isn't very difficult, now, is it?) and they want it kept private is some kind moron.
I mean, I could easily spider his site using wget ignoring his robots.txt.. (For the record, his robots.txt is disalow everyone).
It is, in fact a mechanism for safeguarding content that owners wish to keep private from crawlers.WRONG! It is a mechanism for discouraging crawlers from downloading vast hunks of your site. (Good example: Crawling all of slashdot would be much larger than slashdot itself because of all the different views of comments you can have. That's why the robots.txt of/. discourages spiders in the dynamically generated views.) Yes, in theory he's right, but reality beckons.
Robots.txt is not like locking your door with a weak latch. It's like leaving the door unlocked with a "please behave while inside" sign on it.
Oddly enough, I don't think the police would have much sympathy for anyone who's house got burgled like this...
The way this person talks, it seems that they're currently running a web page containg a java applet.
(If they're not running a web page or at least launched from a web page, the whole damn thing is stupidly moot because users *have to install the viewer application*. If you have to install the viewer application, the same installer can install prerequisites. <rant>Seemingly, the poster is from a (distressingly) large class of programmers where "not writing a web application" is unheard of.)</rant>
So, given they're running in a web page, a SWF in a web page would be supported on all major platforms.
I think IE has a version of Flash already installed. It's certainly possible to get IE to install flash automagcailly. Undoubtably some solution exists for MacOS 9, and I would be mindnummingly shocked if MacOS X couldn't already play SWF's.
Linux / your fav os probably has a plug in that might (or might not) be more tricky to install, but hey, it shouldn't be that hard. You've probably already installed it for other sites anyway.
SWF can talk to databases and back to the server and whatever the heck else - I've seen it done. (look at http://www.cactuslab.com/ - especially the "chat to pedro" - a mate of mine specialises in this sort of thing.) It's also damn fast.. (faster than a Java Applet, that's for sure.) I believe MapServer open-source GIS server has a SWF viewer.
Try out the SWF option; it's not just for homestarrunner.com. If you want,
Otherwise, you're back to DHTML/CSS/Loading rendered PNGs/TIFFs/Whateverelse from the server options.. (If only XUL was feasable..)
I think (but I could be wrong on this) the main reason you would want to use a real sid vs a FPGA emulated one is the real SID chips have analogue components, so for "perfect" emulation you need real SIDs.
I got the impression that the FPGA's do a generally passable SID emulation, but if you're a pureist.:-) (in other words, either FPGA Monster-SID (I think it is called) or a real SID is an option - up to you.)
It seems you're right; note that the CPU is on a seperate board and the system is desinged to allow you to switch it. (And since the main thing the CPU interfaces to is FPGAs, designing a new CPU board is easy because you can reconfigure the FPGAs to match the new CPU.) It also seems the FPGAs do the inteface the CPU to everything else bits as well.
It is still possible to emulate the Atari 2600 or whatever - but it involves switching the processor.
http://www.geocities.com/profdredd/commodoreone/ cm drone.html
It's not entirely clear where the "monster-sid" is located; it seems it's in (one of the two) FPGAs.
Open Core's project list gives a list of cores you can download *right now* under the *GPL* and do stuff with. Shows you the kind of things you can do. (I believe you can combine multiple cores onto one FPGA as well, if they'll fit, and they can intercommunicate.)
I have heard of people talking about a PCI card with a few FPGA's on it; so dedicated programs could download their own accellerator programs to them. It's just an idea at the moment, AFAIK, but hey.
Err, QWK was different from FidoNet. FidoNet was inter-bbs messaging carrying echos (roughly like newsgroups; except that posts had a addressed to user and threads were far more coherent and other differences) and so called NetMail which was a specific user - roughly, email.
QWK was BBS userBBS messaging allowing someone to build a packet of messages to download and read and reply offline, reading both fidonet echos and BBS-local message areas (and other "Fidonet Technology Networks" which used the same software as, but were not, Fidonet.)
QWK was for BBS users; FidoNet was inter-BBS communications. (Although it was possible to be a point on Fido - basically, a complete leaf node that had no dial in users.) Different applications; it would be very common to use QWK to download Fidonet echos that their BBS carried.
Shannon, formerlly 3:772/1175.2 (as I recall; it's been a loooong time.)
In december 2002 Linus said, "At least to me a choice of license by the _original_ author is a hell of a lot more important than the technical legality of then limiting it to just one license."
May I recommend reading the always excellent Kernel Traffic? This particular issue was first delt with here, so it's not news to anyone that reads Kernel Traffic.
Remember that this code was written and maintained by Intel anyway; in fact, any patches done to the code from outside Intel were redone internally by Intel so they could reuse the code for other uses. ("We have to determine the problem the patch fixes and then do the fix ourselves." - from the Kernel Traffic writeup.)
SRAM, or Static RAM is still around. It's just the individual memory cells are a bistable formed from two transistors and other bits and pieces. It has the advantage that data is kept valid and accessable as long as power is applied.
The other option is the cheaper DRAM - where the memory cells are just a capacitor and a transistor. The problem is that the capactior doesn't hold its charge indenfinitly and needs to be refreshed. - It's this need of a refresh that is a pain because it blocks access by other devices, and requires logic circuts.
In a modern PC, cache is typically SRAM, and main core is DRAM.
As for "The olden days of PDAs" - well, Palms use exactly this for their primary storage.
You're right though, a simple battery backed SRAM card would be useful for a lot of situations - especially if an external power supply was available most of the time. (My palm happly keeps 8 MB of such ram valid for months at a time off two AA batteries.)
Of course, if it's read only or infrequently updated then preparing an image on a file and writing that would be a better solution.
I've seen a flash-based embedded system create a ramdisk to store working files - avoids the rewrite the flash issue.
IMHO, Sans serif fonts. Ironically, virtually all web useablity sites fall for this one.
Sans serif fonts are fine for headings, but difficult for body text. The *look* good at first glance - which is why these "web designers" use them, but when you actually sit down and read paragraphs of sans-serif, your eyes will ache and you might not know why.
(Okay, perhaps I'm ranting, but this is my personal experience. It's worse in print - I have a textbook in sans-serif, and it's murder to read!)
Instruction selection isn't that simple - knowing what instructions there are isn't difficult, as that is documented.
But, knowing which instruction would be the fastest in each particular situation, how to organise things to reduce the chance of a cache miss and that sort of thing. So, yes, Intel know more about their chips than anyone else does.
(However, AMD know more about AMD chips than anyone else does...)
The Intel Compilers are not linux specific. They come in both Windows and Linux flavours - and there's nothing stopping you from compiling Moz for Windows using it, afaik.
And, no, I supsect not really. Intel Compilers are designed for number-crunching work - eg: finite element alaysis, engineering simulations, that sort of thing. They perform optimizations designed to improve CPU bound processes. I suspect that interactive / IO bound processes wouldn't be so affected.
Secondly, it depends where the bottleneck is - I could be the runtime linker, or the X-Window system itself or who knows.
Those projects should see some level of improvement, but I wouldn't imagine it's twice as fast. (Things like a paint program might though - as the Intel compilers can take existing "normal" C code and generate SSE and MMX using code.)
A while ago, no. Intel explicitly documented that their C compiler could not compile the Linux kernel because the Linux kernel used a significant amount of gcc-specific functionality. (Specifics of inline keywords, the inline assembly bits interfacing with the c written bits, for example.)
I do not know if this is still true, but I imagine it is.
The Kernel developers use gcc - I wouldn't entirely trust using a different compiler. Besides, there probably isn't a huge performance penality.
I've looked at using the Intel compilers (the have a FORTRAN one) and their main advantage is in number-crunching applications. I suspect the differences aren't so important in interactive / non-crunching applications.
What is common knowledge in New Zealand is that there is some knowledge that Richard Perce may have been the first to fly.
Generally, it's accepted there isn't enough evidence to be sure either way.
It isn't "common knowledge" that he was the first to fly - as that is disputed. That the dispute exists is common knowledge.
For us Kiwi's, there's nothing new here. This ain't news, to us.:-)
(Don't you think a NZ newspaper would break the story if it was news?)
(Of course, as an aside, forgotten silver does "proove" this, as it also "prooves" that we had the first colour cinema film. It's also a brilliently constructed hoax - it suckered me when it first aired.)
NZ'ers believe that he could have been the first, not that he is. I believe if you ask a German who was the first to invent the light bulb, you will get a similar story. (Could someone please tell me?)
Aside from the ban on new second level domains at the moment (Floodgates argument, as a laywer would say), why not? Why not a pakeha.nz? kiwiana.nz? more_than_third_generation_immigrant.nz ?
To a large degree, race and culture are pretty blurry around here - and I wouldn't be too suprised if a member of the Urban Maori couldn't get a.maori.nz domain. The whole Tribal vs Urban issue comes to mind.
Yeah, I was pushing the race line a bit hard, like I said, it's a bugbear with me.
Anyway, the maori.nz domain is one source for the idea for geek.nz, as I understand it, came from..maori.nz SLD is purely for a cultual group and could overlap other SLDs (A Maori business venture 'belongs' in.maori.nz or.co.nz? Or both?) Therefore, geek.nz has just as equal right to exist, so why shouldn't it? Why should one cultural group get their own SLD and not this one?
This could easily get way off topic into the whole issue of Race Relations - and that is a rather murky and large issue that we (as a country) have to deal with.
Slashdot Mirror
Well.. the US based GSM providers should be able to interoperate using the GSM network, right? Otherewise they're not playing ball with GSM.
From memory, I was able while in the US to send SMS home to New Zealand. (From memory, Verizon and AT&T are two GSM providers over there - it was a while ago, all I do is just pick provider from the on-phone menu - I can't remember..)
Amazingly, in NZ, it's possible (and even trivial) to send a message to and from the GSM provider (Vodafone) to the CDMA and DAMPS networks run by Telecom NZ - there was that much public demand for interoperability.
Heck, I've sent a SMS message to people in Europe using GSM network interconnections from my phone for 20c NZ. (10c US or so).
And, hey, I can send SMS to and from ICQ without any problems. (Handy when I am at the keyboard and I want to msg a friend.)
As for your question, well, that's why T9 predicitve messaging was invented, averaging only slightly more than one keypress per letter. Once it's trained up, it's pretty fast.
That guy from Star Wars playing a slightly renegade coenel with an anti-authority streak in the Terran Confediation..
...
And yeah.. Malcom Macdowell... and that guy from Back to The Future... and perhaps even that company that did the Muppets to do some puppeteering..
Perhaps.. even... Part of the famous Wing Commander Series?
Oh
wait...
ummm...
It's flawed, simply because those things don't affect me. If somebody posts a copyright violating HTML file on a server I never look at, it doesn't directly waste my time, money or resources.
If they send me annoying email telling me they're doing this, it does.
(And, yes, wasting my time and money and resources because they're being used for something I don't want them to be used for. )
Like I said, use software update services. :-)
Oh, and subscribe to NTBUGTRAQ. That's pretty much an abosoulte must - heads up as to which patches (like MS 03-010) it might be a good idea to hold off on.
SUS lets the admin specify which patches the workstations are to download and install. It uses the same (more or less) client software as the standard windows auto-update, but you use Group Policies to connect to your own, internal, controlled, server.
And, yes, you *do* need to automatically install the patches, because there's no way several hundred (or more) users are going to install the patches themselves. The Admin just has to test them (or at least, wait for NTBUGTRAQ posts) before setting the server to distribute them.
Secondly... sounds awfully odd on that network.
Install a copy of Software Update Services and then use group policies to configure your workstations to use and automatically install the patches.
It's a partial solution, while it doesn't upgrade Internet Explorer itself, it *does* apply all relevant patches to IE and the OS.
You do use Group Policies, right? This is one managment area where Windows 2000 out-of-the-box beats any Linux managment system hands down.
Generally.. the patches aren't that important, but notable exceptions exist. (Such as Outlook Express opening certain mime types automatically! - virus writers were quick to take advantage of *that* one..) The problem is that you never quite know which ones are going to be important.
Thankfully, US Case Law isn't binding on me, yet.
:-)
Really, you're arguing that robots.txt is just a special case of "Terms of Use" that you see around the place.
(Don't get me started on the so-called "justice" system.
I would perfer to hope that it becomes accepted knowledge that putting anything on a website is considered publication of that information.. but this could just be idle hope.
Ironically, it takes *more* effort to not "break in" in this case.
Yeah, it's a bit of a strech though, I know.
But, thinking that "reading links on your site that you don't want them to even though you didn't try and stop them is an invasion" is just niaeve and stupid.
This guy is a moron, right?
/. discourages spiders in the dynamically generated views.) Yes, in theory he's right, but reality beckons.
Anyone that has *anything* on a public web server that isn't protected with a username and password (and that isn't very difficult, now, is it?) and they want it kept private is some kind moron.
I mean, I could easily spider his site using wget ignoring his robots.txt.. (For the record, his robots.txt is disalow everyone).
It is, in fact a mechanism for safeguarding content that owners wish to keep private from crawlers. WRONG! It is a mechanism for discouraging crawlers from downloading vast hunks of your site. (Good example: Crawling all of slashdot would be much larger than slashdot itself because of all the different views of comments you can have. That's why the robots.txt of
Robots.txt is not like locking your door with a weak latch. It's like leaving the door unlocked with a "please behave while inside" sign on it.
Oddly enough, I don't think the police would have much sympathy for anyone who's house got burgled like this...
The way this person talks, it seems that they're currently running a web page containg a java applet.
(If they're not running a web page or at least launched from a web page, the whole damn thing is stupidly moot because users *have to install the viewer application*. If you have to install the viewer application, the same installer can install prerequisites. <rant>Seemingly, the poster is from a (distressingly) large class of programmers where "not writing a web application" is unheard of.)</rant>
So, given they're running in a web page, a SWF in a web page would be supported on all major platforms.
I think IE has a version of Flash already installed. It's certainly possible to get IE to install flash automagcailly. Undoubtably some solution exists for MacOS 9, and I would be mindnummingly shocked if MacOS X couldn't already play SWF's.
Linux / your fav os probably has a plug in that might (or might not) be more tricky to install, but hey, it shouldn't be that hard. You've probably already installed it for other sites anyway.
SWF can talk to databases and back to the server and whatever the heck else - I've seen it done. (look at http://www.cactuslab.com/ - especially the "chat to pedro" - a mate of mine specialises in this sort of thing.) It's also damn fast.. (faster than a Java Applet, that's for sure.) I believe MapServer open-source GIS server has a SWF viewer.
Try out the SWF option; it's not just for homestarrunner.com. If you want,
Otherwise, you're back to DHTML/CSS/Loading rendered PNGs/TIFFs/Whateverelse from the server options.. (If only XUL was feasable..)
Interesting; it wasn't all that easy to clearly see the startup sequence for the whole system. (All the various things getting loaded at startup.)
Thanks.
Such cards do exist? Yay bananas!
I recall reading that too.
:-) (in other words, either FPGA Monster-SID (I think it is called) or a real SID is an option - up to you.)
I think (but I could be wrong on this) the main reason you would want to use a real sid vs a FPGA emulated one is the real SID chips have analogue components, so for "perfect" emulation you need real SIDs.
I got the impression that the FPGA's do a generally passable SID emulation, but if you're a pureist.
It seems you're right; note that the CPU is on a seperate board and the system is desinged to allow you to switch it. (And since the main thing the CPU interfaces to is FPGAs, designing a new CPU board is easy because you can reconfigure the FPGAs to match the new CPU.) It also seems the FPGAs do the inteface the CPU to everything else bits as well.
/ cm drone.html
:-)
It is still possible to emulate the Atari 2600 or whatever - but it involves switching the processor.
http://www.geocities.com/profdredd/commodoreone
It's not entirely clear where the "monster-sid" is located; it seems it's in (one of the two) FPGAs.
I think. Unless I'm rong.
Yep, if SETI@Home cared to release such code.
Open Core's project list gives a list of cores you can download *right now* under the *GPL* and do stuff with. Shows you the kind of things you can do. (I believe you can combine multiple cores onto one FPGA as well, if they'll fit, and they can intercommunicate.)
I have heard of people talking about a PCI card with a few FPGA's on it; so dedicated programs could download their own accellerator programs to them. It's just an idea at the moment, AFAIK, but hey.
Err, QWK was different from FidoNet. FidoNet was inter-bbs messaging carrying echos (roughly like newsgroups; except that posts had a addressed to user and threads were far more coherent and other differences) and so called NetMail which was a specific user - roughly, email.
QWK was BBS userBBS messaging allowing someone to build a packet of messages to download and read and reply offline, reading both fidonet echos and BBS-local message areas (and other "Fidonet Technology Networks" which used the same software as, but were not, Fidonet.)
QWK was for BBS users; FidoNet was inter-BBS communications. (Although it was possible to be a point on Fido - basically, a complete leaf node that had no dial in users.) Different applications; it would be very common to use QWK to download Fidonet echos that their BBS carried.
Shannon, formerlly 3:772/1175.2 (as I recall; it's been a loooong time.)
In december 2002 Linus said,
"At least to me a choice of license by the _original_ author is a hell of a lot more important than the technical legality of then limiting it to just one license."
May I recommend reading the always excellent Kernel Traffic? This particular issue was first delt with here, so it's not news to anyone that reads Kernel Traffic.
Remember that this code was written and maintained by Intel anyway; in fact, any patches done to the code from outside Intel were redone internally by Intel so they could reuse the code for other uses. ("We have to determine the problem the patch fixes and then do the fix ourselves." - from the Kernel Traffic writeup.)
Then don't contribute to the ACPI code, write your own version that's GPL only or whatever.
Remember that Intel wrote this code, they can do what they damn well want with it.
SRAM, or Static RAM is still around. It's just the individual memory cells are a bistable formed from two transistors and other bits and pieces. It has the advantage that data is kept valid and accessable as long as power is applied.
The other option is the cheaper DRAM - where the memory cells are just a capacitor and a transistor. The problem is that the capactior doesn't hold its charge indenfinitly and needs to be refreshed. - It's this need of a refresh that is a pain because it blocks access by other devices, and requires logic circuts.
In a modern PC, cache is typically SRAM, and main core is DRAM.
As for "The olden days of PDAs" - well, Palms use exactly this for their primary storage.
You're right though, a simple battery backed SRAM card would be useful for a lot of situations - especially if an external power supply was available most of the time. (My palm happly keeps 8 MB of such ram valid for months at a time off two AA batteries.)
Of course, if it's read only or infrequently updated then preparing an image on a file and writing that would be a better solution.
I've seen a flash-based embedded system create a ramdisk to store working files - avoids the rewrite the flash issue.
IMHO, Sans serif fonts. Ironically, virtually all web useablity sites fall for this one.
Sans serif fonts are fine for headings, but difficult for body text. The *look* good at first glance - which is why these "web designers" use them, but when you actually sit down and read paragraphs of sans-serif, your eyes will ache and you might not know why.
(Okay, perhaps I'm ranting, but this is my personal experience. It's worse in print - I have a textbook in sans-serif, and it's murder to read!)
Instruction selection isn't that simple - knowing what instructions there are isn't difficult, as that is documented.
But, knowing which instruction would be the fastest in each particular situation, how to organise things to reduce the chance of a cache miss and that sort of thing. So, yes, Intel know more about their chips than anyone else does.
(However, AMD know more about AMD chips than anyone else does...)
The Intel Compilers are not linux specific. They come in both Windows and Linux flavours - and there's nothing stopping you from compiling Moz for Windows using it, afaik.
And, no, I supsect not really. Intel Compilers are designed for number-crunching work - eg: finite element alaysis, engineering simulations, that sort of thing. They perform optimizations designed to improve CPU bound processes. I suspect that interactive / IO bound processes wouldn't be so affected.
Secondly, it depends where the bottleneck is - I could be the runtime linker, or the X-Window system itself or who knows.
Those projects should see some level of improvement, but I wouldn't imagine it's twice as fast. (Things like a paint program might though - as the Intel compilers can take existing "normal" C code and generate SSE and MMX using code.)
A while ago, no. Intel explicitly documented that their C compiler could not compile the Linux kernel because the Linux kernel used a significant amount of gcc-specific functionality. (Specifics of inline keywords, the inline assembly bits interfacing with the c written bits, for example.)
I do not know if this is still true, but I imagine it is.
The Kernel developers use gcc - I wouldn't entirely trust using a different compiler. Besides, there probably isn't a huge performance penality.
I've looked at using the Intel compilers (the have a FORTRAN one) and their main advantage is in number-crunching applications. I suspect the differences aren't so important in interactive / non-crunching applications.
-
-
You misunderstand.
:-)
What is common knowledge in New Zealand is that there is some knowledge that Richard Perce may have been the first to fly.
Generally, it's accepted there isn't enough evidence to be sure either way.
It isn't "common knowledge" that he was the first to fly - as that is disputed. That the dispute exists is common knowledge.
For us Kiwi's, there's nothing new here. This ain't news, to us.
(Don't you think a NZ newspaper would break the story if it was news?)
(Of course, as an aside, forgotten silver does "proove" this, as it also "prooves" that we had the first colour cinema film. It's also a brilliently constructed hoax - it suckered me when it first aired.)
NZ'ers believe that he could have been the first, not that he is. I believe if you ask a German who was the first to invent the light bulb, you will get a similar story. (Could someone please tell me?)
AIR = As I Recall. Subsustute that phrase in and it should make more sense. :-)
/. comes from that world. :-)
Sorry, habit from old-school BBS days - I guess not everyone on
Aside from the ban on new second level domains at the moment (Floodgates argument, as a laywer would say), why not? Why not a pakeha.nz? kiwiana.nz? more_than_third_generation_immigrant.nz ?
.maori.nz domain. The whole Tribal vs Urban issue comes to mind.
.maori.nz SLD is purely for a cultual group and could overlap other SLDs (A Maori business venture 'belongs' in .maori.nz or .co.nz? Or both?) Therefore, geek.nz has just as equal right to exist, so why shouldn't it? Why should one cultural group get their own SLD and not this one?
To a large degree, race and culture are pretty blurry around here - and I wouldn't be too suprised if a member of the Urban Maori couldn't get a
Yeah, I was pushing the race line a bit hard, like I said, it's a bugbear with me.
Anyway, the maori.nz domain is one source for the idea for geek.nz, as I understand it, came from.
This could easily get way off topic into the whole issue of Race Relations - and that is a rather murky and large issue that we (as a country) have to deal with.