This was tested with the latest CVS version of Gimp at the time, which was after 1.2 was released. --
Why Photoshop still 0wnz Gimp
on
GIMP And OS X
·
· Score: 5
Gimp is quite impressive, but, aside from lack of color matching and color separation features, there's one big problem with using Gimp for professional non-web graphics.
Here's a way to see for yourself. Open Gimp and Photoshop on 2 boxes with identical hardware (Gimp in any OS it works on, Photoshop in NT or Win2k). Now open a 3000x3000 image in each program and observe the performance differences. Gimp's tile cache and memory management code just isn't optimized for large images, while Photoshop's is. Photoshop doesn't perform noticeably differently when editing a 300x300 image or a 3000x3000 image, while Gimp slowly cranks and grinds through the larger one (and a 3000x3000 image isn't exactly huge... think a 300dpi for-print image at 10"x10"). For reference, my box is a 350mhz P2, 384MB of RAM. Photoshop tested in Win2k Pro, Gimp in Linux 2.2.19 and 2.4.0-test5 (this was awhile ago:) and FreeBSD 4.2-RELEASE.
I heard a few months back that Gimp's tiling cache and memory management code were in line for a complete rewrite, but I don't know if this has happened yet. I haven't heard anything about it, so I'm going to assume that the situation is still the same. If anybody knows differently, please correct me.
Heh, while I'm on the subject... will somebody please write an Adobe Illustrator-type program for Linux that doesn't suck? Or at least make KIllustrator suck a bit less... --
The clipboard in Linux sucks incredibly. It is nice to be able to select and middle-click to paste when you're in a console, but doing something as simple as copying and pasting a URL into the browser is difficult.
I agree that the clipboard in Linux sucks incredibly, but this isn't why - in at least Netscape 4.x, Mozilla, and Konqueror, you can just middle-click on the HTML display area and it'll paste whatever's in your clipboard into the URL bar and go there.
Middle-click paste is one of the nicest things about X apps, IMHO. It's right up there with sloppy focus and virtual desktops (yeah, you can get the last 2 in Windows, but they always seem to have issues.) --
You're mostly right. The extra byte is often used for other things, like an 8-bit alpha channel, or four bits of alpha plus four bits of Z-buffer.
Really? That's interesting. Most of what I know about lowlevel graphics is from the 486-era, because that's when I was really into the whole thing. The only graphics coding I've done since then has been OpenGL stuff.
Makes me wonder, though. The de facto standard in the cinema world is 12 bits per pixel per channel-- 36 bit color. I wonder why no vendor has sold a PC-class product that does 36-bit color?
I thought that there are very high-end digital monitors and video cards for PC-class machines that could do this, but they're very expensive (quite obviously... this isn't the type of feature that the average computer user needs).
Cool trivia: the smallest pixels you can use on the Onyx2 IR2 system I have in my lab are 128 bits deep. That's 12 bits per channel RGBA, times two (double buffered) plus 32 bits of Z-buffer. Yowzers.
Holy hell. That's an interesting way of doing double buffering, though - is it really doing it the way you're implying, or like it was generally done in the 320x240x256 VGA programming days (i.e. one big contiguous block of memory represents the screen, and then a second contiguous big block of memory represents the offscreen buffer, and the display offset is just changed to flip)?
The method I think you're talking about gives me bad vibes of the 4-bit color days and bit planes. *shudder* --
These are the same Desktop developers that insist on using butt-ugly GTK Mandrake configuration tools with my sweet KDE environment.
No they aren't; I did some contracting work for MandrakeSoft, and I was asked to use GTK for the interface, because that's what everything else used. I would've preferred Qt, but hey, what can you do? I got the impression that these types of decisions aren't made at the developer level, they're made a bit higher up. --
This is just a question. But i thought apple users beeing the l33t computer graphics people that they are would require a monitor that can show 32bit color?
24-bit color is visually identical to 32-bit color; the extra byte is simply to speed up accesses by aligning pixels on 32-bit boundaries.
And monitors always display 24-bit color (at least monitors made in the last decade). The video card may store its pixel data in 8-bit or 16-bit format, but it sends full RGB data to the monitor. --
Dumbass! Sorenson != Apple. Sorenson is a codec made by an entirely different company that happens to be popular with Apple's (completely open, BTW) Quicktime format. Apple has no control over the openness of Sorenson's codec.
There are plenty of reasons to bash Apple (you can start with their patent fiascos), but Sorenson's proprietary video compression algorithm isn't one of them. --
The code is still copyrighted and still owned by the copyright owner, who is free to relicense the code however they wish (even to close the source... . but this doesn't retroactively affect code released previously under the GPL, which still stays free). The fact that they put the code under the GPL simply gives you the ability to use it under the GPL's terms, but doesn't give you ownership of the code.
And it's the GNU General Public License, not the GNU Public License. --
There's a difference between "bitching" and "constructive critisism." All I did was post a comment on the RAM usage of Slash, comparing it to a few other weblogs.
And to reply to the AC who replied to your comment, I don't make money off Smokedot. Do you see any ads? --
I never claimed it wasn't, and I didn't mean to knock everybody's hard work on it. It's a fine piece of software (although CmdrTaco's original version was... well... messy before Krow, et al, started work on it, and I certainly would have designed it a bit differently internally.)
It's not meant for smaller sites. It's meant to be on it's own server, taking millions of hits, and performing well under pressure.
Right - which is what I'm complaining about:) Since it's designed to handle large sites and doesn't perform well for smaller ones, why don't they make this fact known?
Now, if they made a stripped-down veresion of Slash, specifically catered to smaller weblogs, but with a compatible config format, so that when/if the weblog became popular, upgrading was fairly painless - that would be something =)
Yeah, that would be nice, actually. But changing weblogs isn't *that* difficult. It's just a matter of changing the templates for the new weblog to visually match (or at least come close) to the original and the writing a script which SELECTs the old values you want to save from the database and then INSERTs them into the new database. I already have the script written which will convert from Slash (0.9.3) to Scoop. --
Actually, I don't know. I didn't tune it for these tests - all the weblogs were pretty much at the stock install settings. Block caching was turned on though.
Were you using the beta software that's out, or are you speaking with the released 2.0 version?
The original tests were using the 1.0 release, the test of Bender used a recent beta, but not the release. --
I can't speak as to slashcode's memory usage, but this statement is lamentable. A server process can and should take up as much RAM as it possibly can, so long as it's also capable of releasing parts of that RAM that are going for 'gravy' functionality when other apps need said RAM for core functionality.
I agree; however, not everyone who would like to run a weblog can dedicate a server to it. Oftentimes Apache has to coexist with other services, and Slashcode just takes over the whole box (RAM-wise). Maybe this is good behavior for a large server, but IMHO not a small one.
On a semi-related note, you say that a server should be capable of releasing parts of its RAM to other programs... how is a program supposed to know that the RAM it's using is needed for another program? I'm not aware of any functionality in the C library for this type of thing, but I could be wrong. Anybody know? --
Sheesh, you don't remember when Rob was being called a child-molester every 15 minutes until he released the/. code?
Yes, I remember that. I'm not talking about him releasing it, but he acts as though it's the weblog to end all weblogs. If it doesn't perform well on smaller sites, it's not. And when somebody comments on the performance, he shouldn't make snappy comments about it not being designed for sites that get 7 hits a day. If this is the case, he should document this fact; it isn't mentioned at all on slashcode.com.
This 'community' gave him no end of shit for being a hipocrite [sp?] for running an (open source/free software/whatever)-centric site and not releasing the code that runs it.
No, this community didn't. The same people that bitch and moan about absolutely everything bitched and moaned about that as well.
Well they clearly say slash is designed for a million hits a day. Not really for use when co-hosted with other apps, It swallows all system resources, just like the best games, in order to give itself best advantage when the going gets tough.. Quite valid thing to do.
I suppose. But then why are they pushing it to anybody who needs a weblog? Performance for low- to medium-volume sites sucks pretty hard. It swallows all the RAM and then still performs worse than Scoop (and even Dope, which, when I ran the aforementioned tests, didn't use any caching whatsoever and wasn't even the least bit optimized). --
I've been running Slashcode on Smokedot for the last year, and I haven't exactly had the best experiences with it. First of all, it's running on a shared, freely hosted server, and Slash consistently uses too much RAM and CPU. I did some informal (very informal) tests on my local network, and here's how that went.
I installed Slash, Scoop, and Dope on virtual hosts on the same httpd. Then I'd stop and start httpd to get a clean server. Then I'd run a script which would request a few thousand pages very quickly and watch the free RAM level - I'd restart apache between tests so Slash wouldn't mess with Scoop's results, etc...
The box I used for testing was a 600mhz Alpha with 512MB of RAM. The MySQL server was on a different box so it wouldn't skew the results.
At the beginning of each test there was approximately 300MB free on the box. The Dope test reduced free RAM to about 220MB, Scoop reduced it to about 180MB, and Slash reduced it to about 4MB free (and I'm guessing it would have kept going if there was more RAM for it to play with). This is unacceptable, especially when you consider that Scoop was significanly faster than Slash in my testing. Slash does cache information as.shtml files, which speeds things up (I did the testing against index.pl and article.pl, obviously). But this is an annoying workaround, as the information you see is not necessarily up-to-date with what's in the database.
Speedwise, Scoop was about 20% faster than Slash, while Dope was about right in the middle.
This was a test with version 1.0 of Slashcode, and I recently ran he same tests with a recent beta of Bender. I was shocked - not only was it more RAM-hungry than older versions, but it was slower as well! This may be all well and good for a site with tons of resources, like Slashdot, but for smaller sites it's just not a good idea.
Dope is a work in development, by the way, and it was supposed to replace Slashcode for Smokedot. But since I'm basically just reimplementing Scoop anyway, I'm considering just using Scoop instead and scrapping Dope (hurstdog keeps bugging me to work on Scoop instead). --
How is the newbie firewall setup compared to the redhat 7.1 tool to setup simple firewalls?
Mandrake 8 ships with Bastille, a hardening and lockdown tool. It's a bit of a pain in the ass to set up, since you have to sit there and answer questions (some of them fairly complex) for half an hour.
However, I did some contract work for MandrakeSoft a few weeks back and wrote a few things which are included in Mandrake 8, one of which is a program called TinyFirewall - it's a program which creates a configuration file for Bastille with a few easy questions (but it obviously far less powerful than the full Bastille). It's meant simply to firewall a single machine rather than a network.
I also wrote a program (although I don't know what they're calling it in the release) which has the same basic idea (answer a few questions to configure Bastille) but rather than creating a small configuration file it chooses one from a bunch of premade config files (server paranoid, server moderate, server lax, workstation paranoid, workstation moderate, workstation lax). The premade configurations were made by Jay Beale, lead developer for Bastille.
I know that Mandrake's guys have hacked my code up quite a bit, so I make no guarantees about it anymore, but it worked when I gave it to them:) I believe (although I could be mistaken) that the configuration chooser script is run by Mandrake's installer now. --
That's one thing I don't get, in my ignorance: what proceeds do you get from a drug seizure? I presume they can't sell the drugs.
When they make a "drug" seizure, they're not necessarily taking drugs - they can seize your house, your car, all the money in your bank account, your children, your computers, and any of your other possessions if you are simply suspected of being a drug dealer. You never even have to be charged with a crime, but you'll never see any of your stuff again.
This can all happen as the result of an anonymous phone tip. Wonderful country we live in, eh? --
The War on Drugs in nonsense. In my opinion, it's causing more problems in this country than anything else right now - and it's causing a whole hell of a lot of problems. From corruption in government to the losses of individual Constitutional rights, everybody is getting screwed except for those making money from it (Government and large corporations).
And come on, Timothy, you need to read Smokedot more - we
ran this story on Wednesday:P --
I didn't read the article, but I'm guessing (based on the rest of the comments here) that this is an April fools' joke. Regardless, this isn't all that interesting - HTTP proxies can already proxy random TCP connections. I don't remember the exact protocol, but you connect to the proxy and send something like this:
CONNECT some.other.server:theport
... and then anything you send through that connection to the proxy will be sent to the other machine, and vice versa. It's kinda neat. I don't know if this is a standard thing, but at least Junkbuster and Squid support it. Helped me out a bit before I had set up NAT and only had one box connected to the internet on my local network - I hacked up BeAIM to go through junkbuster:) Worked great. On a related note, this is why open source software is good. Otherwise I wouldn't have been able to use an AIM client (some might argue that this is a good thing though...)
Anyway, I don't think it would take a lot of voodoo to get the kernel to handle this transparently. --
One concept I would love to see implemented is "watchdogs." This is the ability to specify a program which should be
run whenever a file or directory is accessed, opened for reads, opened for writes, written to, etc. Basically anything at
the VFS level.:-)
Yeah, BeOS has that - it lets them do some really neat stuff. Unfortunately I can't deal with BeOS on a day-to-day basis without going insane, so I'd love to see Linux or FreeBSD support this. --
Drug experiences may bring out
different emotions that may positively affect their artistic work, but I really don't believe anyone who says they can eat a mess of acid and suddenly the quality of
their code goes up and they can work out new alogrithms they couldn't figure out while straight.
Oh, absolutely you can. Acid (and other psychedelic drugs) don't decrease your ability to focus and think about something like alcohol does, they force you to think about it in much more detail and in an entirely different way and notice things that you never noticed before. Oftentimes this is exactly what you need to work out an algorithm that you're having a problem with or figure out a new way to code up something. --
Slashdot Mirror
This was tested with the latest CVS version of Gimp at the time, which was after 1.2 was released.
--
Gimp is quite impressive, but, aside from lack of color matching and color separation features, there's one big problem with using Gimp for professional non-web graphics.
:) and FreeBSD 4.2-RELEASE.
Here's a way to see for yourself. Open Gimp and Photoshop on 2 boxes with identical hardware (Gimp in any OS it works on, Photoshop in NT or Win2k). Now open a 3000x3000 image in each program and observe the performance differences. Gimp's tile cache and memory management code just isn't optimized for large images, while Photoshop's is. Photoshop doesn't perform noticeably differently when editing a 300x300 image or a 3000x3000 image, while Gimp slowly cranks and grinds through the larger one (and a 3000x3000 image isn't exactly huge... think a 300dpi for-print image at 10"x10"). For reference, my box is a 350mhz P2, 384MB of RAM. Photoshop tested in Win2k Pro, Gimp in Linux 2.2.19 and 2.4.0-test5 (this was awhile ago
I heard a few months back that Gimp's tiling cache and memory management code were in line for a complete rewrite, but I don't know if this has happened yet. I haven't heard anything about it, so I'm going to assume that the situation is still the same. If anybody knows differently, please correct me.
Heh, while I'm on the subject... will somebody please write an Adobe Illustrator-type program for Linux that doesn't suck? Or at least make KIllustrator suck a bit less...
--
The clipboard in Linux sucks incredibly. It is nice to be able to select and middle-click to paste when you're in a console, but doing something as simple as copying and pasting a URL into the browser is difficult.
I agree that the clipboard in Linux sucks incredibly, but this isn't why - in at least Netscape 4.x, Mozilla, and Konqueror, you can just middle-click on the HTML display area and it'll paste whatever's in your clipboard into the URL bar and go there.
Middle-click paste is one of the nicest things about X apps, IMHO. It's right up there with sloppy focus and virtual desktops (yeah, you can get the last 2 in Windows, but they always seem to have issues.)
--
You're mostly right. The extra byte is often used for other things, like an 8-bit alpha channel, or four bits of alpha plus four bits of Z-buffer.
Really? That's interesting. Most of what I know about lowlevel graphics is from the 486-era, because that's when I was really into the whole thing. The only graphics coding I've done since then has been OpenGL stuff.
Makes me wonder, though. The de facto standard in the cinema world is 12 bits per pixel per channel-- 36 bit color. I wonder why no vendor has sold a PC-class product that does 36-bit color?
I thought that there are very high-end digital monitors and video cards for PC-class machines that could do this, but they're very expensive (quite obviously... this isn't the type of feature that the average computer user needs).
Cool trivia: the smallest pixels you can use on the Onyx2 IR2 system I have in my lab are 128 bits deep. That's 12 bits per channel RGBA, times two (double buffered) plus 32 bits of Z-buffer. Yowzers.
Holy hell. That's an interesting way of doing double buffering, though - is it really doing it the way you're implying, or like it was generally done in the 320x240x256 VGA programming days (i.e. one big contiguous block of memory represents the screen, and then a second contiguous big block of memory represents the offscreen buffer, and the display offset is just changed to flip)?
The method I think you're talking about gives me bad vibes of the 4-bit color days and bit planes. *shudder*
--
These are the same Desktop developers that insist on using butt-ugly GTK Mandrake configuration tools with my sweet KDE environment.
No they aren't; I did some contracting work for MandrakeSoft, and I was asked to use GTK for the interface, because that's what everything else used. I would've preferred Qt, but hey, what can you do? I got the impression that these types of decisions aren't made at the developer level, they're made a bit higher up.
--
This is just a question. But i thought apple users beeing the l33t computer graphics people that they are would require a monitor that can show 32bit color?
24-bit color is visually identical to 32-bit color; the extra byte is simply to speed up accesses by aligning pixels on 32-bit boundaries.
And monitors always display 24-bit color (at least monitors made in the last decade). The video card may store its pixel data in 8-bit or 16-bit format, but it sends full RGB data to the monitor.
--
And it is just one word: Sorensen.
Dumbass! Sorenson != Apple. Sorenson is a codec made by an entirely different company that happens to be popular with Apple's (completely open, BTW) Quicktime format. Apple has no control over the openness of Sorenson's codec.
There are plenty of reasons to bash Apple (you can start with their patent fiascos), but Sorenson's proprietary video compression algorithm isn't one of them.
--
What part of Public don't you understand?
The code is still copyrighted and still owned by the copyright owner, who is free to relicense the code however they wish (even to close the source... . but this doesn't retroactively affect code released previously under the GPL, which still stays free). The fact that they put the code under the GPL simply gives you the ability to use it under the GPL's terms, but doesn't give you ownership of the code.
And it's the GNU General Public License, not the GNU Public License.
--
Stop bitching. If you don't like it don't use it.
There's a difference between "bitching" and "constructive critisism." All I did was post a comment on the RAM usage of Slash, comparing it to a few other weblogs.
And to reply to the AC who replied to your comment, I don't make money off Smokedot. Do you see any ads?
--
It's a damn good weblog, for high-traffic sites.
:) Since it's designed to handle large sites and doesn't perform well for smaller ones, why don't they make this fact known?
I never claimed it wasn't, and I didn't mean to knock everybody's hard work on it. It's a fine piece of software (although CmdrTaco's original version was... well... messy before Krow, et al, started work on it, and I certainly would have designed it a bit differently internally.)
It's not meant for smaller sites. It's meant to be on it's own server, taking millions of hits, and performing well under pressure.
Right - which is what I'm complaining about
Now, if they made a stripped-down veresion of Slash, specifically catered to smaller weblogs, but with a compatible config format, so that when/if the weblog became popular, upgrading was fairly painless - that would be something =)
Yeah, that would be nice, actually. But changing weblogs isn't *that* difficult. It's just a matter of changing the templates for the new weblog to visually match (or at least come close) to the original and the writing a script which SELECTs the old values you want to save from the database and then INSERTs them into the new database. I already have the script written which will convert from Slash (0.9.3) to Scoop.
--
What did you have blockcache set to?
Actually, I don't know. I didn't tune it for these tests - all the weblogs were pretty much at the stock install settings. Block caching was turned on though.
Were you using the beta software that's out, or are you speaking with the released 2.0 version?
The original tests were using the 1.0 release, the test of Bender used a recent beta, but not the release.
--
I can't speak as to slashcode's memory usage, but this statement is lamentable. A server process can and should take up as much RAM as it possibly can, so long as it's also capable of releasing parts of that RAM that are going for 'gravy' functionality when other apps need said RAM for core functionality.
I agree; however, not everyone who would like to run a weblog can dedicate a server to it. Oftentimes Apache has to coexist with other services, and Slashcode just takes over the whole box (RAM-wise). Maybe this is good behavior for a large server, but IMHO not a small one.
On a semi-related note, you say that a server should be capable of releasing parts of its RAM to other programs... how is a program supposed to know that the RAM it's using is needed for another program? I'm not aware of any functionality in the C library for this type of thing, but I could be wrong. Anybody know?
--
Sheesh, you don't remember when Rob was being called a child-molester every 15 minutes until he released the /. code?
Yes, I remember that. I'm not talking about him releasing it, but he acts as though it's the weblog to end all weblogs. If it doesn't perform well on smaller sites, it's not. And when somebody comments on the performance, he shouldn't make snappy comments about it not being designed for sites that get 7 hits a day. If this is the case, he should document this fact; it isn't mentioned at all on slashcode.com.
This 'community' gave him no end of shit for being a hipocrite [sp?] for running an (open source/free software/whatever)-centric site and not releasing the code that runs it.
No, this community didn't. The same people that bitch and moan about absolutely everything bitched and moaned about that as well.
--
Well they clearly say slash is designed for a million hits a day. Not really for use when co-hosted with other apps, It swallows all system resources, just like the best games, in order to give itself best advantage when the going gets tough.. Quite valid thing to do.
I suppose. But then why are they pushing it to anybody who needs a weblog? Performance for low- to medium-volume sites sucks pretty hard. It swallows all the RAM and then still performs worse than Scoop (and even Dope, which, when I ran the aforementioned tests, didn't use any caching whatsoever and wasn't even the least bit optimized).
--
Slash will do just fine on virtual hosts now thanks to clever work by Krow.
Erm. Slash has always worked just fine on virtual hosts. Well, maybe not _always_, but it certainly did with version 0.9.3.
--
I've been running Slashcode on Smokedot for the last year, and I haven't exactly had the best experiences with it. First of all, it's running on a shared, freely hosted server, and Slash consistently uses too much RAM and CPU. I did some informal (very informal) tests on my local network, and here's how that went.
.shtml files, which speeds things up (I did the testing against index.pl and article.pl, obviously). But this is an annoying workaround, as the information you see is not necessarily up-to-date with what's in the database.
I installed Slash, Scoop, and Dope on virtual hosts on the same httpd. Then I'd stop and start httpd to get a clean server. Then I'd run a script which would request a few thousand pages very quickly and watch the free RAM level - I'd restart apache between tests so Slash wouldn't mess with Scoop's results, etc...
The box I used for testing was a 600mhz Alpha with 512MB of RAM. The MySQL server was on a different box so it wouldn't skew the results.
At the beginning of each test there was approximately 300MB free on the box. The Dope test reduced free RAM to about 220MB, Scoop reduced it to about 180MB, and Slash reduced it to about 4MB free (and I'm guessing it would have kept going if there was more RAM for it to play with). This is unacceptable, especially when you consider that Scoop was significanly faster than Slash in my testing. Slash does cache information as
Speedwise, Scoop was about 20% faster than Slash, while Dope was about right in the middle.
This was a test with version 1.0 of Slashcode, and I recently ran he same tests with a recent beta of Bender. I was shocked - not only was it more RAM-hungry than older versions, but it was slower as well! This may be all well and good for a site with tons of resources, like Slashdot, but for smaller sites it's just not a good idea.
Dope is a work in development, by the way, and it was supposed to replace Slashcode for Smokedot. But since I'm basically just reimplementing Scoop anyway, I'm considering just using Scoop instead and scrapping Dope (hurstdog keeps bugging me to work on Scoop instead).
--
How is the newbie firewall setup compared to the redhat 7.1 tool to setup simple firewalls?
:) I believe (although I could be mistaken) that the configuration chooser script is run by Mandrake's installer now.
Mandrake 8 ships with Bastille, a hardening and lockdown tool. It's a bit of a pain in the ass to set up, since you have to sit there and answer questions (some of them fairly complex) for half an hour.
However, I did some contract work for MandrakeSoft a few weeks back and wrote a few things which are included in Mandrake 8, one of which is a program called TinyFirewall - it's a program which creates a configuration file for Bastille with a few easy questions (but it obviously far less powerful than the full Bastille). It's meant simply to firewall a single machine rather than a network.
I also wrote a program (although I don't know what they're calling it in the release) which has the same basic idea (answer a few questions to configure Bastille) but rather than creating a small configuration file it chooses one from a bunch of premade config files (server paranoid, server moderate, server lax, workstation paranoid, workstation moderate, workstation lax). The premade configurations were made by Jay Beale, lead developer for Bastille.
I know that Mandrake's guys have hacked my code up quite a bit, so I make no guarantees about it anymore, but it worked when I gave it to them
--
Man, they better not _touch_ my computers! :)
:P It just goes to show you that the War on Drugs isn't a war on drugs, it's a war on the American people. Enough is enough.
Yeah, no shit
--
Would you find this all that suprising if you found out that the post office is coordinating with the DEA to stop suspected drug shipments?
The post office has very stringent rules and regulations regarding packages it may inspect. Amtrak is not subject to these types of rules.
--
The color of someone's skin or sound of their accent must never constitute probable cause.
:) sources.
But they do. A few links to reduce your faith in our government:
New Jersey: "Yes, we racially profile"
USA: Race, Rights, and Police Brutality
These are both articles from Smokedot, but they link to external (i.e. reliable
--
That's one thing I don't get, in my ignorance: what proceeds do you get from a drug seizure? I presume they can't sell the drugs.
When they make a "drug" seizure, they're not necessarily taking drugs - they can seize your house, your car, all the money in your bank account, your children, your computers, and any of your other possessions if you are simply suspected of being a drug dealer. You never even have to be charged with a crime, but you'll never see any of your stuff again.
This can all happen as the result of an anonymous phone tip. Wonderful country we live in, eh?
--
The War on Drugs in nonsense. In my opinion, it's causing more problems in this country than anything else right now - and it's causing a whole hell of a lot of problems. From corruption in government to the losses of individual Constitutional rights, everybody is getting screwed except for those making money from it (Government and large corporations).
:P
And come on, Timothy, you need to read Smokedot more - we ran this story on Wednesday
--
I didn't read the article, but I'm guessing (based on the rest of the comments here) that this is an April fools' joke. Regardless, this isn't all that interesting - HTTP proxies can already proxy random TCP connections. I don't remember the exact protocol, but you connect to the proxy and send something like this:
... and then anything you send through that connection to the proxy will be sent to the other machine, and vice versa. It's kinda neat. I don't know if this is a standard thing, but at least Junkbuster and Squid support it. Helped me out a bit before I had set up NAT and only had one box connected to the internet on my local network - I hacked up BeAIM to go through junkbuster :) Worked great. On a related note, this is why open source software is good. Otherwise I wouldn't have been able to use an AIM client (some might argue that this is a good thing though...)
CONNECT some.other.server:theport
Anyway, I don't think it would take a lot of voodoo to get the kernel to handle this transparently.
--
One concept I would love to see implemented is "watchdogs." This is the ability to specify a program which should be run whenever a file or directory is accessed, opened for reads, opened for writes, written to, etc. Basically anything at the VFS level. :-)
Yeah, BeOS has that - it lets them do some really neat stuff. Unfortunately I can't deal with BeOS on a day-to-day basis without going insane, so I'd love to see Linux or FreeBSD support this.
--
Drug experiences may bring out different emotions that may positively affect their artistic work, but I really don't believe anyone who says they can eat a mess of acid and suddenly the quality of their code goes up and they can work out new alogrithms they couldn't figure out while straight.
Oh, absolutely you can. Acid (and other psychedelic drugs) don't decrease your ability to focus and think about something like alcohol does, they force you to think about it in much more detail and in an entirely different way and notice things that you never noticed before. Oftentimes this is exactly what you need to work out an algorithm that you're having a problem with or figure out a new way to code up something.
--