It's not unreasonable to think that the two problems are related. This is, of course, based on the simple assumption that most people I converse with via e-mail on my particularly spammed account, do not use e-mail clients capable of propagating viruses. So obviously, the first sentence is true in at least 98% of the viruses I receive. I don't receive viruses from people I know. (that is a fact, may be different for different people)
Consider: most spammers use Outlook or Outlook Express. Every virus I've received was from Outlook or Outlook Express. The vehicles of propagation to the end receiver are still the same, be it spam or virus.
If all spammers, not just spamhauses, were eliminated, my virus count would likely be zero, or very close to it. The distinction between the two is irrelevent to me.
Not that I mean to be inflammatory, but what you said strikes me as though you were saying that I shouldn't hold spammers responsible for the doubling in size of the total amount of garbage I receive daily (because of viruses). I mean, give me a break, I'm on a 56k.
Yeah, true, but this doesn't stop the flux of spamhaus cohorts' virus-infected computers sending me their pestilence simply because I'm still on their "hit lists" or whatever. That's basically evidence that even if the root of the problem is taken care of, that the symptoms can still persist.
Unsolicited e-mail, spam or virus, all the same to me.
I really do wonder how this guy offended any moderators.
I honestly used to believe that moderators were supposed to be moderate.
Anyways, back to the topic at hand, yes, I think he's onto something. I'm observing a lot of friends having to replace their 48x discs rather often; like, to the tune of six months.
Now the only thing I'm worried about are those cyanine-loving bacteria. If I can protect against those, then I can keep a CD healthy. After all, I've been using some of the same CD-Rs for three years quite actively, and they are yet to die. But I should get around to making permanent shelved copies...
heh heh, yeah, apples, oranges, I understand. There is that bit of charm about his movies. And it certainly is entertaining to read about his war stories, clad in red panties and all on the warfront;) Not slamming the man, just the movies, when compared to shit like Gigli. But hey, I digress. Without Ed Wood, where WOULD we be? *reflects upon that*
I hate to reply to my own post, but I don't see why using this technology is not relevant to doing something such as, say, mapping those potholes. Why the offtopic moderation?
As a sibling post says, yeah, the map will not be accurate for more than two days, but hey. The map could be generated by the city yearly, perhaps to help manage funds for city works such as repairing the damned potholes.
I could probably do an hours worth of digressing here, but, bleh.
We've got Links, Dillo, and we could probably get Gecko working within reasonable constraints. We have commercial products on our side such as Netfront, Opera. If you're talking QNX, you've also got Voyager. So yeah, Windows, 0, the other guys, 1.
On a consumer level, there are no real benefits to using Windows on embedded controllers, or even developing for evaluation boards.
Although I deviate from Linux in this example, it is still relevant to all open source embedded solutions. A few questions: is there an implementation of Remote Terminal Services for embedded versions of Windows, for easy manipulation of the embedded device in question? If so, what sort of licensing costs are implied?
As demonstrated numerous times before, open standards such as VNC are superior in the aspects of platform-ubiquity, openness, freeness, and simplicity. A shining example of what would be a costly, if implemented, solution, under Windows would be the Ethernet board running Contiki.
Oh yeah, and how many simultaneous threads, per-process-threads, and processes, do embedded Windows products support?
One must also compare the existing products that can be compiled between embedded Linux and Windows. I'm willing to bet software written with POSIX in mind beats Windows.
Excuse me if these speculations seem a bit armchair.
I never buy a new hard drive until it's the 3rd or so generation, much in the same way I cannot trust a Linux kernel for two releases.
This holds doubly true with Western Digital, but I'm usually confident with buying any Seagate SCSI hardware. I have no idea why, but I've only ever had a single SCSI drive die, and it was my Mac SE/30's full height 40MB Seagate. And it would still be useful had the SE/30 not been dropped quite abruptly:-/
Aww c'mon, I'm a slashdotter, we're supposed to be disgruntled once a day at least!
But the elusive bzip2 flag does get to me when moving between a NetBSD, a Slackware, a Debian, and a Red Hat machine. Sometimes, due to very similar-looking shell prompts with ssh sessions in xterms all over the place, the hostname displayed is not a good enough reminder of where I am.
Rather than breaking scriptability like other posters in this thread have suggested, why can't we unify all decompression operations under a single flag, '-z'? tar does not create compressed archives, so it is irrational to differentiate between -z and the various flags to un-bzip2. I've seen -I, -j, and -y, and that's pretty fucking ridiculous. It is NOT HARD at all to implement this change, and if more people saw sense in my grievances, I would submit the patch myself.
It's a simple matter of reading the first four bytes of input and determining which decompression tool to used, based on that magic string. Sigh.
I'm tired of reading the manual page for tar just to see how to untar a.tar.bz2 file when I encounter a different environment.
Not only do intelligent package mechanisms have serious shortcomings for users, but they are also a large boon to system administrators.
I'm not making an attempt to argue against Zero Install, but I am suggesting that a comparison of things like APT to Zero Install is not distant from apples and oranges. Both systems are rather good at what they do, but are tailored for specific purposes.
Now, if you'd like to see Zero Install used in every aspect of your *n?x experience, the underpinnings of the userland would definately have to change.
On the side, I'm not guessing that Zero Install will alleviate every dependency, though it will definately help in solving them in an obvious manner, a matter of simply dropping a directory in ~/Apps.
I do apologize if all of this is rather obvious to you, tal, though this is mostly geared towards the rest of the/. crowd.
Don't get me wrong, this is wholly hypothetical on the whole (erm), but I can personally attest to this.
If people were to learn a bit more about the IPv6 address (like, how it's structured), then the brain somehow is able to logically deduct a network address from a host address, thus the IPv6 address is turned into two separate strings to remember. I'm sure that in the beginning of mass IPv6 deployment, the majority of people are going to be using the same few/32 (or so) delegations, thus the network portion of the address will remain the same for a lot of hosts. I'm guessing the real duty would be remembering your MAC address.
And whoever said you couldn't compact a group of zeroes with the '::'? This can only be used once in an IPv6 address, or else expansion becomes ambiguous.
Nah, screw that. I'll just stick to using DNS to resolve these 128-bit addresses (as previously noted by another poster). That depends on DNS servers upgrading to BIND 9 to support IPv6 sockets, though.
I hate to nitpick, but just to affirm my point, I have to say that rpm2cpio simply isn't available on every system. Of course, one could remedy that by writing a snippet of code that skips all of the RPM header data and starts outputting the contents of an RPM as soon as it has hit a gzip header; then piping it to gunzip and cpio -div. But not everyone is willing to do that;x
Though I do thank you for adding that bit of information.
From a technical standpoint, I find that creating a Debian package would be far easier than creating a Red Hat package. Essentially, a packager does not require any special tools to create a package; all one needs is ar, tar, and gzip, and a text editor to write the package control data. This feature-by-design allows poor ol' me, without any Debian machines, to create packages, assuming a similar development environment and libraries as the Debian environment I'm targeting (which really should not be hard, provided the libraries I use are of the same version).
Similarly, I could install a Debian binary package if that were all that existed for my particular environment, with a simple
$ ar p data.tar.gz package-arch.deb | (cd/; tar -p -zxf -)
(I digress, simple may be relative)
On the other hand, since RPMs have a special binary header, the lazy would be forced to install RPM and Berkeley DB on non-Red Hat-machines in order to build an RPM package. Though it is possible to extract the gzip'ed+cpio'ed data in an RPM without using rpm.
So, in my view, Debian has a bit of an upper hand in simplicity, from a technical standpoint, but not by much.
Slashdot Mirror
Like I said, these are individual circumstances. I've yet to receive a single spam or virus on my private e-mail account.
Now someone SHOULD shoot me and mod my post down to -1 for being off-base on the Outlook thing. Please?
I'm sorry if I'm off-base or have offended you.
So? I'm still receiving viruses from spammers.
.
It's not unreasonable to think that the two problems are related. This is, of course, based on the simple assumption that most people I converse with via e-mail on my particularly spammed account, do not use e-mail clients capable of propagating viruses. So obviously, the first sentence is true in at least 98% of the viruses I receive. I don't receive viruses from people I know. (that is a fact, may be different for different people)
Consider: most spammers use Outlook or Outlook Express. Every virus I've received was from Outlook or Outlook Express. The vehicles of propagation to the end receiver are still the same, be it spam or virus.
If all spammers, not just spamhauses, were eliminated, my virus count would likely be zero, or very close to it. The distinction between the two is irrelevent to me
Not that I mean to be inflammatory, but what you said strikes me as though you were saying that I shouldn't hold spammers responsible for the doubling in size of the total amount of garbage I receive daily (because of viruses). I mean, give me a break, I'm on a 56k.
Tee hee hee. Nothing personal. :)
Yeah, true, but this doesn't stop the flux of spamhaus cohorts' virus-infected computers sending me their pestilence simply because I'm still on their "hit lists" or whatever. That's basically evidence that even if the root of the problem is taken care of, that the symptoms can still persist.
Unsolicited e-mail, spam or virus, all the same to me.
I really do wonder how this guy offended any moderators.
I honestly used to believe that moderators were supposed to be moderate.
Anyways, back to the topic at hand, yes, I think he's onto something. I'm observing a lot of friends having to replace their 48x discs rather often; like, to the tune of six months.
Now the only thing I'm worried about are those cyanine-loving bacteria. If I can protect against those, then I can keep a CD healthy. After all, I've been using some of the same CD-Rs for three years quite actively, and they are yet to die. But I should get around to making permanent shelved copies...
heh heh, yeah, apples, oranges, I understand. There is that bit of charm about his movies. And it certainly is entertaining to read about his war stories, clad in red panties and all on the warfront ;) Not slamming the man, just the movies, when compared to shit like Gigli. But hey, I digress. Without Ed Wood, where WOULD we be? *reflects upon that*
Plan Nine from Outer Space.
:)
That HAS to be the worst movie ever.
We're all STILL on a...power (as in zap-zap fizzle 120VAC) trip!
Seems like the /. editors are on a bit of a power trip!
I hate to reply to my own post, but I don't see why using this technology is not relevant to doing something such as, say, mapping those potholes. Why the offtopic moderation?
As a sibling post says, yeah, the map will not be accurate for more than two days, but hey. The map could be generated by the city yearly, perhaps to help manage funds for city works such as repairing the damned potholes.
I could probably do an hours worth of digressing here, but, bleh.
Let's map them potholes. 'nuff said.
We've got Links, Dillo, and we could probably get Gecko working within reasonable constraints. We have commercial products on our side such as Netfront, Opera. If you're talking QNX, you've also got Voyager. So yeah, Windows, 0, the other guys, 1.
On a consumer level, there are no real benefits to using Windows on embedded controllers, or even developing for evaluation boards.
Although I deviate from Linux in this example, it is still relevant to all open source embedded solutions. A few questions: is there an implementation of Remote Terminal Services for embedded versions of Windows, for easy manipulation of the embedded device in question? If so, what sort of licensing costs are implied?
As demonstrated numerous times before, open standards such as VNC are superior in the aspects of platform-ubiquity, openness, freeness, and simplicity. A shining example of what would be a costly, if implemented, solution, under Windows would be the Ethernet board running Contiki.
Oh yeah, and how many simultaneous threads, per-process-threads, and processes, do embedded Windows products support?
One must also compare the existing products that can be compiled between embedded Linux and Windows. I'm willing to bet software written with POSIX in mind beats Windows.
Excuse me if these speculations seem a bit armchair.
I wish I could mod you up as Flamebait, in that particularly glorifying manner.
I never buy a new hard drive until it's the 3rd or so generation, much in the same way I cannot trust a Linux kernel for two releases.
:-/
This holds doubly true with Western Digital, but I'm usually confident with buying any Seagate SCSI hardware. I have no idea why, but I've only ever had a single SCSI drive die, and it was my Mac SE/30's full height 40MB Seagate. And it would still be useful had the SE/30 not been dropped quite abruptly
Aww c'mon, I'm a slashdotter, we're supposed to be disgruntled once a day at least!
But the elusive bzip2 flag does get to me when moving between a NetBSD, a Slackware, a Debian, and a Red Hat machine. Sometimes, due to very similar-looking shell prompts with ssh sessions in xterms all over the place, the hostname displayed is not a good enough reminder of where I am.
If only we could agree on one stupid bzip2 flag.
yeargh, foiled, -1 uninformative :-/
Rather than breaking scriptability like other posters in this thread have suggested, why can't we unify all decompression operations under a single flag, '-z'? tar does not create compressed archives, so it is irrational to differentiate between -z and the various flags to un-bzip2. I've seen -I, -j, and -y, and that's pretty fucking ridiculous. It is NOT HARD at all to implement this change, and if more people saw sense in my grievances, I would submit the patch myself.
.tar.bz2 file when I encounter a different environment.
It's a simple matter of reading the first four bytes of input and determining which decompression tool to used, based on that magic string. Sigh.
I'm tired of reading the manual page for tar just to see how to untar a
Not only do intelligent package mechanisms have serious shortcomings for users, but they are also a large boon to system administrators.
/. crowd.
:)
I'm not making an attempt to argue against Zero Install, but I am suggesting that a comparison of things like APT to Zero Install is not distant from apples and oranges. Both systems are rather good at what they do, but are tailored for specific purposes.
Now, if you'd like to see Zero Install used in every aspect of your *n?x experience, the underpinnings of the userland would definately have to change.
On the side, I'm not guessing that Zero Install will alleviate every dependency, though it will definately help in solving them in an obvious manner, a matter of simply dropping a directory in ~/Apps.
I do apologize if all of this is rather obvious to you, tal, though this is mostly geared towards the rest of the
(btw, ROX rocks
I'll bet the Unix world is pretty tedious.
> I have worked for 3 separate companies where almost every male employee ran linux.
So what did the female employees use?
I don't mean to nitpick here; I agree on all other points, but perhaps you could clarify which view was represented by the MCSE type you've specified.
Under Mac OS X, you need to include stdlib.h in order for the preprocessor to see exit(3).
Don't get me wrong, this is wholly hypothetical on the whole (erm), but I can personally attest to this.
/32 (or so) delegations, thus the network portion of the address will remain the same for a lot of hosts. I'm guessing the real duty would be remembering your MAC address.
If people were to learn a bit more about the IPv6 address (like, how it's structured), then the brain somehow is able to logically deduct a network address from a host address, thus the IPv6 address is turned into two separate strings to remember. I'm sure that in the beginning of mass IPv6 deployment, the majority of people are going to be using the same few
And whoever said you couldn't compact a group of zeroes with the '::'? This can only be used once in an IPv6 address, or else expansion becomes ambiguous.
Nah, screw that. I'll just stick to using DNS to resolve these 128-bit addresses (as previously noted by another poster). That depends on DNS servers upgrading to BIND 9 to support IPv6 sockets, though.
I hate to nitpick, but just to affirm my point, I have to say that rpm2cpio simply isn't available on every system. Of course, one could remedy that by writing a snippet of code that skips all of the RPM header data and starts outputting the contents of an RPM as soon as it has hit a gzip header; then piping it to gunzip and cpio -div. But not everyone is willing to do that ;x
Though I do thank you for adding that bit of information.
Similarly, I could install a Debian binary package if that were all that existed for my particular environment, with a simple
(I digress, simple may be relative)
On the other hand, since RPMs have a special binary header, the lazy would be forced to install RPM and Berkeley DB on non-Red Hat-machines in order to build an RPM package. Though it is possible to extract the gzip'ed+cpio'ed data in an RPM without using rpm.
So, in my view, Debian has a bit of an upper hand in simplicity, from a technical standpoint, but not by much.