Cool, mine does SMP as well, via a simultaneous-processes setting. Your scripts look larger than mine, and theres a seperate script for SMP? Whats wrong with just making it a config option?
My main goal at this point is to finish setiwatch, which is a small Gtk+-using script to show you workunit status of every node of a SETI farm. It works right now, but its not perfect yet =)
Minor bugfix release here - this should allow you to specify upload/download time periods that include midnight (like their suggestion of 23:00 to 3:00 PST).
This wasn't very hard to see coming, but its still unfortunate.
For those who are looking for a workunit-caching program for linux, I've written a perlscript which has done a quite good job at it. I've decided to release it tonight, to help everyone out, but its a bit rough on the edges. It does
the job, though. Read the README, download it here.
Also, mirrors are welcome - my connection sucks far worse than theirs does =)
They weren't using an oscilloscope; they were using a spectrum analyser. Think winamp/xmms. One display shows you sound waves going by, like an oscilloscope. Another puts that data through an FFT and shows you the frequency domain (bass on the left, treble on the right), like a spectrum analyser.
Orange-Micro's does, with an optional AC adapter. I think the problem is passing that much power through the PCMCIA port, since it takes more power than USB (for which you can generally find powered PC Cards).
Good to know. IBM's (part number 19K5680) don't. The only alternative I've found so far is to get a firewire hub which provides itself - thanks for the heads-up.
I beg to differ. The market for, e.g., Firewire CD-RWs is ramping up, while the market for USB CD-RWs appears to be slacking - my experience was that they were doing fine while Apple's consumer computers didn't have Firewire, but the gain is real enough (8,16,24, even 32x vs. 4x, for a CD-RW) that people want it.
So, in this instance, USB's bandwidth is not "good enough". Thats fair. In most cases I've seen (cameras, mostly), this is not the case.
I hope Firewire takes off, as it already seems to have fewer substandard hardware problems than USB has. Of course, those are a direct result of consumer market popularity, but still...
I would also like to point out the connectors. I would assume firewire was made partly as competition to usb. Thus it would be relatively easy to assume that firewire carries more current to power some lower powered devices.
Firewire and USB both have the option of powering their peripheral devices. I'm not sure about USB, but with firewire, this is not a requirement. I've yet to find a firewire CardBus card which does supply power. I know the iPod requires a power supply to actually realize its plugged into a host, though.
Ethernet isn't designed to power anything. I imagine it only carries enough power to carry the signal for the distances involved.
There are also standards for providing power over ethernet. But thats 10BaseT and 100BaseTX. It works by providing power over another set of wires, since those two standards only use 4 of the 8 conductors in CAT5. 1000BaseT makes full use of all 8 conductors, making this unfeasable.
Also comes into the cost of making hubs. With ethernet you must worry about ip addresses and routing all that information. I do not believe firewire would require this information to be dealt with in such a complicated matter.
Ethernet hubs don't have to care about anything, they just rebroadcast. Ethernet switches don't care about anything past the MAC addresses in the frame header. Only IP routers care about IP addresses, subnets, etc. Thats OSI layer 3. Hubs and switches operate below all of that, which is why you can run things like IPv6 and IPX on your network without having to go buy a new hub.
Firewire hubs act like ethernet switches do, they route information between firewire hosts based on firewire addresses. They're similarly uncomplicated.
If gigabit ethernet is becoming common in consumer devices, this is great, because prices will finally come down. Gigabit has typically been non-cost-effective. Firewire has been a consumer product all along, and although its mostly had its market stolen away by USB (for the same reason 10BaseT devices are still common: performance is "good enough" and the price blows the competition away), it still has a lower price point than gigabit has in the past. I hope this changes, but I think its still a bit overrated given that most commodity OS's I've seen can't even come up with enough raw data to come anywhere near filling this big a pipe.
I have no degree. I was hired for my current job because I had taught myself linux and C. They wanted me to do some application writing for an embedded linux box. Later on, some driver writing. True, its wussy as far as "embedded" is concerned, but it was a beginning. From there, simple knowledge of C and assembly fundamentals were all that was necessary to do some programming for 8051 microcontrollers, AD18xx DSPs, and soon I'll start work on some code to run on an ARM core. In the meantime, though, they have me learning more about hardware via soldering together my own ISA board, at my request. =)
My suggestion is to find a job which involves minor embedded stuff while not being the main focus of the job, so you can ease yourself into it. Knowing linux, java, or other highlevel constructs can get you such a job, but won't be used too much later on when you get to lower level things. I think knowledge of an assembly language or two is far more important. (I still don't know x86 very well, but I learned MOS6510 assembly a long time ago, which I haven't used directly, but the fundamentals have helped)
And yet Charter Pipeline won't even offer one direction at 1.5Mbit reliably. That figures. It just goes to show, though - if you want something done right, do it yourself.
I think this will prove more interesting to those who want to create network links for personal use, rather than those who want to provide large-scale broadband access. As such, its nice to have the extra option out there, but it doesn't offer anything unique.
This may have solved the last mile problem, and at 10 MB, it blows DSL out of the water.
Thats 10Mb(it), not 10MB(yte). DSL is capable of this speed too. Like DSL, its pretty good at running over crap cable, but quality varies with the wiring.
This is a different (fault-tolerant) modulation format for ethernet frames.
DSL is a different (fault-tolerant) modulation format for ATM frames.
I think this is interesting, because ethernet doesn't have as many things to mess up, like, for instance, matching the VCI and VPI up on both ends. On the other side of the coin, though, you don't get the subnet seperation and traffic shaping that ATM offers natively. In terms of moving packets from point A to point B, the technologies seem roughly equivelant to me.
Also remember, DSL is capable of 10MBit, and I don't know how much HFC cable is capable of, but if you ever see an ISP deploying this, don't expect them to give you the full capabilities of the wire - broadband ISPs never do (all of the ones I've tried cap bandwidth higher up in the network regardless of what the technology is capable of).
I'm in the middle of a sparetime project based around an Analog Devices DSP. I'm curious why your statement is true, especially since its so easy... anyone who knows algebra can read AD DSP assembly fairly easily. The only tricky part to writing it is sorting out your algorithm to take the most advantage of parallel instruction execution.
Are other vendors' DSPs (TI comes to mind) more difficult to understand?
Developers obviously have a benefit to knowing assembly, if no reason other than debugging skill. Those who don't know it are reduced to blaming Bill, other components of the system, or the hardware, all of which are counterproductive excuses at best.
I believe sysadmins have a benefit to knowing it as well, simply because you know whats going on under the hood, so to speak. This kind of knowledge allows you to actually understand the worth of things like 3DNow!, SSE/SSE2/MMX, pipeline length, cache consistency, hyperthreading, and all the other things that vary from processor to processor and from software package to software package. I believe this is important because you aren't reduced to cointosses for whose hype to believe, when deciding what things to buy/download and deploy.
In addition, if assembly wasn't relevant for administration of a system, why would you include register dumps in bluescreens/Oopses? Rebooting doesn't cut it, that only temporarily alleviates symptoms and doesn't solve the problem. I believe "keeping a system running smoothly" definately counts as a sysadmin's role, therefore a sysadmin should have good debugging skills. Even if you pass the debugging off to someone who would know, wouldn't it be nice to know WHICH hex numbers on that bluescreen would be helpful to him/her in finding the bug?
If you're constantly answering questions like "I forgot my password", "is the network down?", and "I need a damned good kicking please?", then perhaps assembly wouldn't help you here (unless you're trying to achieve BOFH-style *DUMMY MODE*). However, this means you are either not a sysadmin or are wearing multiple hats - this stuff is commonly called "Tech Support".
You know, if Linux video software would come as Debian packages, I would be really happy. Currently, if I want anything with avifile or
something, I need to compile it myself
Uhh, you can "apt-get install avifile-player" if you like. Its in sid, at least, not sure about the others.
What you're asking for is called multicasting, and unfortunately either requires IP tunneling or hardware support every step of the way. Some IPv4 ISPs support it (starband claims to, for instance) but most don't bother to.
As with most optional technologies, until a critical mass is reached, noone's going to bother to support it.
Fortunately, multicasting is one of the requirements for IPv6 compliance. Of course, since IPv6 is itself currently considered another of those "optional technologies", for now people who really want this tend to roll their own.
If you want to help, do so! People are obviously already throwing ideas around... for example, a quick websearch turned up a draft
RTP ogg payload spec, for multicasting ogg streams.
My coworkers and I tend to use a form of steganography, on IRC. Its not typical pixel-in-picture stuff, though... rather, the script encodes messages (the current irssi perlscript implementation is 7-bit clean) in the entropy available in l3eT-babbling carrier text. For instance, "l" could be "l", "L", "|" or "1", meaning you could use an "l" character to store 2 bits of data. The output looks, as I'm sure you can guess, horrible.
For more important things, we tend to use ssh, but steganography isn't entirely forgotten here =)
* Disitributions should GET RID of old, clunky, insecure programs such as sendmail (replace with postfix), wuftp (replace with proftpd), inetd (replace with xinetd), etc.
Uhmm... proftpd has plenty of security problems too. In the few cases where I really have no choice but to run an ftpd, I use vsftpd.
In any case, its vital to keep up with things like bugtraq, look at everything discussed and fix everything that pertains to your boxes... this is made much easier when you've selected your server software with security in mind, but still just as important.
This is an interesting idea. Indeed, a patent needs to clearly document the process to which it applies.
However, patents apply to processes. So what if someone patents the process of writing code to encrypt/decrypt text using XOR, for example? I can definately see this as being a problem, especially when a large amount of investment is tied up in intellectual property. This leads to a situation similar to the availability of Reed-Solomon codecs, for example (generally implemented in un-reverse-engineerable silicon, and always requiring heavy licensing).
I should patent the process of depressing a shift key for the purpose of gaining access to other symbols on the keyboard... and then sue non-Free vendors for infringing on it (its hard to code in ANY language without the shift key)!
So that means if I had the money right now, I could hire 500 head of lawyer and, wielding my trusty apache logfiles, start 500 lawsuits against the people who, by means of gross administrative irresponsibility, have machines which are running automated scripts which are attempting to gain unauthorized access to my machine (and failing), and win each of those lawsuits because doing so is a felony?
That would be sweet justice. However, I don't think the case would hold up, regardless of who sued who.
Thats the correct way to use uniq, yes. However, since the dates and times are all different, uniq won't do much. All that addition would end up doing is sorting by IP address, rather than by time.
That'll work, until the machines get infected again. I'd rather shutdown the machine entirely, or disable all the NICs, or something.
Its important to get admin intervention. If the admin doesn't know about the problem, you have to let him/her know. If the admin doesn't even know they were running IIS, again, time for a wakeup call.
Disabling the backdoor will work, until the machine gets infected again. It also won't halt the spread, unless the worm somehow depends on infected.dat?
Stopping the IIS service also has the problem of not delivering a wakeup call to those who don't even know they were running it. I don't want to support bad administration.
I'm looking for a way to shut down the machine, stop all the NICs entirely, stop all IPv4 support, or something else disabling the machine and requiring admin intervention. If thats possible, that will FORCE the admin to take responsibility for their box, and effectively disable that box until they do so.
The problem is finding such a thing with a command-line interface, without a confirmation prompt. Any ideas?
In 1996 I paid $50 for a Red Hat Linux set.
I've tried 5 distros since then, eventually settling on Debian, and not paying for any of them (unless you count submitting bugreports and (more often) patches, which, although its the best gift one can give and all, is technically charity anyway).
I've never paid for a Microsoft OS.
My workplace's experience:
My boss pays a yearly subscription for MSDN. He's never paid a cent for Linux, though his network is completely dependent on it.
For administration, about 5 times as much is paid (in terms of employee time spent) yearly to configure and maintain Windows machines than is paid to configure and maintain linux machines. (I feel this is a fair comparison, as we have one windows 2000 server and one linux server/router)
Slashdot Mirror
Cool, mine does SMP as well, via a simultaneous-processes setting. Your scripts look larger than mine, and theres a seperate script for SMP? Whats wrong with just making it a config option?
My main goal at this point is to finish setiwatch, which is a small Gtk+-using script to show you workunit status of every node of a SETI farm. It works right now, but its not perfect yet =)
I've also created an actual webpage for it.
You can find it here.
This wasn't very hard to see coming, but its still unfortunate.
For those who are looking for a workunit-caching program for linux, I've written a perlscript which has done a quite good job at it. I've decided to release it tonight, to help everyone out, but its a bit rough on the edges. It does the job, though. Read the README, download it here. Also, mirrors are welcome - my connection sucks far worse than theirs does =)
They weren't using an oscilloscope; they were using a spectrum analyser. Think winamp/xmms. One display shows you sound waves going by, like an oscilloscope. Another puts that data through an FFT and shows you the frequency domain (bass on the left, treble on the right), like a spectrum analyser.
1.2Mbit down, 128Kbit up.
$40/month for the service, + $10/month cablemodem rental.
Charter Pipeline, South Lake Tahoe, California.
Perhaps SETI@Home can use some help?
They seem to have been heavily overtaxed recently...
This seems to be a repost of this slashdot article.
Orange-Micro's does, with an optional AC adapter. I think the problem is passing that much power through the PCMCIA port, since it takes more power than USB (for which you can generally find powered PC Cards).
Good to know. IBM's (part number 19K5680) don't. The only alternative I've found so far is to get a firewire hub which provides itself - thanks for the heads-up.
I beg to differ. The market for, e.g., Firewire CD-RWs is ramping up, while the market for USB CD-RWs appears to be slacking - my experience was that they were doing fine while Apple's consumer computers didn't have Firewire, but the gain is real enough (8,16,24, even 32x vs. 4x, for a CD-RW) that people want it.
So, in this instance, USB's bandwidth is not "good enough". Thats fair. In most cases I've seen (cameras, mostly), this is not the case.
I hope Firewire takes off, as it already seems to have fewer substandard hardware problems than USB has. Of course, those are a direct result of consumer market popularity, but still...
I would also like to point out the connectors. I would assume firewire was made partly as competition to usb. Thus it would be relatively easy to assume that firewire carries more current to power some lower powered devices.
Firewire and USB both have the option of powering their peripheral devices. I'm not sure about USB, but with firewire, this is not a requirement. I've yet to find a firewire CardBus card which does supply power. I know the iPod requires a power supply to actually realize its plugged into a host, though.
Ethernet isn't designed to power anything. I imagine it only carries enough power to carry the signal for the distances involved.
There are also standards for providing power over ethernet. But thats 10BaseT and 100BaseTX. It works by providing power over another set of wires, since those two standards only use 4 of the 8 conductors in CAT5. 1000BaseT makes full use of all 8 conductors, making this unfeasable.
Also comes into the cost of making hubs. With ethernet you must worry about ip addresses and routing all that information. I do not believe firewire would require this information to be dealt with in such a complicated matter.
Ethernet hubs don't have to care about anything, they just rebroadcast. Ethernet switches don't care about anything past the MAC addresses in the frame header. Only IP routers care about IP addresses, subnets, etc. Thats OSI layer 3. Hubs and switches operate below all of that, which is why you can run things like IPv6 and IPX on your network without having to go buy a new hub.
Firewire hubs act like ethernet switches do, they route information between firewire hosts based on firewire addresses. They're similarly uncomplicated.
If gigabit ethernet is becoming common in consumer devices, this is great, because prices will finally come down. Gigabit has typically been non-cost-effective. Firewire has been a consumer product all along, and although its mostly had its market stolen away by USB (for the same reason 10BaseT devices are still common: performance is "good enough" and the price blows the competition away), it still has a lower price point than gigabit has in the past. I hope this changes, but I think its still a bit overrated given that most commodity OS's I've seen can't even come up with enough raw data to come anywhere near filling this big a pipe.
I have no degree. I was hired for my current job because I had taught myself linux and C. They wanted me to do some application writing for an embedded linux box. Later on, some driver writing. True, its wussy as far as "embedded" is concerned, but it was a beginning. From there, simple knowledge of C and assembly fundamentals were all that was necessary to do some programming for 8051 microcontrollers, AD18xx DSPs, and soon I'll start work on some code to run on an ARM core. In the meantime, though, they have me learning more about hardware via soldering together my own ISA board, at my request. =)
My suggestion is to find a job which involves minor embedded stuff while not being the main focus of the job, so you can ease yourself into it. Knowing linux, java, or other highlevel constructs can get you such a job, but won't be used too much later on when you get to lower level things. I think knowledge of an assembly language or two is far more important. (I still don't know x86 very well, but I learned MOS6510 assembly a long time ago, which I haven't used directly, but the fundamentals have helped)
And yet Charter Pipeline won't even offer one direction at 1.5Mbit reliably. That figures. It just goes to show, though - if you want something done right, do it yourself.
I think this will prove more interesting to those who want to create network links for personal use, rather than those who want to provide large-scale broadband access. As such, its nice to have the extra option out there, but it doesn't offer anything unique.
Thats 10Mb(it), not 10MB(yte). DSL is capable of this speed too. Like DSL, its pretty good at running over crap cable, but quality varies with the wiring.
This is a different (fault-tolerant) modulation format for ethernet frames. DSL is a different (fault-tolerant) modulation format for ATM frames.
I think this is interesting, because ethernet doesn't have as many things to mess up, like, for instance, matching the VCI and VPI up on both ends. On the other side of the coin, though, you don't get the subnet seperation and traffic shaping that ATM offers natively. In terms of moving packets from point A to point B, the technologies seem roughly equivelant to me.
Also remember, DSL is capable of 10MBit, and I don't know how much HFC cable is capable of, but if you ever see an ISP deploying this, don't expect them to give you the full capabilities of the wire - broadband ISPs never do (all of the ones I've tried cap bandwidth higher up in the network regardless of what the technology is capable of).
I'm in the middle of a sparetime project based around an Analog Devices DSP. I'm curious why your statement is true, especially since its so easy... anyone who knows algebra can read AD DSP assembly fairly easily. The only tricky part to writing it is sorting out your algorithm to take the most advantage of parallel instruction execution.
Are other vendors' DSPs (TI comes to mind) more difficult to understand?
Developers obviously have a benefit to knowing assembly, if no reason other than debugging skill. Those who don't know it are reduced to blaming Bill, other components of the system, or the hardware, all of which are counterproductive excuses at best.
I believe sysadmins have a benefit to knowing it as well, simply because you know whats going on under the hood, so to speak. This kind of knowledge allows you to actually understand the worth of things like 3DNow!, SSE/SSE2/MMX, pipeline length, cache consistency, hyperthreading, and all the other things that vary from processor to processor and from software package to software package. I believe this is important because you aren't reduced to cointosses for whose hype to believe, when deciding what things to buy/download and deploy.
In addition, if assembly wasn't relevant for administration of a system, why would you include register dumps in bluescreens/Oopses? Rebooting doesn't cut it, that only temporarily alleviates symptoms and doesn't solve the problem. I believe "keeping a system running smoothly" definately counts as a sysadmin's role, therefore a sysadmin should have good debugging skills. Even if you pass the debugging off to someone who would know, wouldn't it be nice to know WHICH hex numbers on that bluescreen would be helpful to him/her in finding the bug?
If you're constantly answering questions like "I forgot my password", "is the network down?", and "I need a damned good kicking please?", then perhaps assembly wouldn't help you here (unless you're trying to achieve BOFH-style *DUMMY MODE*). However, this means you are either not a sysadmin or are wearing multiple hats - this stuff is commonly called "Tech Support".
Uhh, you can "apt-get install avifile-player" if you like. Its in sid, at least, not sure about the others.
What you're asking for is called multicasting, and unfortunately either requires IP tunneling or hardware support every step of the way. Some IPv4 ISPs support it (starband claims to, for instance) but most don't bother to.
As with most optional technologies, until a critical mass is reached, noone's going to bother to support it.
Fortunately, multicasting is one of the requirements for IPv6 compliance. Of course, since IPv6 is itself currently considered another of those "optional technologies", for now people who really want this tend to roll their own.
If you want to help, do so! People are obviously already throwing ideas around... for example, a quick websearch turned up a draft
RTP ogg payload spec, for multicasting ogg streams.
Gated has indeed gone commercial, however the older free version is still available (check BSD archives).
Zebra, as has already been mentioned, does RIP2, among other things.
Bird is another alternative which does RIP2.
I personally prefer bird, because I want only OSPF (IPv4 and IPv6), so the extra weight of zebra is lost on me. (oo big to easily embed)
My coworkers and I tend to use a form of steganography, on IRC. Its not typical pixel-in-picture stuff, though... rather, the script encodes messages (the current irssi perlscript implementation is 7-bit clean) in the entropy available in l3eT-babbling carrier text. For instance, "l" could be "l", "L", "|" or "1", meaning you could use an "l" character to store 2 bits of data. The output looks, as I'm sure you can guess, horrible.
For more important things, we tend to use ssh, but steganography isn't entirely forgotten here =)
* Disitributions should GET RID of old, clunky, insecure programs such as sendmail (replace with postfix), wuftp (replace with proftpd), inetd (replace with xinetd), etc.
Uhmm... proftpd has plenty of security problems too. In the few cases where I really have no choice but to run an ftpd, I use vsftpd.
In any case, its vital to keep up with things like bugtraq, look at everything discussed and fix everything that pertains to your boxes... this is made much easier when you've selected your server software with security in mind, but still just as important.
This is an interesting idea. Indeed, a patent needs to clearly document the process to which it applies.
However, patents apply to processes. So what if someone patents the process of writing code to encrypt/decrypt text using XOR, for example? I can definately see this as being a problem, especially when a large amount of investment is tied up in intellectual property. This leads to a situation similar to the availability of Reed-Solomon codecs, for example (generally implemented in un-reverse-engineerable silicon, and always requiring heavy licensing).
I should patent the process of depressing a shift key for the purpose of gaining access to other symbols on the keyboard... and then sue non-Free vendors for infringing on it (its hard to code in ANY language without the shift key)!
Automated script ... unauthorized access ... felony.
(*lets that sink in*)
So that means if I had the money right now, I could hire 500 head of lawyer and, wielding my trusty apache logfiles, start 500 lawsuits against the people who, by means of gross administrative irresponsibility, have machines which are running automated scripts which are attempting to gain unauthorized access to my machine (and failing), and win each of those lawsuits because doing so is a felony?
That would be sweet justice. However, I don't think the case would hold up, regardless of who sued who.
Thats the correct way to use uniq, yes. However, since the dates and times are all different, uniq won't do much. All that addition would end up doing is sorting by IP address, rather than by time.
That'll work, until the machines get infected again. I'd rather shutdown the machine entirely, or disable all the NICs, or something.
Its important to get admin intervention. If the admin doesn't know about the problem, you have to let him/her know. If the admin doesn't even know they were running IIS, again, time for a wakeup call.
Disabling the backdoor will work, until the machine gets infected again. It also won't halt the spread, unless the worm somehow depends on infected.dat?
Stopping the IIS service also has the problem of not delivering a wakeup call to those who don't even know they were running it. I don't want to support bad administration.
I'm looking for a way to shut down the machine, stop all the NICs entirely, stop all IPv4 support, or something else disabling the machine and requiring admin intervention. If thats possible, that will FORCE the admin to take responsibility for their box, and effectively disable that box until they do so.
The problem is finding such a thing with a command-line interface, without a confirmation prompt. Any ideas?
If they checked their logs, they'd see upwards of 300 infections daily anyway. At that point, its difficult for them NOT to be aware of the worm.
More likely is that a lot of the machines are unattended, and/or their users are unaware of even HAVING IIS.
My own experience:
In 1996 I paid $50 for a Red Hat Linux set.
I've tried 5 distros since then, eventually settling on Debian, and not paying for any of them (unless you count submitting bugreports and (more often) patches, which, although its the best gift one can give and all, is technically charity anyway).
I've never paid for a Microsoft OS.
My workplace's experience:
My boss pays a yearly subscription for MSDN. He's never paid a cent for Linux, though his network is completely dependent on it.
For administration, about 5 times as much is paid (in terms of employee time spent) yearly to configure and maintain Windows machines than is paid to configure and maintain linux machines. (I feel this is a fair comparison, as we have one windows 2000 server and one linux server/router)
Hope this helps =)
--
Paranoid