I haven't looked at the torrent site in question, but you can be sure that those 3 episodes of The OC are going to be the 3 that have aired in the US from the third series. You can't buy them. At least some of the demand will be from people that missed it on TV (but who probably would have watched it on TV - with advertisments - rather than take the trouble to download it) but also viewers from the rest of the world who can't (won't) wait until it's shown in their own countries.
OP was thinking of crystal meth not crack (which is trivially made from powdered cocaine I hear).
The best place for an explanation is probably under here. It's not that simple, but fairly. It's also dangerous. I understand that (pseudo)ephedrine as the most easily controlled precursor is very closely watched these days in the US.
$0.01 - The server browser is indeed a cringworthy embarrassment. How such a good game can have been released with such a appalling front-end is surely going to be an interesting gamasutra article
$0.02 - Engineers should not be penalised when their retarded teammates drive into their own minefields. I already vented about this here
For the MTV generation maybe, but I didn't see a great deal of depth there: filesystems? 3D support? network stack quality? hardware coverage? It looked a lot more like "I installed some CD and this is what happened" to me.
Not to mention that a review containing "Firefox 1.0.3 requires no introduction, however, a few notes on it are justified: fast & stable. I do not know what the yT guys and girls have done, but they made Firefox on BeOS stable and usable. And that's a great achievement." strikes me as a little suspect. Is Firefox not normally fast and stable, or is the reviewer really stuck for good things to say about Zeta?
You wouldn't lick your ass if you had worms would you?
I wouldn't do it - with or without worms!
Somebody has to quote the classics...
on
Vi IMproved -- Vim
·
· Score: 2, Funny
(Attribution at the bottom of the post)
When I log into my Xenix system with my 110 baud teletype, both vi *and* Emacs are just too damn slow. They print useless messages like, 'C-h for help' and '"foo" File is read only'. So I use the editor that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME ed - text editor
SYNOPSIS ed [ - ] [ -x ] [ name ] DESCRIPTION Ed is the standard text editor. -----
Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929/bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970/usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990/usr/bin/emacs
Of course, on the system *I* administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
--- Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
--
From: patl@athena.mit.edu (Patrick J. LoPresti)
Message-ID:
Sender: news@athena.mit.edu (News system)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Newsgroups: alt.religion.emacs,alt.slack
Organization: Massachusetts Institute of Technology
Lines: 95
Is it worth the trouble? It's worth the trouble for some users now yes. That's why it's done. Given a choice between rendering stuff slowly, or doing readback and rendering fast, people choose to render fast. It's a small investment for a big speed improvement.
As to the future, everybody can see the difference in bus speed vs. GPU performance. Shaders are going to open up a lot of possibilities in the next few years - for all parts of the pipeline.
But at the end of the day performance is what counts. Today we need to do readbacks, tomorrow hopefully not. The fact that we might not need to do them in the future doesn't mean that people shouldn't make the most of what we have at the moment. Nothing lasts forever, everything changes - and in computer graphics - especially fast.
You can also use it for lots of multipass effects - not least cutting down geometry for shadows.
With big scenes (as I mentioned in another post) the cost of attempting to render occluded geometry is far more costly than stalling the pipe for a few ms. Trying to render a few million polys can also kill your performance:-)
Oops, forgot to point out one more thing too: HP and NVidia have both implemented opengl extensions to address the issue of getting Z occlusion information back (nvidia's is layered on top of the HP extension iirc). This isn't useful for reading back the framebuffer fast, but helps when doing realtime occlusion culling.
That's what render-to-texture is for, you don't need to read data back to the CPU.
That is true for simple versions, but with methods moving towards image based rendering you often have to pull the data back anyway. Then you can process the textures to produce better imposters - not necessarily just billboards
Re: occlusion culling. People are using these methods today for realtime graphics (for example combinations of Greens HZB, or HOMs) even with the low readback speed. UNC's Gigawalk software is one published example (Google for it). Getting Z or alpha channel infomation back is the biggest hit, so these methods would be even more efficient and so more widley applicable with faster transfers. When you're rendering N million triangles per frame (UNC quote 82Million) you have to do this stuff to get realtime rendering.
So it is used for realtime graphics today - although mainly for heavy duty applications not games.
There are actually some good reasons to be able to do this apart from just taking screenshots. I did (sad but true) these tests over 4 years ago finishing grad school, and the results (read back speed is very bad) were much the same.
Two reasons for wanting to grab the framebuffer (or parts of it) are for
a) texture imposters (realtime adaptive billboarding) and b) split world/image-space occlusion culling.
With faster readback, both these techniques would probably be used more in "normal" software (ie games). 0.02
Of Perl: "It also powers Sweden's entire pension system [oreilly.com]"
Your fanaticism seems to be clouding your vision:-)
For the Swedish pension system, it is completely wrong to say that Perl powers the entire thing. If you had to choose only one thing, that would have to be Oracle. Slap bang, right in the middle, Oracle keeps the data. Most of the surrounding application is Perl - but not all of it - they also use JScript, VB and PL/SQL.
All this information is from the interesting link you posted. It's worth a read.
My 0.02 is that the parent post is 100% wrong. Nobody that has even looked at doing viz-sim work could take that comment seriously. SGI Performer - historically *the* high performance scenegraph to measure things against, is widely used, and it's widely used because it is so very *very* useful.
ATM SGI are porting Performer to windows (too little, too late perhaps), and there are a number of Open Source projects stepping up to fight it (personal recommendation www.openscenegraph.org);-)
The world is a big place, and there are a lot of people doing serious work that can't use OpenGL - it's far too low level for application writing these days if you want to concentrate on your app itself, and cant use a game engine because they're too expensive/too limited (typically the first problem is that they are often designed for static scene only, even if they support minor modifications with a penalty)/dont work on big iron/stereo/whatever.
The notion that scenegraphs are useless is the dumbest thing I've seen here for a while, now is the begining of the scenegraph era.
My IKEA desk is curently supporting two monitors, one of them is an old 24" weighing 50Kg. It (the desk) is solid as a rock.
How can this be? Simple - I live in Sweden. We keep all the good stuff and ship the rejects abroad:-)
Re:Everything you know is wrong
on
Review: U-571
·
· Score: 3, Informative
This is only half of the story. the Poles had the early machine broken, but when Enigma was upgraded in 1938 from 3 to 5 scramblers, and from 6 to 10 plugboard cables they could no longer break it (in any useful amount of time). Turing and the Bletchley Park group took up where the Poles left off. It's perhaps true that the Poles haven't gotten as much credit as they deserve, but it's also true that the Enigma that Rejewski broke wasn't the same Enigma that Bletchley Park broke - and the later was of far greater importance.
Slashdot Mirror
"Normal" adult voters watch violent movies. Only (non-voting) "kids" play computer games.
I haven't looked at the torrent site in question, but you can be sure that those 3 episodes of The OC are going to be the 3 that have aired in the US from the third series. You can't buy them. At least some of the demand will be from people that missed it on TV (but who probably would have watched it on TV - with advertisments - rather than take the trouble to download it) but also viewers from the rest of the world who can't (won't) wait until it's shown in their own countries.
That Nabaztag was going to turn out to be a synonym for Kancho? Poor bunny!
OP was thinking of crystal meth not crack (which is trivially made from powdered cocaine I hear).
The best place for an explanation is probably under here. It's not that simple, but fairly. It's also dangerous. I understand that (pseudo)ephedrine as the most easily controlled precursor is very closely watched these days in the US.
The logo these guys (still) have elektrostore.se
some debian-legal discussion
$0.01 - The server browser is indeed a cringworthy embarrassment. How such a good game can have been released with such a appalling front-end is surely going to be an interesting gamasutra article
$0.02 - Engineers should not be penalised when their retarded teammates drive into their own minefields. I already vented about this here
For the MTV generation maybe, but I didn't see a great deal of depth there: filesystems? 3D support? network stack quality? hardware coverage? It looked a lot more like "I installed some CD and this is what happened" to me.
Not to mention that a review containing "Firefox 1.0.3 requires no introduction, however, a few notes on it are justified: fast & stable. I do not know what the yT guys and girls have done, but they made Firefox on BeOS stable and usable. And that's a great achievement." strikes me as a little suspect. Is Firefox not normally fast and stable, or is the reviewer really stuck for good things to say about Zeta?
Beware the Ghost Of Usenet Postings Past
Good job editors!
I laughed when I saw the Intel Pocket Concert was on that list - I still use mine.
Outdated? Maybe, but still jsut as useful as ever.
http://news.bbc.co.uk/2/low/technology/2570731.stm
It's just acts of Parliament though, not all the data from the entire goverment.
I wouldn't do it - with or without worms!
(Attribution at the bottom of the post)
/bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
When I log into my Xenix system with my 110 baud teletype, both vi *and* Emacs are just too damn slow. They print useless messages like, 'C-h for help' and '"foo" File is read only'. So I use the editor that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME ed - text editor
SYNOPSIS ed [ - ] [ -x ] [ name ] DESCRIPTION Ed is the standard text editor. -----
Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929
Of course, on the system *I* administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ?
--- Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
--
From: patl@athena.mit.edu (Patrick J. LoPresti)
Message-ID:
Sender: news@athena.mit.edu (News system)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Newsgroups: alt.religion.emacs,alt.slack
Organization: Massachusetts Institute of Technology
Lines: 95
Is it worth the trouble? It's worth the trouble for some users now yes. That's why it's done. Given a choice between rendering stuff slowly, or doing readback and rendering fast, people choose to render fast. It's a small investment for a big speed improvement.
As to the future, everybody can see the difference in bus speed vs. GPU performance. Shaders are going to open up a lot of possibilities in the next few years - for all parts of the pipeline.
But at the end of the day performance is what counts. Today we need to do readbacks, tomorrow hopefully not. The fact that we might not need to do them in the future doesn't mean that people shouldn't make the most of what we have at the moment. Nothing lasts forever, everything changes - and in computer graphics - especially fast.
You can also use it for lots of multipass effects - not least cutting down geometry for shadows.
:-)
With big scenes (as I mentioned in another post) the cost of attempting to render occluded geometry is far more costly than stalling the pipe for a few ms. Trying to render a few million polys can also kill your performance
Oops, forgot to point out one more thing too: HP and NVidia have both implemented opengl extensions to address the issue of getting Z occlusion information back (nvidia's is layered on top of the HP extension iirc). This isn't useful for reading back the framebuffer fast, but helps when doing realtime occlusion culling.
That's what render-to-texture is for, you don't need to read data back to the CPU.
That is true for simple versions, but with methods moving towards image based rendering you often have to pull the data back anyway. Then you can process the textures to produce better imposters - not necessarily just billboards
Re: occlusion culling. People are using these methods today for realtime graphics (for example combinations of Greens HZB, or HOMs) even with the low readback speed. UNC's Gigawalk software is one published example (Google for it). Getting Z or alpha channel infomation back is the biggest hit, so these methods would be even more efficient and so more widley applicable with faster transfers. When you're rendering N million triangles per frame (UNC quote 82Million) you have to do this stuff to get realtime rendering.
So it is used for realtime graphics today - although mainly for heavy duty applications not games.
HTH
There are actually some good reasons to be able to do this apart from just taking screenshots. I did (sad but true) these tests over 4 years ago finishing grad school, and the results (read back speed is very bad) were much the same.
Two reasons for wanting to grab the framebuffer (or parts of it) are for
a) texture imposters (realtime adaptive billboarding) and
b) split world/image-space occlusion culling.
With faster readback, both these techniques would probably be used more in "normal" software (ie games).
0.02
Behold, the time has come for Dr Rat to lead the revolution.
(Dr Rat is a novel by William Kotzwinkle about a talking rat in a research lab. Well worth reading)
Of Perl: "It also powers Sweden's entire pension system [oreilly.com]"
:-)
Your fanaticism seems to be clouding your vision
For the Swedish pension system, it is completely wrong to say that Perl powers the entire thing. If you had to choose only one thing, that would have to be Oracle. Slap bang, right in the middle, Oracle keeps the data. Most of the surrounding application is Perl - but not all of it - they also use JScript, VB and PL/SQL.
All this information is from the interesting link you posted. It's worth a read.
Forbes gets their info from /.? I quote:
"(Full disclosure: VA Software owns OSDN, whose Slashdot Web site provides tech news to Forbes.com.)"
In the next issue, "Exploring hostile takeovers and hot grits"...
My 0.02 is that the parent post is 100% wrong. Nobody that has even looked at doing viz-sim work could take that comment seriously. SGI Performer - historically *the* high performance scenegraph to measure things against, is widely used, and it's widely used because it is so very *very* useful.
;-)
ATM SGI are porting Performer to windows (too little, too late perhaps), and there are a number of Open Source projects stepping up to fight it (personal recommendation www.openscenegraph.org)
The world is a big place, and there are a lot of people doing serious work that can't use OpenGL - it's far too low level for application writing these days if you want to concentrate on your app itself, and cant use a game engine because they're too expensive/too limited (typically the first problem is that they are often designed for static scene only, even if they support minor modifications with a penalty)/dont work on big iron/stereo/whatever.
The notion that scenegraphs are useless is the dumbest thing I've seen here for a while, now is the begining of the scenegraph era.
Stock Fraud
:-)
Glad to see the FBI is doing something useful
My IKEA desk is curently supporting two monitors, one of them is an old 24" weighing 50Kg. It (the desk) is solid as a rock.
:-)
How can this be? Simple - I live in Sweden. We keep all the good stuff and ship the rejects abroad
This is only half of the story. the Poles had the early machine broken, but when Enigma was upgraded in 1938 from 3 to 5 scramblers, and from 6 to 10 plugboard cables they could no longer break it (in any useful amount of time). Turing and the Bletchley Park group took up where the Poles left off. It's perhaps true that the Poles haven't gotten as much credit as they deserve, but it's also true that the Enigma that Rejewski broke wasn't the same Enigma that Bletchley Park broke - and the later was of far greater importance.