Does checking the 'Reiserfs' box count as a trick?;)
Seriously, though - Slackware has had native journaled filesystem support for quite awhile now. Makes me wonder why they make such a big deal about Red Hat 7.2's new ext3 support.
Oh yeah. I remember why. We all own their stock. Duh.
If I understand correctly (IIUC? Maybe I can start a new acronym trend here...) anything parallelizable must be custom-written with the Beowulf libraries in mind.
Nah. Check out MOSIX - it can migrate processes across nodes of a cluster automatically. Like on SMP, parallelism is just a fork() away.
Ya know, I thought this looked familiar. Like damn near a year old familiar. It wasn't a good idea- and barely newsworthy- then, and isn't any better now.
With stuff that isn't news (crap), and stuff that isn't news (old), I'd say today's a slow news day on slashdot. If there ever were a day that it wasn't, anyway.
And that cheap shot at minidiscs is just inexcusable.
I believe Zeus uses something similar to SGI's state threads, coupled with one heavyweight process per CPU. It's basically I/O multiplexing in multiple processes - a one to many process/connection relationship as opposed to a one-to-one relationship. The "threads" don't have any kernel entity associated with them, and aren't fully preemptive.
No, it's not. I have one sitting right here, and I can assure you the power supply is external. It's a gray, rounded box, with the trademark Apple rapid-machine-gun-fire(tm) design on the sides and top.
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea?
Gladly. And I don't even have to do it myself.
For starters, check out On u-Kernel Construction, a paper written by Jochen Liedke for the 15th ACM Symposium on Operating System Principles. It contains a thorough technical explanation of why Mach performs poorly, and provides corroborating evidence measured on multiple architectures.
Additionally, using Mach as a "hardware abstraction layer" for a userspace Unix server, rather than as a true microkernel, only compounds the kernel and related subsystems' poor performance.
So my question is should I submit hex data for the server to compute or int data?
Actually, if you compress it first with lzip, you'll generate a lot less network traffic, and thus less server load.
Sheesh... As more and more of these things get posted, I'm starting to gain an appreciation for the heaps of shit that the slashdot editors wade through.
...All your M$ are belong to us. ...For great justice.
Hey! Jamie!
1. Read the submission.
2. Follow the provided links. Read what those links point to. No links? Put it in the circular file. Or/dev/null. Or whatever you want to call it.
3. Read the submission again, checking for correct grammar and spelling. (Note that Commander "can't spell" Taco is not permitted to be in the room during this step).
4. If, after reading the submission, you don't wish you ended your life five minutes ago, then post.
That's all there is to it. I would have a real hard time bringing myself to post crap like this unless I had a 5% blood alcohol level and were in the middle of recieving oral sex. And I know nothing like that is going on in your geek compound.
Give both of our sets of eyes a rest. Don't post crap like this unless you plan to apologize profusely afterwards. God knows you'd demand an apology from Microsoft if they accused GPL projects of stealing code.
America Online also has plans to replace the position of administrators with automated inteligence bots that respond in a logical manor. These bots will be able to provide more "services" for the average user.
Although I'm sure automated bots indeed could provide better service than your average AOL administrator, this does appear to be an April Fool's joke.
And, it's quite possibly the first one of the day that hasn't been completely stupid.
Story Time. I was driving home from the university last week, and came across a similar "contract" while shooting down I-71 at around 85mph. This one was on the back of a large truck hauling rocks:
"Remain back 200 feet. We are not responsible for any resulting damage from falling rocks."
Give me a break - These are scare tactics. If a truck dumps a load of rocks on to you, you do have a claim against them. Same with AOL: prove malice, fraud, or negligence, and you could probably sue for more than termination of your account.
I'd pay a micro-payment to yank banner ads from websites I frequent.
The reaction to this statement has been interesting to say the least. Half of the posts I've seen today are responses like "Use junkbuster, stupid", or "Are you too lazy/stupid/ignorant to control what comes down your own connection (that you paid for)?"
Right now, most banners are controlled by some autonomous "advertising service", be it DoubleClick, AdFu (heh), or even some web hosting services (like Yahoo/GeoCities). They're easy to block: they all come from a specific domain; route *.doubleclick.net into oblivion and you're done. Ads have been "tacked on" to sites to increase (or produce) revenue, mainly because its easy for smaller sites to do this than to seek out ad content themselves. All a site owner has to do is sign on with an ad provider, and they're provided with a steady stream of advertisers that wouldn't possibly be interested in them alone.
What if ads were indistinguishable from the regular content, at least in terms of the HTTP semantics? What if slashdot just stuck those Lineo ads in some static content in the front page, pulling lineo.png out of the same directory as a slashdot.png or even that ugly Billy Gates image? Televisions don't change to the "advertising channel" at high noon when the network overlord declares it to be "ad time", why do most websites pull static images from addresses like http://ads.foo.com/annoy-user-with-ad.cgi ?
If ad content was blended seamlessly with a site, then the micropayments idea would make sense, at least to the content provider trying to make a living off of his/her website. The world would get the Slashdot with commercials every ten minutes, while the "subscribers" would see the feature-length HBO version. You're free to ignore the ads, and you're even free to set up a fancy perl script to filter them if you can.
It's the unpredictability of where ads occur that causes them to be viewed, right? I block web ads easily through squid, but I haven't rigged up a device to guess what time television commercials come on to filter those.
Battlefield Earth and the Mainstream Press Posted by JonKatz on 02:00 PM June 9th, 2000
Battlefield Earth is already an important movie, just by dint of its existence. It acknowledges, implicitly and explicitly, that movies are no longer simple forms of entertainment, but increasingly creative, complex -- even political -- expressions of the new culture forming online. It's the cinematic equivalent of the newsmagazine in the media world of yore - stylish, literate, interesting. The movie offers breaking profiles of game-like heroes and heroines in the form of cinematic essays. One recent screening featured hints of the sleazy days of gaming, and the controversial "tits-and-ass game" Panty Raider, as well as ruminations on the sometimes-addictive nature of creative movies. Such a movie, almost inconceivable even five years ago, now seems a benchmark of the way new media evolve to recognize and shape new culture. The mainstream press, as usual, gets left behind, clucking about the new world like Temperance Ladies outside a bar.
# We'll never let this happen again... rm./katz-article.pl
The DRI (Direct Rendering Infrastructure) is an add-on to the XFree86 X Server to allow direct writes to a 3D card's framebuffer memory, bypassing Xlib.
Direct3D is a proprietary API implemented on only the Windows platform. As it stands now, the Linux and X DRI will not run on Windows, and Direct3D will not run on Linux/Unix/X.
Slashdot Mirror
For the love of god. That's almost as bad as goatse.cx.
(begin evil voice)
RMS: "I've been working for GNOME since years before there was a GNOME. Mwhahahaha..."
(maniacal laughter, breathing fire)
Yeah. After reading his sound bite, I think you may have a point there.
Does checking the 'Reiserfs' box count as a trick? ;)
Seriously, though - Slackware has had native journaled filesystem support for quite awhile now. Makes me wonder why they make such a big deal about Red Hat 7.2's new ext3 support.
Oh yeah. I remember why. We all own their stock. Duh.
Nah. Real men can write assembly in *any* language. :)
The minutes of the IA-64 GCC summit are especially interesting and informative
Was that a subliminal message?
Great website.
A bunch of full-screen stock photography urging me to "take control of my digital universe".
Do they use Perl to generate this stuff?
If I understand correctly (IIUC? Maybe I can start a new acronym trend here...) anything parallelizable must be custom-written with the Beowulf libraries in mind.
Nah. Check out MOSIX - it can migrate processes across nodes of a cluster automatically. Like on SMP, parallelism is just a fork() away.
UNIX must be next. Slashdot said so.
Unless Slashdot's dying too. Then I may have to leave the basement. And that would suck.
Nope. The retail-boxed Pentium IIs came with an attached heatsink.
Ya know, I thought this looked familiar. Like damn near a year old familiar. It wasn't a good idea- and barely newsworthy- then, and isn't any better now.
With stuff that isn't news (crap), and stuff that isn't news (old), I'd say today's a slow news day on slashdot. If there ever were a day that it wasn't, anyway.
And that cheap shot at minidiscs is just inexcusable.
Nah. They just convert it to Mime-encoded text, then to PDF, and, finally, put a big black square over it.
Nitpick.
. html for more info.
I believe Zeus uses something similar to SGI's state threads, coupled with one heavyweight process per CPU. It's basically I/O multiplexing in multiple processes - a one to many process/connection relationship as opposed to a one-to-one relationship. The "threads" don't have any kernel entity associated with them, and aren't fully preemptive.
Check out http://oss.sgi.com/projects/state-threads/docs/st
Just make sure to send your changes back before consuming the sandwich, for the love of god. If you thought merging your code into CVS was messy...
No, it's not. I have one sitting right here, and I can assure you the power supply is external. It's a gray, rounded box, with the trademark Apple rapid-machine-gun-fire(tm) design on the sides and top.
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea?
Gladly. And I don't even have to do it myself.
For starters, check out On u-Kernel Construction, a paper written by Jochen Liedke for the 15th ACM Symposium on Operating System Principles. It contains a thorough technical explanation of why Mach performs poorly, and provides corroborating evidence measured on multiple architectures.
Additionally, using Mach as a "hardware abstraction layer" for a userspace Unix server, rather than as a true microkernel, only compounds the kernel and related subsystems' poor performance.
No... you're not the only one stabbing himself with a pencil. The upside is, with my recently-acquired brain damage, I can see squant.
43rd Law of Computing: Anything that can go wr
Sharks. With frickin' laser beams.
43rd Law of Computing: Anything that can go wr
So my question is should I submit hex data for the server to compute or int data?
Actually, if you compress it first with lzip, you'll generate a lot less network traffic, and thus less server load.
Sheesh... As more and more of these things get posted, I'm starting to gain an appreciation for the heaps of shit that the slashdot editors wade through.
43rd Law of Computing: Anything that can go wr
I'd go for a one-week orgy if there were no false positives. Given the circumstances, though, I'd probably just settle for two days worth.
43rd Law of Computing: Anything that can go wr
...All your M$ are belong to us.
...For great justice.
/dev/null. Or whatever you want to call it.
Hey! Jamie!
1. Read the submission.
2. Follow the provided links. Read what those links point to. No links? Put it in the circular file. Or
3. Read the submission again, checking for correct grammar and spelling. (Note that Commander "can't spell" Taco is not permitted to be in the room during this step).
4. If, after reading the submission, you don't wish you ended your life five minutes ago, then post.
That's all there is to it. I would have a real hard time bringing myself to post crap like this unless I had a 5% blood alcohol level and were in the middle of recieving oral sex. And I know nothing like that is going on in your geek compound.
Give both of our sets of eyes a rest. Don't post crap like this unless you plan to apologize profusely afterwards. God knows you'd demand an apology from Microsoft if they accused GPL projects of stealing code.
43rd Law of Computing: Anything that can go wr
America Online also has plans to replace the position of administrators with automated inteligence bots that respond in a logical manor. These bots will be able to provide more "services" for the average user.
Although I'm sure automated bots indeed could provide better service than your average AOL administrator, this does appear to be an April Fool's joke.
And, it's quite possibly the first one of the day that hasn't been completely stupid.
43rd Law of Computing: Anything that can go wr
Story Time. I was driving home from the university last week, and came across a similar "contract" while shooting down I-71 at around 85mph. This one was on the back of a large truck hauling rocks:
"Remain back 200 feet. We are not responsible for any resulting damage from falling rocks."
Give me a break - These are scare tactics. If a truck dumps a load of rocks on to you, you do have a claim against them. Same with AOL: prove malice, fraud, or negligence, and you could probably sue for more than termination of your account.
43rd Law of Computing: Anything that can go wr
I'd pay a micro-payment to yank banner ads from websites I frequent.
The reaction to this statement has been interesting to say the least. Half of the posts I've seen today are responses like "Use junkbuster, stupid", or "Are you too lazy/stupid/ignorant to control what comes down your own connection (that you paid for)?"
Right now, most banners are controlled by some autonomous "advertising service", be it DoubleClick, AdFu (heh), or even some web hosting services (like Yahoo/GeoCities). They're easy to block: they all come from a specific domain; route *.doubleclick.net into oblivion and you're done. Ads have been "tacked on" to sites to increase (or produce) revenue, mainly because its easy for smaller sites to do this than to seek out ad content themselves. All a site owner has to do is sign on with an ad provider, and they're provided with a steady stream of advertisers that wouldn't possibly be interested in them alone.
What if ads were indistinguishable from the regular content, at least in terms of the HTTP semantics? What if slashdot just stuck those Lineo ads in some static content in the front page, pulling lineo.png out of the same directory as a slashdot.png or even that ugly Billy Gates image? Televisions don't change to the "advertising channel" at high noon when the network overlord declares it to be "ad time", why do most websites pull static images from addresses like http://ads.foo.com/annoy-user-with-ad.cgi ?
If ad content was blended seamlessly with a site, then the micropayments idea would make sense, at least to the content provider trying to make a living off of his/her website. The world would get the Slashdot with commercials every ten minutes, while the "subscribers" would see the feature-length HBO version. You're free to ignore the ads, and you're even free to set up a fancy perl script to filter them if you can.
It's the unpredictability of where ads occur that causes them to be viewed, right? I block web ads easily through squid, but I haven't rigged up a device to guess what time television commercials come on to filter those.
43rd Law of Computing: Anything that can go wr
./katz-article.pl --topic='Battlefield Earth' --review=good --logic=off
./katz-article.pl
Battlefield Earth and the Mainstream Press
Posted by JonKatz on 02:00 PM June 9th, 2000
Battlefield Earth is already an important movie, just by dint of its existence. It acknowledges, implicitly and explicitly, that movies are no longer simple forms of entertainment, but increasingly creative, complex -- even political -- expressions of the new culture forming online. It's the cinematic equivalent of the newsmagazine in the media world of yore - stylish, literate, interesting. The movie offers breaking profiles of game-like heroes and heroines in the form of cinematic essays. One recent screening featured hints of the sleazy days of gaming, and the controversial "tits-and-ass game" Panty Raider, as well as ruminations on the sometimes-addictive nature of creative movies. Such a movie, almost inconceivable even five years ago, now seems a benchmark of the way new media evolve to recognize and shape new culture. The mainstream press, as usual, gets left behind, clucking about the new world like Temperance Ladies outside a bar.
# We'll never let this happen again...
rm
43rd Law of Computing: Anything that can go wr
"Well Kyle, No! No No! No!"
The DRI (Direct Rendering Infrastructure) is an add-on to the XFree86 X Server to allow direct writes to a 3D card's framebuffer memory, bypassing Xlib.
Direct3D is a proprietary API implemented on only the Windows platform. As it stands now, the Linux and X DRI will not run on Windows, and Direct3D will not run on Linux/Unix/X.
43rd Law of Computing: Anything that can go wr