That depends on the marketing strategy. If it's a `cool new device for interacting with your friends`, I'm sure they'll get not so tech-savy or privacy-savy people to buy it.
Good point, I somehow didn't think of that when posting - probably because I'm used to working with "empty" Windows installations (I work for an OEM, mainly on preinstallations).
Agreed, their reasoning does sound sort of shady. Reading the article poses a question, how is "The court also noted that the technicians weren't randomly perusing the drive for contraband, but instead were testing its functioning in a "commercially accepted manner."
playing back a video (see article for context) going to help testing an installed drive? The only (far fetched) theory I could come up with, would be testing DVD playback software they installed with the burner; but c'mon, IF the staff were seriously going to test the drive, they would have burned c:\boot.ini or c:\windows or $any-other-folder-within-2-clicks-reach and then test the playback software with the latest porn flic on DVD laying around in their lab. I highly doubt someone would go through the trouble of searching for specific file types (videos/jpegs) if it weren't for harvesting data. I'm under the impression those 'technicians' simply haven't learned from the Geek Squad incident. Nonetheless in the end they did the right thing and hopefully that guy gets what he deserves.
>> How do you deal with large-scale legitimate mail sources (i.e. mailing lists, mail houses, etc.)?
There are two issues here. Mailing lists don't really have a good solution with the first generation of stamps. The traffic mailing lists generate is fundamentally indistinguishable from spammers, therefore whatever hurts spammers will hurt mailing lists. The answer for right now is to not do anything with mailing lists. Let them send unstamped mail and let the user whitelist mailing lists or deal with the trapped message issue manually.
In the future, it will become easier to deal with mailing lists because of the second generation of stamps (opportunistic signatures). If the list is signed with its own stamps, then it would be let through without problem. Spammers would still be barred because their signatures would be ignored.
The second issue is that mailing houses that deliver bulk e-mail for legitimate commercial ventures will need to generate stamps for some of their traffic. If they are sending newsletters to which users have subscribed, then the signature stamps method will work for them. Everything else is advertising mail and should be stamped. A circumstance in the future can be envisaged where mass mailers will try to cheat and use signature stamps for mailing lists to deliver commercial e-mail. Obviously there should be some method of responding, but that is not yet apparent.
In the meantime, these houses will need to generate stamps. While most of their server resources will be maxed out, they'll have idle resources on the desktop. A technique is being developed that allows a company to make use of its idle resources to generate stamps for its outbound mail. It will be up to each organization to determine what machines it wants to use and how high it wants to load them. If it's bulk e-mail with no particular need to deliver immediately, then a small number of heavily loaded machines should be sufficient. If it's urgent corporate mail, then they will want to have more machine resources than are needed for stamps.
if you RTFA, they want a whoppin 150$/year for ad-free 100GB.
To me that only makes sense for businesses, but then again, which business would need 100GB without being able to afford their own/co-located/hosted mailserver ?
I'd personally rather stick with gmail and use AdMuncher. Works like a charme.
Making a Kernel isn't too hard.
You find the correct image, (yep you probably want 2.6.7;), download the.tar.bz2 version.
To keep this short, we'll stick it in/usr/src:
1) su -
2) cd/usr/src
3) wget http://full.url.to.file.including.filename
4) tar xjvf linux-...tar.bz2
5) ln -s./linux-2.6.7./linux
6) cd linux-2.6.7
7) make menuconfig
8) configure options - read the help for information about options, if necessary google around, usually it's pretty easy to find information about specific options
9) make bzImage
10) make modules
11) cd arch/i386/boot/
12) cp bzImage/boot/
13) edit/etc/grub.conf with your favorite editor, basically adding the new image, using the existing one as template.
reboot and enjoy:)
You completely ignored my point as well:P I was trying to say that if you administrate a network you need to know what to do in order to maintain it. You are obviously more advanced than Joe Doe, yet you complain about your daily (weekly?) bread, that's what I was getting to. And, as I shortly mentioned before, there IS a solution for the average user who just installed Linux yesterday. Apt/Up2date/Emerge/and whatever their names are. It is also not about being cool, those are simple tasks that at least people who are willing to look into things can understand.
In simple words: (Corporate) Administrators, who need to apply patches within days/hours should know what they are doing, so they can do it efficiently and fast without having to rely on external help. Home users can wait until patches and updates hit the official distribution channels for their distro.
If you maintain a Linux system for a larger group of people, you should know what you are doing. Pardon me, but obviously you're not. As soon as I read this I upgraded our Firewall at work. I downloaded the latest 2.6, got the patch from the bottom of the linuxreviews site. That took about 4 minutes on a somewhat fast internet connection. Extracting the Kernel and patching it: 1 minute, brain involved: none (patch howto on that page as well, besides, if you are a real sysadmin you'll be able do kernel patches single fingered). Configuring the kernel: 1 minute as well, using make oldconfig (porting over my.config from 2.6.4, then answering a few questions for new options) brain involved: 1%, well documented in case of doubt. Compiling: make-kpkg kernel_image: 10 minutes, brain involved: 0%. Installing: dpkg -i../kernel....: 10 seconds, brain involved: 0%. Rebooting: about 1.5 minutes, brain involved: how fecking hard can it be to type 'shutdown -r now' ? or maybe even 'reboot':P
This also answers the other posting where somebody was whining about making the updates moronproof... Most distros have this 'feature', autoupdating, Redhat: up2date, Debian: apt (through security.debian.org),...
Slashdot Mirror
That depends on the marketing strategy. If it's a `cool new device for interacting with your friends`, I'm sure they'll get not so tech-savy or privacy-savy people to buy it.
nothing a piece of duct tape couldn't fix...
Good point, I somehow didn't think of that when posting - probably because I'm used to working with "empty" Windows installations (I work for an OEM, mainly on preinstallations).
Agreed, their reasoning does sound sort of shady. Reading the article poses a question, how is
"The court also noted that the technicians weren't randomly perusing the drive for contraband, but instead were testing its functioning in a "commercially accepted manner."
playing back a video (see article for context) going to help testing an installed drive? The only (far fetched) theory I could come up with, would be testing DVD playback software they installed with the burner; but c'mon, IF the staff were seriously going to test the drive, they would have burned c:\boot.ini or c:\windows or $any-other-folder-within-2-clicks-reach and then test the playback software with the latest porn flic on DVD laying around in their lab. I highly doubt someone would go through the trouble of searching for specific file types (videos/jpegs) if it weren't for harvesting data. I'm under the impression those 'technicians' simply haven't learned from the Geek Squad incident. Nonetheless in the end they did the right thing and hopefully that guy gets what he deserves.
Did you even read beyond the title? I wonder how you even managed to make it onto Slashdot...
It was ported, and it says so right in the text...
Thanks very much, -duh- but yeah, it _really_ is an exe.
well, besides that, nothing happens. it just flies by the text file.
You, my friend are even more of an idiot. He was attempting to make a joke (+ failed miserably) about making the _site itself_ a torrent.
How about RTFA ?
He's been to several docs and none have found anything significant, but he's obviously in a bad condition.
Thanks for RTFA
Jeez.
>>
How do you deal with large-scale legitimate mail sources (i.e. mailing lists, mail houses, etc.)?
There are two issues here. Mailing lists don't really have a good solution with the first generation of stamps. The traffic mailing lists generate is fundamentally indistinguishable from spammers, therefore whatever hurts spammers will hurt mailing lists. The answer for right now is to not do anything with mailing lists. Let them send unstamped mail and let the user whitelist mailing lists or deal with the trapped message issue manually.
In the future, it will become easier to deal with mailing lists because of the second generation of stamps (opportunistic signatures). If the list is signed with its own stamps, then it would be let through without problem. Spammers would still be barred because their signatures would be ignored.
The second issue is that mailing houses that deliver bulk e-mail for legitimate commercial ventures will need to generate stamps for some of their traffic. If they are sending newsletters to which users have subscribed, then the signature stamps method will work for them. Everything else is advertising mail and should be stamped. A circumstance in the future can be envisaged where mass mailers will try to cheat and use signature stamps for mailing lists to deliver commercial e-mail. Obviously there should be some method of responding, but that is not yet apparent.
In the meantime, these houses will need to generate stamps. While most of their server resources will be maxed out, they'll have idle resources on the desktop. A technique is being developed that allows a company to make use of its idle resources to generate stamps for its outbound mail. It will be up to each organization to determine what machines it wants to use and how high it wants to load them. If it's bulk e-mail with no particular need to deliver immediately, then a small number of heavily loaded machines should be sufficient. If it's urgent corporate mail, then they will want to have more machine resources than are needed for stamps.
if you RTFA, they want a whoppin 150$/year for ad-free 100GB.
To me that only makes sense for businesses, but then again, which business would need 100GB without being able to afford their own/co-located/hosted mailserver ?
I'd personally rather stick with gmail and use AdMuncher. Works like a charme.
This is only partly true - Progeny gives you (paid) support for debian.
Program accessibility & defaults... at least in XP SP1+
line :P
breaks
make
things
easier
to
read
DVD Decrypter uses the Nero engine too, just FYI.
lol !
;)
I was trying to point something out which might have been unknown to newer Debian users reading this.
Besides, I'm running 2.6.6
At least for us Debian-fanatics...
alien works perfectly well for importing rpms and solaris packages... never failed on me.
(Although in some cases a little directory tweaking might be necessary, but that`s really not that much of an issue, at least IMHO)
Well security is not a reason to update your system ?
Making a Kernel isn't too hard. You find the correct image, (yep you probably want 2.6.7 ;), download the .tar.bz2 version.
To keep this short, we'll stick it in /usr/src:
1) su -
2) cd /usr/src
3) wget http://full.url.to.file.including.filename
4) tar xjvf linux-...tar.bz2
5) ln -s ./linux-2.6.7 ./linux
6) cd linux-2.6.7
7) make menuconfig
8) configure options - read the help for information about options, if necessary google around, usually it's pretty easy to find information about specific options
9) make bzImage
10) make modules
11) cd arch/i386/boot/
12) cp bzImage /boot/
13) edit /etc/grub.conf with your favorite editor, basically adding the new image, using the existing one as template.
reboot and enjoy :)
You completely ignored my point as well :P
I was trying to say that if you administrate a network you need to know what to do in order to maintain it.
You are obviously more advanced than Joe Doe, yet you complain about your daily (weekly?) bread, that's what I was getting to.
And, as I shortly mentioned before, there IS a solution for the average user who just installed Linux yesterday. Apt/Up2date/Emerge/and whatever their names are.
It is also not about being cool, those are simple tasks that at least people who are willing to look into things can understand.
In simple words:
(Corporate) Administrators, who need to apply patches within days/hours should know what they are doing, so they can do it efficiently and fast without having to rely on external help. Home users can wait until patches and updates hit the official distribution channels for their distro.
If you maintain a Linux system for a larger group of people, you should know what you are doing. Pardon me, but obviously you're not. .config from 2.6.4, then answering a few questions for new options) brain involved: 1%, well documented in case of doubt. ../kernel....: 10 seconds, brain involved: 0%. :P
...
As soon as I read this I upgraded our Firewall at work. I downloaded the latest 2.6, got the patch from the bottom of the linuxreviews site. That took about 4 minutes on a somewhat fast internet connection.
Extracting the Kernel and patching it: 1 minute, brain involved: none (patch howto on that page as well, besides, if you are a real sysadmin you'll be able do kernel patches single fingered).
Configuring the kernel: 1 minute as well, using make oldconfig (porting over my
Compiling: make-kpkg kernel_image: 10 minutes, brain involved: 0%.
Installing: dpkg -i
Rebooting: about 1.5 minutes, brain involved: how fecking hard can it be to type 'shutdown -r now' ? or maybe even 'reboot'
This also answers the other posting where somebody was whining about making the updates moronproof... Most distros have this 'feature', autoupdating, Redhat: up2date, Debian: apt (through security.debian.org),