One fact which all the search engines must realize, as well as cache companies like Inktomi and Akamai, is that the Internet is becoming increasingly dynamically-generated, personalized, and transactional -- exactly the kind of content least suited for static spider-driven search engines and static cache technology.
That's where I think it would be a great idea to embed the spiders within people's browsers for this distributed search engine project. Of course you'd need to be able to set up a system to selectively not spider sites / pages (account info, etc.) but the idea is as you're accessing the info in the web database the HTML that pours out gets indexed and then sent to your upstream. A lot of database information stays put or changes very little, but it's hidden behind a search or an index of some kind (see my knowledgebase for an example). If you embedded the spider within the browser, you'd get the content without hammering sites and all is good.
Only during the daytime. CO2 is used in conjuction with sunlight to produce O2+energy. During nighttime, plants consume oxygen just the same as you and I.
The above equation may be greatly overgeneralized but it's been quite some years since my Biology classes.
My apologies for the routing comment. When you'd said to rdir (portfw) localhost:80 it came across that you'd just portfw on the box you were using and placing a static route on that just wouldn't do too much.:-)
Yeah.. On a Linux box you could use rdir to redirect traffic on localip:80/napsterport to napsterserver:napsterport, then ensure that napsterserver has an implicit route. No actual proxy would be needed.
Don't know much about routing do you?
Unless I have misread what you stated, your linux box *still* needs to get through my router to get on to napster. And if I block all outgoing traffic to port 6969 you won't get there, no matter how many redirs you have going because that implicit route still needs to get through my router.
Now something you could do is have an outside box do the redirection. Unfortunately all traffic would be going through that box so you wouldn't want to proxy too many people.:-)
It doesn't need to infect or modify the kernel at all. All it needs to do is copy itself into the filesystem somewhere and insert a line into/etc/inittab.
I don't know about your servers, but my/etc/rc.d/rc.* structure is only accessable as root to begin with. My firewalls boot from write-protected floppy. I've yet to see a virus reach out of the CD-ROM, pop the disk out, flip the tab and put it back in.
Though *nix has a very strict file permission system, it is still a big hassle if a user on a system gets infected. Because then the sysop has to trace down who else on the system executed files of that user. And trace it down all the way.
Funny, I thought that was what BSD process accounting was for. Track all the executions and return codes of all programs. Then there's also the kernel module that tracks every exec().
I mean come on, if you're going to admin, don't be half-assed about it. Get your tcp loggers and your exec() loggers and set your user limits and WATCH the damn system. Don't set it up, leave it go and complain when you got rooted by a 6-week old exploit since you were surfing for pr0n instead of watching the security lists.
I'd like to know what steps to take to prevent a system from being bombed by the superforker exploit. Its a simple little program that forks and forks and forks while filling up your/tmp directory in seconds. It would be nice to see distributions protected against exploits like this out of the box.
There is a kernel module that replaces the exec() call (I think) and provides the exact protection you are asking about. You can tune the amount of forking by user and it also (IIRC) supports logging of "over-fork" conditions.
You can get an average PC for under $800...why not an average laptop for under a grand.
Are you that dense?
TFT screens are EXPEN$IVE
tiny HDDs are EXPEN$IVE
cases are costly to create (big tooling charges in excess of $10k) so you have to sell a whole lot of laptops to bring this down
Heat considerations affect the design, making it costlier
custom motherboards
Li-ion batteries aren't cheap
In short, the sheer volume of standard PC components outnumbers the volume of laptop components so they are far cheaper to buy in consumer quantities. Until everyone buys laptops and not PCs, this won't change.
Regardless, it will have to be turned off even if it is for battery changes.
Not to be an ass, but my Palmpilot doesn't lose its data when I switch batteries. Nor do (new) VCRs lose their programming on power loss. Devices called super capacitors (5V 1F style things) keep enough energy around to keep very low power components up and running in a sleep mode to ride out such interruptions.
...is how much faster this thing will run if it's not emulating an x86.
That is missing the point, IMHO. One of the reasons the chip kicks ass is because they can change the hardware and you can't tell. Write native VLIW on this pig and you're fucked if they change, just like all the other processors.
... this is coming from a guy who prefers assembly to high-level languages in 98% of cases. I think they really struck on something here, don't fuck it up by asking to write in the "native tongue" of this beast. Well, unless you're writing your own processor.:-)
Sorry about that, I didn't grab the last part I wanted to comment on.
I really think notebooks are going to be where Crusoe blooms, if for no other reason than to not melt your lap while your working with it. But is $329 for the 700MHz really any kind of a bargain?
At 1/60 the power consumption it'll do more than not melt in your lap. Your batteries will last longer. It'll run quieter. Replace the HDD with a lower-power device and it'll run longer and quieter yet. The laptop can be physically smaller (no heat pipe/fans and at least 1/2 the chipset is gone). Those are some major savings. How much does a mobile P3-700 cost? I betcha it's more than $329 and you need to add on those items I mentioned above.
And of course, the price on those web "appliances" (aren't you sick of that term?) is still too high for what amounts to a big kids toy. You're not going to get any real work done without a keyboard (in most cases) so basically what you are paying for is a $500 - $1000 Rolodex with some added functionality.
Think broader. A net-accessible device that runs for weeks. It's not just a rolodex. It's an extension of the 'net that you have anywhere you go. That opens up tons of opportunites in all manner of fields: instrumentation, administration, gaming, medical, scientific... And that's not even going into the geek sector. Sit on the can and web-browse. Read in bed. Code in your lazy-boy. Browse/code anywhere in the transit system.
(And yes, I know, virtual keyboard or whatever they called it. Did you ever try to do any touch typing on the old Atari 400 membrane keyboard? If so, you know my objection here)
I too saw little use there. Similar to the Palm pop-up keyboard. Blah. I'll carry along a fold-up USB keyboard (there is a serial one for palm in the making).
Remember that this device is targetted for mobile and low power apps. You don't need to learn new APIs or chips. Use what you know; the chip will emulate it. I didn't see anywhere the option to code it in its native language but then again you would lose the self-optimization that it is capable of doing. This is a good and bad thing.
Transmeta didn't just show off the power consumption, although that is a MAJOR big thing. They also showed off its "code morphing", dynamic optimization and emulation features. Don't write this off; this is a major hit.
Remember, both the P3 and the K7 will kick Crusoes ass, real hard, when it comes to performance.
... howso? Mind you I did not see any fp benchmarks on the Crusoe, so you may very well be correct in that aspect of benchmarking. From what I can gather, however, the Crusoe optimizers actually improve performance as they run code. Add on the battery life (not much of a factor in desktops/servers*) and support circuitry**, however, and Crusoe still comes out ahead.
*power consumption *is* a factor in desktop/server markets because it affects the cost of equipment needed to power / cool these devices/rooms. Hotter components also burn out faster.
**If I am reading this correctly, Crusoe includes North and Southbridges on-chip. This would make the motherboards for these devices cheaper and smaller as well, the former variable making desktops/servers cheaper.
Do they mean software based in the same way that the 6800 (not 68000) was software based - an onboard ROM (well, RAM in transmetas case) that contains instructions on how to control the hardware part of the chip?
No. The software that runs natively on the VLIW core does all the translation, optimization and such.
But oh my, what optimization! They're talking about ass-end compiler optimizations.. very 'big' algorithms that won't fit on silicon.
I wonder if you could buy the code optimizer and have it spit back hyper-optimized x86. You know, the code runs and self-profiles, rewrites and then retranslates to x86.
I also have to wonder how scared Intel and AMD are right now. This puppy runs COLD, FAST and is SMALL and CHEAP to build. Plus it is self-optimizing and 100% x86-compatible. I think Intel et al just lost their mobile market.
I was particularly impressed with the Longrun technology. If those were actual true power consumption graphs.../me breathes low... wow!
I think at that point your primary problem would be computing on a television monitor. They just don't have the fidelity required. Ever see one of those PCTV converters that would take your monitors output, and display it on a TV screen? It may look neat, but try using it for your primary interface.
Precisely why I kinda relegated the entire linux x-server market to web browsing or otherwise graphical uses.:-)
I wish I had the link, but I've already seen X on an N64.
Ahh dammit, it was an April Fool's joke. The rest of my post still applies, though.:-)
... it is curious... when I post my comment, I go and re-read the article to see what else I can reply to. And there, right under the link for the N64 XTerm, is my post. Talk about irony.:-)
I would have to question Linux on any gaming console. I want the gaming console running something that I don't know the name of, and don't care to, because it means it's so proprietary, it will work wonders with the proprietary hardware it runs on.
Actually the documentation on the N64 is quite extensive (for a proprietary system). And with all that fancy-do hardware you could write one hell of an accellerated X server. Think of it. Throw in a cart that has a 100bT port on it, plug in a keyboard (the controller interface is not too difficult to hack) and you have a cheap, fast X terminal for web browsing / gaming. Insert kiosk / cafe / whatever use here.
I wish I had the link, but I've already seen X on an N64.
And why's this guy taking everything apart to learn? dextrose has compilers, assemblers, disassemblers and all manner of documentation on programming this fscker.
Get yourself a Doctor V64 or, what I use, a Z64 and start programming. I like the latter because it's smaller, doesn't use CDs or take up a parallel port and (upon taking it apart) is an embedded 386. The V64 is a 6809 (IIRC) machine with a lot more custom circuitry.
My goal for it is to hook up a network card to it's internal PC/104 slot and get rid of the need for a Zip drive altogether. Boot via BOOTP, grab games from my server via TFTP. The source for the BIOS is available on the 'net and all it is ATM just OpenDOS with some custom executable to run the embedded PC <-- N64 part.
There's no need for custom hardware. Hell a simple ROM emulator would work. There *are* tricks to doing it in hardware (they have a lock chip on each cart IIRC) but if you got one of those V64jr units you could hack it and put a ROM emulator on that if you *really* felt you needed to. (the V64jr lets you read/write to its onboard memory with a parallel port so a ROM emulator is not necessary, but most good ROM emulators let you have breakpoints and other good things for development). From what this guy's website said, he was using custom hardware to read/write to N64 memory. Waste of time / energy / effort! Proprietary interface!
My brother already programs for the N64 (just simple stuff but his time is limited too:-) -- All you're doing is writing a ROM image. You do *not* need to rip the thing apart to run Linux on the pig. All the info (hell you can even get detalled info / memory maps / etc on the hardware) is available from dextrose or #n64dev on efnet. All this scope tracing / etc is bullshit if you want to really program it / port Linux to it.
Mind you now, if he was the curious sort like myself, he'd have done it just for fun.:-)
yes, and we would expect another civ. trying to communicate to use exactly those methods. If they're trying to communicate, they won't be making themselves difficult to detect...
The point I was trying to make was that for the signal to reach us you need to waste an awful lot of energy on transmitting that carrier. Get rid of it and you can use the energy more wisely, thus reaching farther.
I am running Win98/Netscape with *checking* 6 windows open as I type. This is a typical load for me, with up to 15 Netscape windows running.
What else? GetRight, CodeWright, ICQ, SecureCRT. I never seem to have any problems unless I load up too big a page. Then Netscape crashes horribly and takes down all my Netscape windows. Doesn't matter how much swap I have available, Netscape seems to ignore it. Looks like it needs real actual RAM. Go figure.
My other machine runs X/Netscape and has similar problems. Usually 500+ comment slash pages in flat mode do it every time.:-)
Incidentally, there are also projects searching for those very laser-light signals you mention, as well.
Um... wouldn't a laser signal have to be pointed directly at the intended target? Yes I know all about divergence and all those great things but looking for laser communications perhaps not intended for us seems rather silly.
Slashdot Mirror
One fact which all the search engines must realize, as well as cache companies like Inktomi and Akamai, is that the Internet is becoming increasingly dynamically-generated, personalized, and transactional -- exactly the kind of content least suited for static spider-driven search engines and static cache technology.
That's where I think it would be a great idea to embed the spiders within people's browsers for this distributed search engine project. Of course you'd need to be able to set up a system to selectively not spider sites / pages (account info, etc.) but the idea is as you're accessing the info in the web database the HTML that pours out gets indexed and then sent to your upstream. A lot of database information stays put or changes very little, but it's hidden behind a search or an index of some kind (see my knowledgebase for an example). If you embedded the spider within the browser, you'd get the content without hammering sites and all is good.
CO2, on the other hand, is food for plants.
Only during the daytime. CO2 is used in conjuction with sunlight to produce O2+energy. During nighttime, plants consume oxygen just the same as you and I.
The above equation may be greatly overgeneralized but it's been quite some years since my Biology classes.
An outside box is what I had in mind..
:-)
My apologies for the routing comment. When you'd said to rdir (portfw) localhost:80 it came across that you'd just portfw on the box you were using and placing a static route on that just wouldn't do too much.
Yeah.. On a Linux box you could use rdir to redirect traffic on localip:80/napsterport to napsterserver:napsterport, then ensure that napsterserver has an implicit route. No actual proxy would be needed.
:-)
Don't know much about routing do you?
Unless I have misread what you stated, your linux box *still* needs to get through my router to get on to napster. And if I block all outgoing traffic to port 6969 you won't get there, no matter how many redirs you have going because that implicit route still needs to get through my router.
Now something you could do is have an outside box do the redirection. Unfortunately all traffic would be going through that box so you wouldn't want to proxy too many people.
...let me see if I can zip back up the history...
:-) Your comments are valid in this context. :-)
Sorry, I didn't we were talking about what we were talking about.
[Show me]...your dual boot firewall and how all of /etc/rc.d.... is protected from anything while the "other" os is running.
:-)
Now why on earth would a server or firewall be dual-booting?
Now on my home system, I use vmware for booting into NT to run my PIC emulator software. And you can lock down partitions with vmware.
It doesn't need to infect or modify the kernel at all. All it needs to do is copy itself into the filesystem somewhere and insert a line into /etc/inittab.
/etc/rc.d/rc.* structure is only accessable as root to begin with. My firewalls boot from write-protected floppy. I've yet to see a virus reach out of the CD-ROM, pop the disk out, flip the tab and put it back in.
I don't know about your servers, but my
Though *nix has a very strict file permission system, it is still a big hassle if a user on a system gets infected. Because then the sysop has to trace down who else on the system executed files of that user. And trace it down all the way.
Funny, I thought that was what BSD process accounting was for. Track all the executions and return codes of all programs. Then there's also the kernel module that tracks every exec().
I mean come on, if you're going to admin, don't be half-assed about it. Get your tcp loggers and your exec() loggers and set your user limits and WATCH the damn system. Don't set it up, leave it go and complain when you got rooted by a 6-week old exploit since you were surfing for pr0n instead of watching the security lists.
I'd like to know what steps to take to prevent a system from being bombed by the superforker exploit. Its a simple little program that forks and forks and forks while filling up your /tmp directory in seconds. It would be nice to see distributions protected against exploits like this out of the box.
There is a kernel module that replaces the exec() call (I think) and provides the exact protection you are asking about. You can tune the amount of forking by user and it also (IIRC) supports logging of "over-fork" conditions.
Where is it? Here is a link to Freshmeat.
Are you that dense?
In short, the sheer volume of standard PC components outnumbers the volume of laptop components so they are far cheaper to buy in consumer quantities. Until everyone buys laptops and not PCs, this won't change.
No one ever noticed that the execute bit was set on a couple of core files. :)
Okay colour me stupid, but that is one of the neatest ideas I'd heard of. Mind you, talk would have to be running at the time of the dump, no?
(/me knows his network security quite well, but not his system security)
Regardless, it will have to be turned off even if it is for battery changes.
Not to be an ass, but my Palmpilot doesn't lose its data when I switch batteries. Nor do (new) VCRs lose their programming on power loss. Devices called super capacitors (5V 1F style things) keep enough energy around to keep very low power components up and running in a sleep mode to ride out such interruptions.
...is how much faster this thing will run if it's not emulating an x86.
:-)
That is missing the point, IMHO. One of the reasons the chip kicks ass is because they can change the hardware and you can't tell. Write native VLIW on this pig and you're fucked if they change, just like all the other processors.
... this is coming from a guy who prefers assembly to high-level languages in 98% of cases. I think they really struck on something here, don't fuck it up by asking to write in the "native tongue" of this beast. Well, unless you're writing your own processor.
Sorry about that, I didn't grab the last part I wanted to comment on.
I really think notebooks are going to be where Crusoe blooms, if for no other reason than to not melt your lap while your working with it. But is $329 for the 700MHz really any kind of a bargain?
At 1/60 the power consumption it'll do more than not melt in your lap. Your batteries will last longer. It'll run quieter. Replace the HDD with a lower-power device and it'll run longer and quieter yet. The laptop can be physically smaller (no heat pipe/fans and at least 1/2 the chipset is gone). Those are some major savings. How much does a mobile P3-700 cost? I betcha it's more than $329 and you need to add on those items I mentioned above.
And of course, the price on those web "appliances" (aren't you sick of that term?) is still too high for what amounts to a big kids toy. You're not going to get any real work done without a keyboard (in most cases) so basically what you are paying for is a $500 - $1000 Rolodex with some added functionality.
Think broader. A net-accessible device that runs for weeks. It's not just a rolodex. It's an extension of the 'net that you have anywhere you go. That opens up tons of opportunites in all manner of fields: instrumentation, administration, gaming, medical, scientific... And that's not even going into the geek sector. Sit on the can and web-browse. Read in bed. Code in your lazy-boy. Browse/code anywhere in the transit system.
(And yes, I know, virtual keyboard or whatever they called it. Did you ever try to do any touch typing on the old Atari 400 membrane keyboard? If so, you know my objection here)
I too saw little use there. Similar to the Palm pop-up keyboard. Blah. I'll carry along a fold-up USB keyboard (there is a serial one for palm in the making).
Remember that this device is targetted for mobile and low power apps. You don't need to learn new APIs or chips. Use what you know; the chip will emulate it. I didn't see anywhere the option to code it in its native language but then again you would lose the self-optimization that it is capable of doing. This is a good and bad thing.
Transmeta didn't just show off the power consumption, although that is a MAJOR big thing. They also showed off its "code morphing", dynamic optimization and emulation features. Don't write this off; this is a major hit.
Remember, both the P3 and the K7 will kick Crusoes ass, real hard, when it comes to performance.
... howso? Mind you I did not see any fp benchmarks on the Crusoe, so you may very well be correct in that aspect of benchmarking. From what I can gather, however, the Crusoe optimizers actually improve performance as they run code. Add on the battery life (not much of a factor in desktops/servers*) and support circuitry**, however, and Crusoe still comes out ahead.
*power consumption *is* a factor in desktop/server markets because it affects the cost of equipment needed to power / cool these devices/rooms. Hotter components also burn out faster.
**If I am reading this correctly, Crusoe includes North and Southbridges on-chip. This would make the motherboards for these devices cheaper and smaller as well, the former variable making desktops/servers cheaper.
Do they mean software based in the same way that the 6800 (not 68000) was software based - an onboard ROM (well, RAM in transmetas case) that contains instructions on how to control the hardware part of the chip?
/me breathes low... wow!
No. The software that runs natively on the VLIW core does all the translation, optimization and such.
But oh my, what optimization! They're talking about ass-end compiler optimizations.. very 'big' algorithms that won't fit on silicon.
I wonder if you could buy the code optimizer and have it spit back hyper-optimized x86. You know, the code runs and self-profiles, rewrites and then retranslates to x86.
I also have to wonder how scared Intel and AMD are right now. This puppy runs COLD, FAST and is SMALL and CHEAP to build. Plus it is self-optimizing and 100% x86-compatible. I think Intel et al just lost their mobile market.
I was particularly impressed with the Longrun technology. If those were actual true power consumption graphs...
I think at that point your primary problem would be computing on a television monitor. They just don't have the fidelity required. Ever see one of those PCTV converters that would take your monitors output, and display it on a TV screen? It may look neat, but try using it for your primary interface.
:-)
Precisely why I kinda relegated the entire linux x-server market to web browsing or otherwise graphical uses.
I wish I had the link, but I've already seen X on an N64.
:-)
:-)
Ahh dammit, it was an April Fool's joke. The rest of my post still applies, though.
... it is curious... when I post my comment, I go and re-read the article to see what else I can reply to. And there, right under the link for the N64 XTerm, is my post. Talk about irony.
I would have to question Linux on any gaming console. I want the gaming console running something that I don't know the name of, and don't care to, because it means it's so proprietary, it will work wonders with the proprietary hardware it runs on.
Actually the documentation on the N64 is quite extensive (for a proprietary system). And with all that fancy-do hardware you could write one hell of an accellerated X server. Think of it. Throw in a cart that has a 100bT port on it, plug in a keyboard (the controller interface is not too difficult to hack) and you have a cheap, fast X terminal for web browsing / gaming. Insert kiosk / cafe / whatever use here.
I wish I had the link, but I've already seen X on an N64.
:-) -- All you're doing is writing a ROM image. You do *not* need to rip the thing apart to run Linux on the pig. All the info (hell you can even get detalled info / memory maps / etc on the hardware) is available from dextrose or #n64dev on efnet. All this scope tracing / etc is bullshit if you want to really program it / port Linux to it.
:-)
And why's this guy taking everything apart to learn? dextrose has compilers, assemblers, disassemblers and all manner of documentation on programming this fscker.
Get yourself a Doctor V64 or, what I use, a Z64 and start programming. I like the latter because it's smaller, doesn't use CDs or take up a parallel port and (upon taking it apart) is an embedded 386. The V64 is a 6809 (IIRC) machine with a lot more custom circuitry.
My goal for it is to hook up a network card to it's internal PC/104 slot and get rid of the need for a Zip drive altogether. Boot via BOOTP, grab games from my server via TFTP. The source for the BIOS is available on the 'net and all it is ATM just OpenDOS with some custom executable to run the embedded PC <-- N64 part.
There's no need for custom hardware. Hell a simple ROM emulator would work. There *are* tricks to doing it in hardware (they have a lock chip on each cart IIRC) but if you got one of those V64jr units you could hack it and put a ROM emulator on that if you *really* felt you needed to. (the V64jr lets you read/write to its onboard memory with a parallel port so a ROM emulator is not necessary, but most good ROM emulators let you have breakpoints and other good things for development). From what this guy's website said, he was using custom hardware to read/write to N64 memory. Waste of time / energy / effort! Proprietary interface!
My brother already programs for the N64 (just simple stuff but his time is limited too
Mind you now, if he was the curious sort like myself, he'd have done it just for fun.
Tea, Early Grey - Hot!
Bah... gimme Kirk:
"Beer. Romulan. Cold."
:-)
yes, and we would expect another civ. trying to communicate to use exactly those methods. If they're trying to communicate, they won't be making themselves difficult to detect...
The point I was trying to make was that for the signal to reach us you need to waste an awful lot of energy on transmitting that carrier. Get rid of it and you can use the energy more wisely, thus reaching farther.
I am running Win98/Netscape with *checking* 6 windows open as I type. This is a typical load for me, with up to 15 Netscape windows running.
:-)
What else? GetRight, CodeWright, ICQ, SecureCRT. I never seem to have any problems unless I load up too big a page. Then Netscape crashes horribly and takes down all my Netscape windows. Doesn't matter how much swap I have available, Netscape seems to ignore it. Looks like it needs real actual RAM. Go figure.
My other machine runs X/Netscape and has similar problems. Usually 500+ comment slash pages in flat mode do it every time.
Incidentally, there are also projects searching for those very laser-light signals you mention, as well.
Um... wouldn't a laser signal have to be pointed directly at the intended target? Yes I know all about divergence and all those great things but looking for laser communications perhaps not intended for us seems rather silly.