Probably the only thing alive is afilias.info AKA nic.info.
It's just beyond my comprehension why a TLD this general should have its registry in the domain itself...
(The same way, that the impossible.sex domain should not have its registry at thesexregistry.sex.. It would be quite sufficient to have a "pornia.com the dot sex registry" etc...) Clean up this mess of everyone "reserving" domains "'cause it sounds/looks good"...
Dr. Pier Oddone... Hands up, who believed this story anyway with that name?
(Me, I'm just minutes after seeing Dr. Strangelove...)
Re:Sounds like a good idea, but..
on
The Dot in .mars
·
· Score: 2
.. I can't really think of a practical purpose for it, except for perhaps e-mail...
Yes, in the light of more than a few seconds turnaround (basically anything in space further away than the Moon), nothing but email would survive as a communication form. It is however, very suited for much larger delays too, I have some unanswered email in my inbox dating back a few years... (I mean to reply soon...).
OTOH, nothing prevents us to come up with something email like, but utilizing video technology.. Sending a new message is trivial, just press record, and at the end, stop it, the interesting bit comes when replying. I hope MS dies when we need this tech, or you'll see "Original message follows" at the end of your partner's video, and you can see your own again:)
Seriously, imagine a better way, you see your girlfriends face as she hears your message, she pauses, and tells the stories, and then unpauses to go on..
Of course, the personal communications are not the single form you need from Mars (and obviously, in the first years, we won't have any), but most of it can be reduced to a form of offline, spooled data transfer. UUCP anyone? It (or some flashback of it) is very easily suited for bulk, offline data transfer. You could just program the local machinery to transfer data to be sent to a central spool machine, which then sends it away to Earth (or Pluto, for that matter). It's not internet, really, but IP need not be thrown away; and locally (ie. on Mars), TCP/IP is just as efficient, and well-working as here for us.
For the real bulk transfer, something else would be needed than TCP, imagine that any missed packet can get reported only many minutes later, and you don't want to restart the connection then.. Add a bit forward error correction, and large buffering to cope with minutes (millions) of un-acked packets, and here we go.
Shall I work on this, or let your billions of tax dollars work on this for a few years to get this built?:)
Well, I'm not quite sure that dangerous is the right word, but it's the same stuff "we" don't like about the progress and commercialization of services. Just imagine, you don't get the details of a security flaw, just a notice of it, and if they decide that it's bigger than they thought, they simply revoke the info on the web page. The first hundred visitor is then threatened to not distribute the former version.
Convenient for the companies, but useless for "us". Why do the need to rely on power games every time? Let them get a clue. (cluetrain.com anyone?)
Fine, then wait a bit for the comments outside of the two coasts..
Seriously, I don't regard myself as an anarchist, but I don't think an established power should control the future, and noone should be able to escape and build something better. As a quite stretched example, how useful is money, and the concepts of "owning" music copyright to thousands of people travelling to a star system far away?
The question I have is: Is it OK to tape a song played on the radio and then distribute it? It seems to be public domain.
Not public domain, but others told you that already.
On the other hand, it's even more limited than you think. To play music, radio stations pay a sum depending how many they play in a month to an agency that supposedly distributes this to the artists. What the artists get, is very rarely comparable to a real income. What's more, when buying a tape, you pay a tax decided much earlier to cover for the costs of copying copyrighted material to that tape (that's why "audio" CDR's have a larger price too.)
At least, that's how it "works" in our small country over in Europe. It should be very similar in US too, that "agency" could even be the RIAA.
Well, I would:) Of course, it's quite hypotethical, but being familiar with company-to-company matters, it would pay off big time if your consultants/support company wouldn't be able to threaten you to remove/disable part of the system, or even *hide* any part of it.
Sure, it would be dumb to expect the local admins/operators to develop further the system, should the support company leave you alone, but it'd make sense when your people are able to get the whole thing in operation until you find another company which is more responsible...
How cheap? Cheaper than plugging a Celery into a BX motherboard?
...
You probably can build a server (or a workstation) out of it, but why?
Well, if nothing else, a bit more security. From the worst kind, but still. By using a "different" enough system, you are more immune to script-kiddies, just as by using a lesser-known distribution instead of red hat i386..
Or... remembering the F0 0F Intel-only specific bug, would you believe AMD owners were really happy that they don't have a Pentium?:) By using a less common platform, you are more protected, just as you are left out from the Outlook/exchange/VBS virus madness when you use mutt.
With Linux, and full source, you basically should not care what architecture/platform you are running on. If it can use commodity hardware (IDE, DIMM, PCI), the better.
Actually, probably there's another reason for Intel to like "new" standards. Way back then, DDR wasn't cleanly foreseeable, but SDRAM started to get a really commodity item, and such a big company, with sufficient "friendship" with Rambus (the company), can earn a few extra bucks by encouraging "better" techologies, and tighten the locks held on customers...
... Going into the 80's, the hits were generally 75% for 24 hours out, 50% for 3 days out, and just above a crap shot for beyond that....
Hmm.. You don't mean it was worse than 50% after 3 days? That would be sooo easy..:) Then simply the opposite has higher probability, and we can predict it easily...:)
I decided to check out the HTML myself without a web browser...
Maybe you forgot the Host: HTTP header, and they are using virtual servers. This way, the server can't tell, from which server was the page requested, and this is default (erroneous) page for the server.
Re:No one has claimed to have "rooted" NT using pc
on
SSH v. SRP
·
· Score: 1
bullshit I know for a fact of a certian search engine that is a top 25 web site that got hacked through pcAnywhere
Wow. by Anonymous Coward hirself, citing reliable sources on a reliable target, slashdot credibility at its best...
(Not that I have too much faith in the named software...)
Native Crusoe? I have deep suspicions that the "raw" machine code will not be accessible as we might think, since judging from the patents the device is so optimized for translating things to it... On the other hand, there might be a (still not native) instruction set, which is easier to translate from than the rest, but the goal would be that this optimal instruction set is still common, or at least the difference should not be noticeable... I'd think x86 AND java byte code should be near-perfectly translated and executed (even more so after a time, when the translator had a few run over the code to detect the hot spots).
One of the patents also reveal that the device has larger than 32-bit addressing. In a specific code sequence, they compare the -- otherwise unspecified size -- registers to check if it's outside the 32-bit range. That also may mean a bit closer cooperation with AMD to unify the x86-64 efforts.
Another fact is that at 4th Sep. 1999, Steve Chamberlain of Transmeta, has submitted a set of changes to the assembler of the Cygnus binutils to support the picojava architecture. Presuming this is not his lone interest, Transmeta should have a need for a picojava developer tool chain...
Er? You mean patented... Open source is right on about copyrights... Sorry, that mistake took away at least three Funny scores:)
Re:GPL *is* appropriate for software docs.
on
Free Books Online
·
· Score: 1
You might not have a problem, but it may not be a legal licence. Remember it talks about "running" the program and distributing "object code or executable form".
Although I'm sceptic whether GPL is or is not good for docs, remember, a *copyright* license can only govern the copying. And GPL is nothing else just a finetuned copyright to lead to the free world:)
This is GPL's subtitle: TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION, and BTW, GPL can only intervene, when you distribute something, i.e. when traditional copyright law would be infringed on "normal" stuff. What you *do* with the work you *have* depends only on you. As long as you start to copy, you must comply with the GPL. From this point of view, it's just as appropriate for any machine readable work, as anything else...
There's a thing apparently noone noticed. According the latest patent, they check for segment limits via software (reportedly, Intel has a patent to do that in hardware), and the included code (meta-code?) does the compare with zero and 0xffffffff (ie. they compare a number via the maximum possible value in 32 bit arithmetics -- and this code is even present in the "superoptimized" version of the code too...).
That "proves" the CPU is not a 32 bit one... So, maybe the x86 compatibility is just a big plus, maybe the main thing is really different:) But maybe a 64-bit PC compatible processor is big enough (see this.)
That crusoe thing is another easily confirmable, they have three refused trademark applications for the word "Crusoe", (available via search only at the USPTO web site, no constant URL's, search for crusoe, the applications are: 75-708413, 75-706113 and 75-706048).
Just search for transmeta on the uspto.gov web site among the *trademarks*... (BTW: it can be long known from the maniac rumour monger yours truly here in this Linux Today article...)
if you use Intuit's online accounting software, they have access to all of your account information!
Imagine... "Newsletter to special customers #1 - We are glad to notice you have payed more than $1200 for your new [geeky-device], so we finally have a proof that you afford our advanced services for just $120 monthly!" "Newsletter to special customers #2 - We are glad to notice you wanted to pay $50 to our rival, but we refused that transaction in your advantage! We can do the same for $49.9! You don't have to leave us anymore!"
On the other hand, if people didn't bother their phone company can listen in their conversations, I don't know why this would bother them:) [Me? Yes, I do something about it, and I think wherever "we" go, "we" will certainly have our chances to do what we really want..]
I don't want to claim there's nothing wrong with qmail, but the arguments you show are not quite true:
1. Because there is no one right way to do things in qmail,
Ok, this might be true; but having things done in many ways is only confusing at first, i.e. bad from the user interface point from view. Alas, experts *prefer* things to be done any way they want. Or do you say perl is also bad?:)
2. The qmail author seems to want to rewrite everything rather than use anyone else's code.
Ok, bad from the engineering point of view, but the code he builds is superior from the viewpoints it needed rewriting. Not libc he avoids to use (it's quite difficult to do that in a portable Unix program), but stdio. Stdio is not quite designed for reliability (i.e. buffering, error handling), and security (overruns). His code is not quite nonobvious, I'd rather call it genuinely great. Too bad he doesn't have time to reinvent every part of Unix:)
3. qmail spawns a separate process for just about everything.
You missed a qualifier: qmail spawns a very small separate process for just about everything. I think Ken Thompson, or some other old Unix guy said that if people understood fork() better, we would not need multithreading. Now, DJB *does* understand what is efficient in Unix, and small, cooperating processes are efficient, let me tell you. It is scalable really; although most of the top-volume email sites does not use it directly, it's just because no shrink-wrapped MTA does exactly what they want. hotmail.com uses/used qmail only for one of the in/outcoming directions, AOL uses sendmail, but on quite a few servers -- if I had 45 incoming servers, I could even run SMTP server written in BASIC on them..:) For quite shocking loads however, qmail just works fine.
Ever try to do mail via BITNET or UUCP with qmail?
Weird. I'd bet noone mentioning BITNET *knows* anything about it:) If I knew it, I would try it with qmail yes! I've run uucp over ssh with qmail, I've used FidoNET with qmail. No problem. My only problem with sendmail was that you can *fix* it to do something you want it, but you'll never understand it completely. On the other hand, if you take a few hours, and read all (included) qmail docs, and you know Unix, you can do *anything*, and you understood qmail totally.
If I let myself summoned with qmail bashing, let me share a few resources on it:
BTW, let me mention, Dan (the author of qmail) is the Math Professor on University of Illinois at Chicago, who sued the government to not restrict him distributing his crypto source at his web page (for his students!).
More interesting is the fact that the chip isn't limited to emulating Intel...
Sure we hope... But.. Can you imagine how difficult would it be for a software to translate x86 code to a VLIW architecture very efficiently? I bet the IA64 Linux&GCC people still have something that barely just works, i.e. compiling C to VLIW is still difficult, but Transmeta needs to do this for raw x86 codes...
I guess this is why there were delayed, probably they targeted Java at first, and then moved onto x86 (or maybe backwards), so a complete, efficient emulator for another architecture (including hardware devices) could take quite a few long boring nights... Hopefully they disclose all parts of these translation, so we all can have fun building our C64, ZX81, CP/M, etc. emulators:)
(Another side thought, as they seem to be able to translate any arbitrary sequence of instructions to a VLIW stream, they probably can translate even at the API level, i.e. by translating random Win32 stuff like call ObtainAtomicMutex (I know this is not a real call:), by compiling it into something like LOCK; GETSEM; the possibilities are endless.. Maybe finally we can see a speedy Windows program...:)
Slashdot Mirror
It's just beyond my comprehension why a TLD this general should have its registry in the domain itself...
(The same way, that the impossible .sex domain should not have its registry at thesexregistry.sex.. It would be quite sufficient to have a "pornia.com the dot sex registry" etc...) Clean up this mess of everyone "reserving" domains "'cause it sounds/looks good"...
(Me, I'm just minutes after seeing Dr. Strangelove...)
Yes, in the light of more than a few seconds turnaround (basically anything in space further away than the Moon), nothing but email would survive as a communication form. It is however, very suited for much larger delays too, I have some unanswered email in my inbox dating back a few years... (I mean to reply soon...).
OTOH, nothing prevents us to come up with something email like, but utilizing video technology.. Sending a new message is trivial, just press record, and at the end, stop it, the interesting bit comes when replying. I hope MS dies when we need this tech, or you'll see "Original message follows" at the end of your partner's video, and you can see your own again :)
Seriously, imagine a better way, you see your girlfriends face as she hears your message, she pauses, and tells the stories, and then unpauses to go on..
Of course, the personal communications are not the single form you need from Mars (and obviously, in the first years, we won't have any), but most of it can be reduced to a form of offline, spooled data transfer. UUCP anyone? It (or some flashback of it) is very easily suited for bulk, offline data transfer. You could just program the local machinery to transfer data to be sent to a central spool machine, which then sends it away to Earth (or Pluto, for that matter). It's not internet, really, but IP need not be thrown away; and locally (ie. on Mars), TCP/IP is just as efficient, and well-working as here for us.
For the real bulk transfer, something else would be needed than TCP, imagine that any missed packet can get reported only many minutes later, and you don't want to restart the connection then.. Add a bit forward error correction, and large buffering to cope with minutes (millions) of un-acked packets, and here we go.
Shall I work on this, or let your billions of tax dollars work on this for a few years to get this built? :)
In a way, that sounds like throwing out people from bars if they don't get drunk in a hour. (In which case, they don't care either..)
Convenient for the companies, but useless for "us". Why do the need to rely on power games every time? Let them get a clue. (cluetrain.com anyone?)
Seriously, I don't regard myself as an anarchist, but I don't think an established power should control the future, and noone should be able to escape and build something better. As a quite stretched example, how useful is money, and the concepts of "owning" music copyright to thousands of people travelling to a star system far away?
Not public domain, but others told you that already.
On the other hand, it's even more limited than you think. To play music, radio stations pay a sum depending how many they play in a month to an agency that supposedly distributes this to the artists. What the artists get, is very rarely comparable to a real income. What's more, when buying a tape, you pay a tax decided much earlier to cover for the costs of copying copyrighted material to that tape (that's why "audio" CDR's have a larger price too.)
At least, that's how it "works" in our small country over in Europe. It should be very similar in US too, that "agency" could even be the RIAA.
Well, I would :) Of course, it's quite hypotethical, but being familiar with company-to-company matters, it would pay off big time if your consultants/support company wouldn't be able to threaten you to remove/disable part of the system, or even *hide* any part of it.
Sure, it would be dumb to expect the local admins/operators to develop further the system, should the support company leave you alone, but it'd make sense when your people are able to get the whole thing in operation until you find another company which is more responsible...
Well, if nothing else, a bit more security. From the worst kind, but still. By using a "different" enough system, you are more immune to script-kiddies, just as by using a lesser-known distribution instead of red hat i386..
Or... remembering the F0 0F Intel-only specific bug, would you believe AMD owners were really happy that they don't have a Pentium? :) By using a less common platform, you are more protected, just as you are left out from the Outlook/exchange/VBS virus madness when you use mutt.
With Linux, and full source, you basically should not care what architecture/platform you are running on. If it can use commodity hardware (IDE, DIMM, PCI), the better.
Actually, probably there's another reason for Intel to like "new" standards. Way back then, DDR wasn't cleanly foreseeable, but SDRAM started to get a really commodity item, and such a big company, with sufficient "friendship" with Rambus (the company), can earn a few extra bucks by encouraging "better" techologies, and tighten the locks held on customers...
Ok. Does this mean if I say "I *think* the UK government is run by weenies", noone can cry libel?
After all, how can someone say I *don't* think that way? :)
Maybe you forgot the Host: HTTP header, and they are using virtual servers. This way, the server can't tell, from which server was the page requested, and this is default (erroneous) page for the server.
Wow. by Anonymous Coward hirself, citing reliable sources on a reliable target, slashdot credibility at its best...
(Not that I have too much faith in the named software...)
One of the patents also reveal that the device has larger than 32-bit addressing. In a specific code sequence, they compare the -- otherwise unspecified size -- registers to check if it's outside the 32-bit range. That also may mean a bit closer cooperation with AMD to unify the x86-64 efforts.
Another fact is that at 4th Sep. 1999, Steve Chamberlain of Transmeta, has submitted a set of changes to the assembler of the Cygnus binutils to support the picojava architecture. Presuming this is not his lone interest, Transmeta should have a need for a picojava developer tool chain...
I can imagine someone feeling offended by some cartoons, but then again, why do they want to be part of an experience they don't need?
Er? You mean patented... Open source is right on about copyrights... Sorry, that mistake took away at least three Funny scores :)
Although I'm sceptic whether GPL is or is not good for docs, remember, a *copyright* license can only govern the copying. And GPL is nothing else just a finetuned copyright to lead to the free world :)
This is GPL's subtitle: TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION, and BTW, GPL can only intervene, when you distribute something, i.e. when traditional copyright law would be infringed on "normal" stuff. What you *do* with the work you *have* depends only on you. As long as you start to copy, you must comply with the GPL. From this point of view, it's just as appropriate for any machine readable work, as anything else...
That "proves" the CPU is not a 32 bit one... So, maybe the x86 compatibility is just a big plus, maybe the main thing is really different :) But maybe a 64-bit PC compatible processor is big enough (see this.)
That crusoe thing is another easily confirmable, they have three refused trademark applications for the word "Crusoe", (available via search only at the USPTO web site, no constant URL's, search for crusoe, the applications are: 75-708413, 75-706113 and 75-706048).
Just search for transmeta on the uspto.gov web site among the *trademarks*... (BTW: it can be long known from the maniac rumour monger yours truly here in this Linux Today article...)
Imagine... "Newsletter to special customers #1 - We are glad to notice you have payed more than $1200 for your new [geeky-device], so we finally have a proof that you afford our advanced services for just $120 monthly!" "Newsletter to special customers #2 - We are glad to notice you wanted to pay $50 to our rival, but we refused that transaction in your advantage! We can do the same for $49.9! You don't have to leave us anymore!"
On the other hand, if people didn't bother their phone company can listen in their conversations, I don't know why this would bother them :) [Me? Yes, I do something about it, and I think wherever "we" go, "we" will certainly have our chances to do what we really want..]
Ok, this might be true; but having things done in many ways is only confusing at first, i.e. bad from the user interface point from view. Alas, experts *prefer* things to be done any way they want. Or do you say perl is also bad? :)
Ok, bad from the engineering point of view, but the code he builds is superior from the viewpoints it needed rewriting. Not libc he avoids to use (it's quite difficult to do that in a portable Unix program), but stdio. Stdio is not quite designed for reliability (i.e. buffering, error handling), and security (overruns). His code is not quite nonobvious, I'd rather call it genuinely great. Too bad he doesn't have time to reinvent every part of Unix :)
You missed a qualifier: qmail spawns a very small separate process for just about everything. I think Ken Thompson, or some other old Unix guy said that if people understood fork() better, we would not need multithreading. Now, DJB *does* understand what is efficient in Unix, and small, cooperating processes are efficient, let me tell you. It is scalable really; although most of the top-volume email sites does not use it directly, it's just because no shrink-wrapped MTA does exactly what they want. hotmail.com uses/used qmail only for one of the in/outcoming directions, AOL uses sendmail, but on quite a few servers -- if I had 45 incoming servers, I could even run SMTP server written in BASIC on them.. :) For quite shocking loads however, qmail just works fine.
Weird. I'd bet noone mentioning BITNET *knows* anything about it :) If I knew it, I would try it with qmail yes! I've run uucp over ssh with qmail, I've used FidoNET with qmail. No problem. My only problem with sendmail was that you can *fix* it to do something you want it, but you'll never understand it completely. On the other hand, if you take a few hours, and read all (included) qmail docs, and you know Unix, you can do *anything*, and you understood qmail totally.
If I let myself summoned with qmail bashing, let me share a few resources on it:
BTW, let me mention, Dan (the author of qmail) is the Math Professor on University of Illinois at Chicago, who sued the government to not restrict him distributing his crypto source at his web page (for his students!).
Sure we hope... But.. Can you imagine how difficult would it be for a software to translate x86 code to a VLIW architecture very efficiently? I bet the IA64 Linux&GCC people still have something that barely just works, i.e. compiling C to VLIW is still difficult, but Transmeta needs to do this for raw x86 codes...
I guess this is why there were delayed, probably they targeted Java at first, and then moved onto x86 (or maybe backwards), so a complete, efficient emulator for another architecture (including hardware devices) could take quite a few long boring nights... Hopefully they disclose all parts of these translation, so we all can have fun building our C64, ZX81, CP/M, etc. emulators :)
(Another side thought, as they seem to be able to translate any arbitrary sequence of instructions to a VLIW stream, they probably can translate even at the API level, i.e. by translating random Win32 stuff like call ObtainAtomicMutex (I know this is not a real call :), by compiling it into something like LOCK; GETSEM; the possibilities are endless.. Maybe finally we can see a speedy Windows program... :)