3 years ago you should've seen what was happening to this industry and switched majors. You're hosed now, and there's no good answers. Take a crappy programming job for now to help pay the bills and attend bartending school at night to start working on a real career, that's my advice.
You can't slap a buzzword like RAID onto whatever you were doing before and expect results. Reliable systems have to be carefully engineered correctly.
From the sound of your posting, I'm assuming when you say you're using RAID, you mean internal RAID cards inside a server with internal disks attached, and relatively small amounts of it. In these types of scenarios, the highest performing, most reliable, and most cost effective option is to put two seperate scsi controllers in your boxes, buy twice as much storage as you need, and mirror between the controllers using the OS's software mirroring capabilities. You are now indepedant of controller failure, the controllers themselves are less likely to "fail" (which doesn't always mean hardware frying) than a complex raid controller by their simpler nature, and you're getting the performance benefit of full mirroring instead of that clunky raid5 business. If you have enough storage to warrant four or more internal disks of some size, use mirror+striping. Always mirror at the lowest level, and then stripe on top of that (in a 4 disk design actually it doesn't matter which way you layer them, but in 6+ disk designs it gives higher data availability in the unlikely event of multiple disk failures). Or in other words - raid5 and hardware cards = bad, mirroring/striping + software raid = good.
Your goal is not to be buzzword compliant by slapping in a raid controller, your goal is to carefully analyze your systems, your options, your requirements, and your budget, and eliminate single points of failure everywhere that it's feasible and desirable to do so, starting with the lowest MTBF items in the system and working your way up. There are no magic bullet answers of course - change the situation and the "right" answer can change dramatically.
This is often true for larger programs, but there's a certain amount of unavoidable overhead that often makes it not true for smaller programs. There was a contest a while back to write the smallest ELF binary that could do some trivial task (exit with a given return value I think?). Doing it in straight C dynamically linked like "normal" gave an executable that runs several k on most platforms, even though the C code amount to a single short line. There are ways around this, the winningest guys ended up with extremely short binaries by hacking around a lot manually with a hex editor in assembly rather than bothering with the compiler.
I'm sure someone will eventually notice an applicable remote exploit, it's bound to happen at some point. If they designed the embedded devices to be static (everything important on read-only roms, software upgrades to be done by running around to each one physically and replacing them), then as time passes the likelyhood of exploit will only grow and grow. If they designed them to be auto-updateable over the wireless network, then when someone finds an exploit before they manage to patch said exploit, they'll probably use it to re-install things their own way across the network, locking out further updates from the city, forcing the city guys to go out and manually clean out each machine by hand (erase/replace the flash storage that the OS and binaries was on).
What it means is that OpenBSD's tcp stack by default has some of the neccesary protections to slow down or stop this attack, like randomized source ports, randomized TCP ISNs, etc.
When they say 64kb, 96kb, etc in the article, they mean executable size. 2k of C source, depending on what's in it, could be and likely is much larger in binary form.
So in other words, you're a spammer in denial, who likes to look down on other spammers and blame your legal and practical problems on those pesky other spammers.
spam is spam is spam, "legal bulk emailer" = we duped some idiot into not unchecking a small box on a form somewhere or duped him nito accidentally clicking yes somewhere he shouldn't have, therefore we're legally ok to spam him with his "consent".
Building a proper projectile around that capsule wouldn't be too hard. Obviously the RFID capsule itself isn't what's chambered into the rifle. More than likely you would construct something similar to a standard centerfire rifle cartridge, but with a new-design projectile for implanting the things. Some lead weight in the back, a razor sharp front edge for piercing the skin, and the right velocity at the end of the flight path (enough to penetrate the skin with a razor isn't much). The real challenges/downfalls within this are:
1) The cartridge would have to be for a certain range to target. If you want adaptability in range to target, you'll have to carry several rounds, maybe one that says 50-100m, one that says 100-200m, etc.
2) The lead weight on the outside/back of the razor rfid payload will neccesarily smack the target's skin right after insertion. It wouldn't be a very hard hit, but it might be more noticeable than the insertion itself.
It's all about the distro. Linux is a kernel, and only the individual distros really count as an "OS". Some Linux distros turn everything on (mentioned above), some turn everything off (check out gentoo, the basic install has just about jack shit enabled until you do so explicitly).
I believe it could possibly be real. When they call it a "GPS chip", what they really mean is that it's an RFID transponder, which when combined with their RFID tracking stations will GPS-locate the wearer of the chip. The idea would be to pepper a metro area with their transponders, which do have GPS hardware, and to track the transponders the person passes by.
Of course, current RFID transponders have far too limited a range (a few feet) to do this effectively. But who knows if they've managed to work out something that can transpond across a city block.
The blurb tries to make it sound like they invented something magical, but they didn't. Basically, a company called ClearPlay has humans that watch popular movies, and makes a note of all the "bad" audio/video spots in the movie. They make a big censoring list, and the player IDs the movie against that list and skips the parts the ClearPlay guys said to skip. The database of movie titles is at about 500 so far, which is far, far short of the number of DVDs at your typical rental store. The mentioned Janet Jackson incident, which was live TV, and has nothing at all to do with cencsoring your DVDs.
Master discs still make no sense to me for CD/DVD. It's digital data. The original data is bits, which I can store in a mirrored drive array and back up several copies of to tape if I feel the need. I can make "perfect" copies from this source, and the source never goes bad. So why worry about the physical precision of a supposed master disc, which then has to be read into bits and written into another disc, when we can just read the bits stored in a hard drive somewhere and do the same?
The LD50 of coffee is 192 mg/kg, which means for an average 200 pound male you stand a roughly 50/50 chance of dying if you ingest about 17 grams of caffeine.
I don't know the specifics of your coffee, but I'm sure yuo can look up the caffeine content per cup and go from there. Rememeber that the 192mg/kg is for a single dosage all at once, you can probably ingest way more than that over the course of 24 hours as your body processes it out, but if I were you I certainly wouldn't exceed the LD50 amount within a period of an hour or two.
While they make a good case about how impossible it is to determine legal jurisdiction and determine the existance and nature of legal violations, the technical issues that they raise with this RFC would mostly be solved by pervasive DRM. Eventually, every PC, every NAT/router box, etc will have embedded DRM, and you won't be able to stop the deployment and invisibility of something like OP with DRM (with keys controlled by all the wrong people) in your way.
The anti-spam angle is a very good one. With the amount of email google will likely be receiving and archiving in this system - they could turn around and sell anti-spam services to ISPs and corporations that uses software which does a remote anti-spam check back to google's main engine. There's really only two likely outcomes in that situation, both favorable:
1) Google gets to sell the best anti-spam commercial service ever, profit.
2) Spammers figure out this scheme and decide to never spam gmail accounts so that they don't help google block corp/isp access of the spammers, and gmail customers become a spam-free zone, sign up lots more accounts, indirect profit.
Install from source, automatically with nice package tree management and dependency tracking. If you feel the need to custom compile a package or two in such a way that precludes using their automated build system, you can do it manually and then "inject" the package into your installed base, so that dependencies work for the manually added package.
Re:He's misinformed on a geopolitical resource sca
on
The Wrong Stuff
·
· Score: 1
The current fusion reactor building coalition between US/EU/Japan announced a couple months ago the start of construction on what I would paraphrase as their "final beta" reactor. They expect to sort out the remaining hurdles during this project, and the next reactor design should actually work and be deployable. I'm not sure exactly what that means in real time, but I would guess 10-30 years isn't a bad range. Considering the amount of space (and land-based) infrastructure we have to build in order to commercially strip-mine Helium3 from the moon and how many years that will take, it's high time we got busy.
He's misinformed on a geopolitical resource scale
on
The Wrong Stuff
·
· Score: 1
On the timescales on speaks of when considering deploying permanent bases of humans on the moon, we face a serious issue in the hubbert oil peak problem, which will eventually crash our oil-based economy unless we come up with a new plentiful energy resource. Most "alternative" methods we have today simply make things more efficient on a global scale and are incapable of replacing the oil dependency. One of the most probable and workable solutions in the long term view is that we finish the current ongoing work to build stable fusion reactors here on earth for power. One of the best fuel sources around for them is to strip mine the moon for Helium3. I think the realization of the importance of these things is the driving force behind the president's renewed interest in space and the moon.
Well, for one, obviously the author of badgerbadgerbadger.com has access to some seriously high quality psychodelic drugs. If you listen closesly though, you'll notice that the audio never says the word badger. The "badger" part of the song is just a rythmic sound. But you're staring at badgers, and you're at badgerbadgerbadger.com, so your mind convinces you that it must be saying badger.
If you did that, the key is nowhere near "random". A better adjective might be "meaningless in terms of dictionary attacks".
On a side note, it really doesn't matter what your WEP key is. Even if you used a quantum random number generator for your WEP key, it's pretty trivial for your neighbors to break it, sniff your traffic, inject traffic, etc. The code is out there for download, has been for a long time.
I might add that even when you're not worried about viruses, the benefit of not displaying emails unless you really want them displayed is that it keeps you from loading the gifs in spam/porn emails, which helps keep them from validating that you're reading their emails. When you select that kind of spam to delete it in outlook, if the gifs start to load in the preview pane, you just responded positively to their ad in a way - many of them encode a unique identifier in the gif urls for the email address they spammed you at.
Mozilla itself has gotten much better since the 1.2 days as well. Personally, I like and advocate Thunderbird, especially because it's very good about not spreading email plagues like the ones in the article. YMMV, maybe you'd hate the slight differences in interface layout. Aside from the fact that it won't execute code for you in your emails to begin with (unless you tell it to explicitly), it also does *not* display the email contents in the preview pane when you right-click a mail to select Delete or to move it to a junk folder or whatever, and it also doesn't display anything in the preview pane when you select multiple emails for such an operation.
While it's true that it's technically alpha quality, it borrowed a lot of well-tested code, and from the first time I ever downloaded it, I've never had any functional issues with it. I use it daily at work for my corporate email (I basically ignore my loss of outlook's calendaring, it's a problem, but one I can deal with) on standard win2k corporate setup, I use it at home on Winxp against a standard linux-based postfix+uw-imap server, and I use it under a Gentoo Gnome desktop in both environments as well. I feel pretty comfortable recommending it over Outlook, with the exception of the "can't do exchange calendaring" issue.
Slashdot Mirror
3 years ago you should've seen what was happening to this industry and switched majors. You're hosed now, and there's no good answers. Take a crappy programming job for now to help pay the bills and attend bartending school at night to start working on a real career, that's my advice.
You can't slap a buzzword like RAID onto whatever you were doing before and expect results. Reliable systems have to be carefully engineered correctly.
From the sound of your posting, I'm assuming when you say you're using RAID, you mean internal RAID cards inside a server with internal disks attached, and relatively small amounts of it. In these types of scenarios, the highest performing, most reliable, and most cost effective option is to put two seperate scsi controllers in your boxes, buy twice as much storage as you need, and mirror between the controllers using the OS's software mirroring capabilities. You are now indepedant of controller failure, the controllers themselves are less likely to "fail" (which doesn't always mean hardware frying) than a complex raid controller by their simpler nature, and you're getting the performance benefit of full mirroring instead of that clunky raid5 business. If you have enough storage to warrant four or more internal disks of some size, use mirror+striping. Always mirror at the lowest level, and then stripe on top of that (in a 4 disk design actually it doesn't matter which way you layer them, but in 6+ disk designs it gives higher data availability in the unlikely event of multiple disk failures). Or in other words - raid5 and hardware cards = bad, mirroring/striping + software raid = good.
Your goal is not to be buzzword compliant by slapping in a raid controller, your goal is to carefully analyze your systems, your options, your requirements, and your budget, and eliminate single points of failure everywhere that it's feasible and desirable to do so, starting with the lowest MTBF items in the system and working your way up. There are no magic bullet answers of course - change the situation and the "right" answer can change dramatically.
This is often true for larger programs, but there's a certain amount of unavoidable overhead that often makes it not true for smaller programs. There was a contest a while back to write the smallest ELF binary that could do some trivial task (exit with a given return value I think?). Doing it in straight C dynamically linked like "normal" gave an executable that runs several k on most platforms, even though the C code amount to a single short line. There are ways around this, the winningest guys ended up with extremely short binaries by hacking around a lot manually with a hex editor in assembly rather than bothering with the compiler.
I'm sure someone will eventually notice an applicable remote exploit, it's bound to happen at some point. If they designed the embedded devices to be static (everything important on read-only roms, software upgrades to be done by running around to each one physically and replacing them), then as time passes the likelyhood of exploit will only grow and grow. If they designed them to be auto-updateable over the wireless network, then when someone finds an exploit before they manage to patch said exploit, they'll probably use it to re-install things their own way across the network, locking out further updates from the city, forcing the city guys to go out and manually clean out each machine by hand (erase/replace the flash storage that the OS and binaries was on).
What it means is that OpenBSD's tcp stack by default has some of the neccesary protections to slow down or stop this attack, like randomized source ports, randomized TCP ISNs, etc.
When they say 64kb, 96kb, etc in the article, they mean executable size. 2k of C source, depending on what's in it, could be and likely is much larger in binary form.
So in other words, you're a spammer in denial, who likes to look down on other spammers and blame your legal and practical problems on those pesky other spammers.
spam is spam is spam, "legal bulk emailer" = we duped some idiot into not unchecking a small box on a form somewhere or duped him nito accidentally clicking yes somewhere he shouldn't have, therefore we're legally ok to spam him with his "consent".
Building a proper projectile around that capsule wouldn't be too hard. Obviously the RFID capsule itself isn't what's chambered into the rifle. More than likely you would construct something similar to a standard centerfire rifle cartridge, but with a new-design projectile for implanting the things. Some lead weight in the back, a razor sharp front edge for piercing the skin, and the right velocity at the end of the flight path (enough to penetrate the skin with a razor isn't much). The real challenges/downfalls within this are:
1) The cartridge would have to be for a certain range to target. If you want adaptability in range to target, you'll have to carry several rounds, maybe one that says 50-100m, one that says 100-200m, etc.
2) The lead weight on the outside/back of the razor rfid payload will neccesarily smack the target's skin right after insertion. It wouldn't be a very hard hit, but it might be more noticeable than the insertion itself.
It's all about the distro. Linux is a kernel, and only the individual distros really count as an "OS". Some Linux distros turn everything on (mentioned above), some turn everything off (check out gentoo, the basic install has just about jack shit enabled until you do so explicitly).
I believe it could possibly be real. When they call it a "GPS chip", what they really mean is that it's an RFID transponder, which when combined with their RFID tracking stations will GPS-locate the wearer of the chip. The idea would be to pepper a metro area with their transponders, which do have GPS hardware, and to track the transponders the person passes by.
Of course, current RFID transponders have far too limited a range (a few feet) to do this effectively. But who knows if they've managed to work out something that can transpond across a city block.
The blurb tries to make it sound like they invented something magical, but they didn't. Basically, a company called ClearPlay has humans that watch popular movies, and makes a note of all the "bad" audio/video spots in the movie. They make a big censoring list, and the player IDs the movie against that list and skips the parts the ClearPlay guys said to skip. The database of movie titles is at about 500 so far, which is far, far short of the number of DVDs at your typical rental store. The mentioned Janet Jackson incident, which was live TV, and has nothing at all to do with cencsoring your DVDs.
Doesn't this belong on an appropriate mailing list or something?
Your OS/2 comment shows a lack of understanding. How easily we forget that OS/2 was originally a joint project between IBM and Microsoft.
Master discs still make no sense to me for CD/DVD. It's digital data. The original data is bits, which I can store in a mirrored drive array and back up several copies of to tape if I feel the need. I can make "perfect" copies from this source, and the source never goes bad. So why worry about the physical precision of a supposed master disc, which then has to be read into bits and written into another disc, when we can just read the bits stored in a hard drive somewhere and do the same?
The LD50 of coffee is 192 mg/kg, which means for an average 200 pound male you stand a roughly 50/50 chance of dying if you ingest about 17 grams of caffeine.
I don't know the specifics of your coffee, but I'm sure yuo can look up the caffeine content per cup and go from there. Rememeber that the 192mg/kg is for a single dosage all at once, you can probably ingest way more than that over the course of 24 hours as your body processes it out, but if I were you I certainly wouldn't exceed the LD50 amount within a period of an hour or two.
While they make a good case about how impossible it is to determine legal jurisdiction and determine the existance and nature of legal violations, the technical issues that they raise with this RFC would mostly be solved by pervasive DRM. Eventually, every PC, every NAT/router box, etc will have embedded DRM, and you won't be able to stop the deployment and invisibility of something like OP with DRM (with keys controlled by all the wrong people) in your way.
The anti-spam angle is a very good one. With the amount of email google will likely be receiving and archiving in this system - they could turn around and sell anti-spam services to ISPs and corporations that uses software which does a remote anti-spam check back to google's main engine. There's really only two likely outcomes in that situation, both favorable:
1) Google gets to sell the best anti-spam commercial service ever, profit.
2) Spammers figure out this scheme and decide to never spam gmail accounts so that they don't help google block corp/isp access of the spammers, and gmail customers become a spam-free zone, sign up lots more accounts, indirect profit.
Install from source, automatically with nice package tree management and dependency tracking. If you feel the need to custom compile a package or two in such a way that precludes using their automated build system, you can do it manually and then "inject" the package into your installed base, so that dependencies work for the manually added package.
The current fusion reactor building coalition between US/EU/Japan announced a couple months ago the start of construction on what I would paraphrase as their "final beta" reactor. They expect to sort out the remaining hurdles during this project, and the next reactor design should actually work and be deployable. I'm not sure exactly what that means in real time, but I would guess 10-30 years isn't a bad range. Considering the amount of space (and land-based) infrastructure we have to build in order to commercially strip-mine Helium3 from the moon and how many years that will take, it's high time we got busy.
On the timescales on speaks of when considering deploying permanent bases of humans on the moon, we face a serious issue in the hubbert oil peak problem, which will eventually crash our oil-based economy unless we come up with a new plentiful energy resource. Most "alternative" methods we have today simply make things more efficient on a global scale and are incapable of replacing the oil dependency. One of the most probable and workable solutions in the long term view is that we finish the current ongoing work to build stable fusion reactors here on earth for power. One of the best fuel sources around for them is to strip mine the moon for Helium3. I think the realization of the importance of these things is the driving force behind the president's renewed interest in space and the moon.
Well, for one, obviously the author of badgerbadgerbadger.com has access to some seriously high quality psychodelic drugs. If you listen closesly though, you'll notice that the audio never says the word badger. The "badger" part of the song is just a rythmic sound. But you're staring at badgers, and you're at badgerbadgerbadger.com, so your mind convinces you that it must be saying badger.
If you did that, the key is nowhere near "random". A better adjective might be "meaningless in terms of dictionary attacks".
On a side note, it really doesn't matter what your WEP key is. Even if you used a quantum random number generator for your WEP key, it's pretty trivial for your neighbors to break it, sniff your traffic, inject traffic, etc. The code is out there for download, has been for a long time.
I might add that even when you're not worried about viruses, the benefit of not displaying emails unless you really want them displayed is that it keeps you from loading the gifs in spam/porn emails, which helps keep them from validating that you're reading their emails. When you select that kind of spam to delete it in outlook, if the gifs start to load in the preview pane, you just responded positively to their ad in a way - many of them encode a unique identifier in the gif urls for the email address they spammed you at.
Mozilla itself has gotten much better since the 1.2 days as well. Personally, I like and advocate Thunderbird, especially because it's very good about not spreading email plagues like the ones in the article. YMMV, maybe you'd hate the slight differences in interface layout. Aside from the fact that it won't execute code for you in your emails to begin with (unless you tell it to explicitly), it also does *not* display the email contents in the preview pane when you right-click a mail to select Delete or to move it to a junk folder or whatever, and it also doesn't display anything in the preview pane when you select multiple emails for such an operation.
While it's true that it's technically alpha quality, it borrowed a lot of well-tested code, and from the first time I ever downloaded it, I've never had any functional issues with it. I use it daily at work for my corporate email (I basically ignore my loss of outlook's calendaring, it's a problem, but one I can deal with) on standard win2k corporate setup, I use it at home on Winxp against a standard linux-based postfix+uw-imap server, and I use it under a Gentoo Gnome desktop in both environments as well. I feel pretty comfortable recommending it over Outlook, with the exception of the "can't do exchange calendaring" issue.