Re:Oh, well, that explains everything...
on
C# In-Depth
·
· Score: 1
You needed to do that if you wanted to do anything fancy, like change colors, unless you could be sure that your programs' users were using ANSI.SYS or 'fansi console' or something similar.
ORLY? They didn't have a "uses bios;" option? I always used BIOS or ANSI.SYS. BIOS was kind of pokey but it was plenty good enough for putting up a banner.
Ironically, within a few years ANSI.SYS was faster than most of the programs that (originally) directly wrote to the video card. I assumed that the video cards or (even later) Windows were emulating the behavior of the original frame buffer, and ANSI.SYS bypassed that emulation.
Lisp is the best language to date, and it's been the best language since the '60s. I don't see why you'd invent a language that isn't derived from Lisp.
De gustibus non erat disputandum
on
C# In-Depth
·
· Score: 1
Im getting to dislike all those curly braces.
De gustibus non erat disputandum. A lot of people have big problems depending on indentation alone for nesting.
Re:Oh, well, that explains everything...
on
C# In-Depth
·
· Score: 2, Insightful
I was a 15-year old kid with a copy of Turbo Pascal. A very dangerous thing back then.
Aha! "Turbo Pascal, the PHP of the '80s."
Did you read what I wrote?
on
C# In-Depth
·
· Score: 1
Turbo Pascal might have been great for a DOS-only programmer, I don't know, I didn't use it because I needed to write software that would work on more than just DOS... that's not the point.
And, though this is not the point either, I would say the first IDE was Smalltalk, and Interlisp-D and UCSD Pascal both provided an IDE before Turbo.
The point is that the resulting program you got after you pressed that button was a badly behaved program. The end user doesn't give a damn whether you built the program by pushing a single button, or even if that button was pushed at the factory before you got it.
The end user had to deal with the fact that Turbo Pascal programs crashed on their computer because they didn't have one of the three video cards or two UARTs that Turbo's "too hell with MS-DOS and the BIOS, we're gong straight to the hardware" runtime knew about. The end user had to deal with the fact that when they ran a Turbo Pascal program, it clobbered their TSR text editor and wrote all over the other screen of DoubleDOS. The end user had to deal with the fact that Windows stuttered whenever they were running a Turbo program in a COMMAND window because they had to use a PIF that let the Turbo "I own the computer" program write straight to the hardware. Because whether or not Borland provided a way to build well behaved programs, no Turbo programmer in creation bothered to use it. Turbo was its own little world.
Oh, well, that explains everything...
on
C# In-Depth
·
· Score: 1
"Microsoft's leader of C# development, writer of the Turbo Pascal system, and lead architect on the Delphi language..."
Well, that explains everything. Turbo Pascal was the source of endless problems on the PC, and not just because it was really "Turbo Something Kind Of Like Pascal". It seemed like 90% of the time when I came across a badly behaved application that ignored command line redirects because it went straight to the BIOS just to write its copyright banner, and wouldn't run on anything but a perfect clone, or wouldn't run under DoubleDOS, or (later) required the most stringent DOS emulation under Windows, it was in Turbo Pascal.
Why anyone thought that was a good thing to happen by default, I don't know, but it drove me bonkers. No wonder C# and.NET is its own little universe that only deals with other software at the end of a ten foot pole.
Notes email client isn't even a *good* email client.
Notes is more like a browser for a weird mainframe version of the web, based on copying and synchronizing databases. It's like what you'd have gotten if OSI networking and IBM mainframes had been the basis of the world wide web.
Linden Labs has problems, yes, but they're almost the exact opposite of "they just know how to pump out marketing".
Both Google and LL are companies with a very rich engineering culture, where products and changes to products often happen out because they're cool. Linden Labs, if anything, could do with more marketing and more business culture... and they seem to know this. Google's business *is* marketing, their revenue seems to be almost entirely from advertising, and they do marketing very well. They don't do sustaining engineering so well... their APIs are frequently changed incompatibly and require people using them to rewrite their code to adjust... they could do with a bit more of LL's commitment to backwards compatibility in their APIs.
OK, you're talking about the SL server API being bad, not the LSL language being bad. Most people who rag on LSL just want to write C# instead of LSL. This is similar to the complaints people make about javascript... which would be quite a nice language, if the API exposed by the browser wasn't so funky and inconsistent.
The server API is restricted, there are serious shortcomings, but that's got nothing to do with LSL... and given the API that google has proposed for Lively (google gadgets running inside window frames on the wall) do you really think that they're going to provide a richer environment than SL?
Indeed. One of the curious things about Smalltalk is the lack of source code.
The other interactive languages I listed after Smalltalk don't have that problem, and neither does LSL, so while that's an interesting side issue about Smalltalk (and one that I have sympathy with) it's kind of irrelevant to the point I was making.
I could also add the UNIX command line versus Windows Scripting Host: the advantage of the interactive environment is not that it hides the source code.
"In-world creation of content" == "In world _ONLY_"
There doesn't seem to be a middle ground. It's either in-world and interactive, or (as in things like There and Activeworlds and... well, everything but SL) external and batch.
That's a big advantage SL has: an interactive environment is a much more productive one. It's like Smalltalk or Lisp or Forth or APL versus punched cards and COBOL, or Fortran. Or Enterprise Java Beans.
It's almost unheard of that a programming language comes along that some crazy person doesn't swear by and decide to write everything they do in it.
Tiny languages in real time control systems are often much more limited than LSL, and many of the limitations in LSL are typical of the real-time control environment. Trust me, even total maniacs don't expect to use these languages outside the real-time environment. One real time control language I implemented a compiler and interpreter for didn't even have loops, the only non-sequential control structure was retriggering events. I've dealt with real-time systems programmed using relay-ladder logic ONLY.
Google has _no_ content creation now? Is that really that much of a step down from what Second Life supports?
Yes, that's the point, isn't it. Most people's internet service is like renting an apartment, not owning a house. No control over access, visitors need to park down the block because you've only got one space, no privacy,...
Don't worry, when you're buying dedicated internet service with a fixed IP and guaranteed performance, you pay for traffic.
Not saying that that Lively won't be a advertising/hacking cluster fuck but at least it sounds it would be more open to programmers
Second Life: in-world creation of in-world content (no special tools needed for building and scripting), open source client, active cooperation with competing open source server platform, runs on Windows 2000, Mac, Linux, in-world scripting based on Mono,...
Lively: no user-created in-world content, in-world or out, just promises, no developer API, no information about an API, just 'you can put a non-interactive web page in a frame', only runs on Windows XP or better.
This is some version of "open" that only applies to Google.
Out of all the 3d user interfaces I've used, this is probably the worst. There's no connection between you and your avatar at all, and even getting your avatar to walk along a straight line is frustrating... the normal motion is to have you avatar teleport from one piece of furniture to another while you pan around at a distance.
If simple movement is so hard, how on earth do they expect people to use it for a gaming platform?
What I didn't know, though, is that a lot of nontechnical users are unknowingly using these privacy-protecting tools. Maybe they're being deployed as transparent proxies at large orgs or something
A lot of proxies drop referrers and user agents, yeh. There's proxies specifically for that.
But they can only do that for plain HTTP connections. They can't look inside HTTPS.
Unlike random session tokens, referrer-checking is an arms race that the other side can trivially win. The scraper writer just has to spend 2 minutes adding a pass-referrers feature to his program
Because it's virtually free to do and it DOES block some attempts. While it's possible some of them are scrupulous there's a LOT of traces in my logs from spidering software that is unimaginably sloppy. Basically, lots of them simply don't bother.. possibly because enough people figure that it's trivially defeated that they don't check referrers.
While I would say that there are very few games that have noticeable depth as literature, that doesn't mean that's inherent in the medium.
For that matter, very few movies have as much depth as novels, even novelizations of movies explore areas that the movie simply can't reach, and that doesn't mean movies aren't art. Not all games are "play balanced", and not all books are "Moby Dick".
And speaking of Moby Dick...
There are plenty of stories where the ending would be just as satisfying and meaningful if you got there by a different path, or even with a different character. Getting there can even give you an appreciation of the trials of the protagonist that you wouldn't gain if success or failure didn't depend on your decisions.
And play-balance doesn't mean giving Ahab a chance to live, there are plenty of games where it's impossible to "win" one side, and the "victory conditions" are based only on how well you lose. There are even games where the story is almost completely fixed, and all you can do is spend more or less time exploring the scenery.
Your 7600 did not use the affected solder/soldering method.
Good to know.
This defect affects primarily G84/G86 cards (mainly marketed as GeForce 8600). The G92-based 8800GT and 8800GTS 512 are not *supposed* to be affected, and the G80 based 8800GTX and 8800GTS 320/640 are believed unaffected as well.
So long as you don't pick up old stock that's currently sitting in warehouses, you should be fine then?
I would be happier if they'd publish SKUs of potentially defective cards.
Optional, perhaps, but in practice I've used it to discourage address scrapers for over 10 years and don't recall a single complaint from anyone about requiring a referrer. In practice it's almost always present.
And unreliable? How would it fail in a way that delivered the correct URL for a referrer check over an HTTPS connection? It won't be even seen by a proxy, let alone modified or removed.
The worst case is a false positive, and only if the end user has explicitly chosen to disable it.
Nvidia has already switched away from high-lead solder.
So, should I plan on buying a new card soon, when my solder snaps, or do I have a good one? How do I find out? Is this why my 7600 gave up the ghost so quickly? Have I already been a victim of this problem?
Slashdot Mirror
You needed to do that if you wanted to do anything fancy, like change colors, unless you could be sure that your programs' users were using ANSI.SYS or 'fansi console' or something similar.
ORLY? They didn't have a "uses bios;" option? I always used BIOS or ANSI.SYS. BIOS was kind of pokey but it was plenty good enough for putting up a banner.
Ironically, within a few years ANSI.SYS was faster than most of the programs that (originally) directly wrote to the video card. I assumed that the video cards or (even later) Windows were emulating the behavior of the original frame buffer, and ANSI.SYS bypassed that emulation.
Lisp is the best language to date, and it's been the best language since the '60s. I don't see why you'd invent a language that isn't derived from Lisp.
Im getting to dislike all those curly braces.
De gustibus non erat disputandum. A lot of people have big problems depending on indentation alone for nesting.
I was a 15-year old kid with a copy of Turbo Pascal. A very dangerous thing back then.
Aha! "Turbo Pascal, the PHP of the '80s."
Turbo Pascal might have been great for a DOS-only programmer, I don't know, I didn't use it because I needed to write software that would work on more than just DOS... that's not the point.
And, though this is not the point either, I would say the first IDE was Smalltalk, and Interlisp-D and UCSD Pascal both provided an IDE before Turbo.
The point is that the resulting program you got after you pressed that button was a badly behaved program. The end user doesn't give a damn whether you built the program by pushing a single button, or even if that button was pushed at the factory before you got it.
The end user had to deal with the fact that Turbo Pascal programs crashed on their computer because they didn't have one of the three video cards or two UARTs that Turbo's "too hell with MS-DOS and the BIOS, we're gong straight to the hardware" runtime knew about. The end user had to deal with the fact that when they ran a Turbo Pascal program, it clobbered their TSR text editor and wrote all over the other screen of DoubleDOS. The end user had to deal with the fact that Windows stuttered whenever they were running a Turbo program in a COMMAND window because they had to use a PIF that let the Turbo "I own the computer" program write straight to the hardware. Because whether or not Borland provided a way to build well behaved programs, no Turbo programmer in creation bothered to use it. Turbo was its own little world.
"Microsoft's leader of C# development, writer of the Turbo Pascal system, and lead architect on the Delphi language..."
Well, that explains everything. Turbo Pascal was the source of endless problems on the PC, and not just because it was really "Turbo Something Kind Of Like Pascal". It seemed like 90% of the time when I came across a badly behaved application that ignored command line redirects because it went straight to the BIOS just to write its copyright banner, and wouldn't run on anything but a perfect clone, or wouldn't run under DoubleDOS, or (later) required the most stringent DOS emulation under Windows, it was in Turbo Pascal.
Why anyone thought that was a good thing to happen by default, I don't know, but it drove me bonkers. No wonder C# and .NET is its own little universe that only deals with other software at the end of a ten foot pole.
Notes email client isn't even a *good* email client.
Notes is more like a browser for a weird mainframe version of the web, based on copying and synchronizing databases. It's like what you'd have gotten if OSI networking and IBM mainframes had been the basis of the world wide web.
LL just knows how to pump out marketing.
*boggle*
Linden Labs has problems, yes, but they're almost the exact opposite of "they just know how to pump out marketing".
Both Google and LL are companies with a very rich engineering culture, where products and changes to products often happen out because they're cool. Linden Labs, if anything, could do with more marketing and more business culture... and they seem to know this. Google's business *is* marketing, their revenue seems to be almost entirely from advertising, and they do marketing very well. They don't do sustaining engineering so well... their APIs are frequently changed incompatibly and require people using them to rewrite their code to adjust... they could do with a bit more of LL's commitment to backwards compatibility in their APIs.
OK, you're talking about the SL server API being bad, not the LSL language being bad. Most people who rag on LSL just want to write C# instead of LSL. This is similar to the complaints people make about javascript... which would be quite a nice language, if the API exposed by the browser wasn't so funky and inconsistent.
The server API is restricted, there are serious shortcomings, but that's got nothing to do with LSL... and given the API that google has proposed for Lively (google gadgets running inside window frames on the wall) do you really think that they're going to provide a richer environment than SL?
Indeed. One of the curious things about Smalltalk is the lack of source code.
The other interactive languages I listed after Smalltalk don't have that problem, and neither does LSL, so while that's an interesting side issue about Smalltalk (and one that I have sympathy with) it's kind of irrelevant to the point I was making.
I could also add the UNIX command line versus Windows Scripting Host: the advantage of the interactive environment is not that it hides the source code.
"In-world creation of content" == "In world _ONLY_"
There doesn't seem to be a middle ground. It's either in-world and interactive, or (as in things like There and Activeworlds and... well, everything but SL) external and batch.
That's a big advantage SL has: an interactive environment is a much more productive one. It's like Smalltalk or Lisp or Forth or APL versus punched cards and COBOL, or Fortran. Or Enterprise Java Beans.
It's almost unheard of that a programming language comes along that some crazy person doesn't swear by and decide to write everything they do in it.
Tiny languages in real time control systems are often much more limited than LSL, and many of the limitations in LSL are typical of the real-time control environment. Trust me, even total maniacs don't expect to use these languages outside the real-time environment. One real time control language I implemented a compiler and interpreter for didn't even have loops, the only non-sequential control structure was retriggering events. I've dealt with real-time systems programmed using relay-ladder logic ONLY.
Google has _no_ content creation now? Is that really that much of a step down from what Second Life supports?
Infinitely less.
I tried to find more about Gamebryo but when I got to Emergent.com it said:
Unless you live rent with included utilities...
Yes, that's the point, isn't it. Most people's internet service is like renting an apartment, not owning a house. No control over access, visitors need to park down the block because you've only got one space, no privacy, ...
Don't worry, when you're buying dedicated internet service with a fixed IP and guaranteed performance, you pay for traffic.
Seems to be a closed alpha test that only runs on Windows.
Just like Lively.
I am SO excited.
I'd like a second life where I could create a 50 megaton virtual H-bomb.
They had those in Second Life 3 years ago.
Not saying that that Lively won't be a advertising/hacking cluster fuck but at least it sounds it would be more open to programmers
Second Life: in-world creation of in-world content (no special tools needed for building and scripting), open source client, active cooperation with competing open source server platform, runs on Windows 2000, Mac, Linux, in-world scripting based on Mono, ...
Lively: no user-created in-world content, in-world or out, just promises, no developer API, no information about an API, just 'you can put a non-interactive web page in a frame', only runs on Windows XP or better.
This is some version of "open" that only applies to Google.
Out of all the 3d user interfaces I've used, this is probably the worst. There's no connection between you and your avatar at all, and even getting your avatar to walk along a straight line is frustrating... the normal motion is to have you avatar teleport from one piece of furniture to another while you pan around at a distance.
If simple movement is so hard, how on earth do they expect people to use it for a gaming platform?
What I didn't know, though, is that a lot of nontechnical users are unknowingly using these privacy-protecting tools. Maybe they're being deployed as transparent proxies at large orgs or something
A lot of proxies drop referrers and user agents, yeh. There's proxies specifically for that.
But they can only do that for plain HTTP connections. They can't look inside HTTPS.
Unlike random session tokens, referrer-checking is an arms race that the other side can trivially win. The scraper writer just has to spend 2 minutes adding a pass-referrers feature to his program
Because it's virtually free to do and it DOES block some attempts. While it's possible some of them are scrupulous there's a LOT of traces in my logs from spidering software that is unimaginably sloppy. Basically, lots of them simply don't bother.. possibly because enough people figure that it's trivially defeated that they don't check referrers.
After all, I don't have to outrun the bear.
The Computer is your Friend! If your security clearance is ultraviolet or greater, we can discuss play balance in Call of Cthulhu as well.
While I would say that there are very few games that have noticeable depth as literature, that doesn't mean that's inherent in the medium.
For that matter, very few movies have as much depth as novels, even novelizations of movies explore areas that the movie simply can't reach, and that doesn't mean movies aren't art. Not all games are "play balanced", and not all books are "Moby Dick".
And speaking of Moby Dick...
There are plenty of stories where the ending would be just as satisfying and meaningful if you got there by a different path, or even with a different character. Getting there can even give you an appreciation of the trials of the protagonist that you wouldn't gain if success or failure didn't depend on your decisions.
And play-balance doesn't mean giving Ahab a chance to live, there are plenty of games where it's impossible to "win" one side, and the "victory conditions" are based only on how well you lose. There are even games where the story is almost completely fixed, and all you can do is spend more or less time exploring the scenery.
Your 7600 did not use the affected solder/soldering method.
Good to know.
This defect affects primarily G84/G86 cards (mainly marketed as GeForce 8600). The G92-based 8800GT and 8800GTS 512 are not *supposed* to be affected, and the G80 based 8800GTX and 8800GTS 320/640 are believed unaffected as well.
So long as you don't pick up old stock that's currently sitting in warehouses, you should be fine then?
I would be happier if they'd publish SKUs of potentially defective cards.
Optional, perhaps, but in practice I've used it to discourage address scrapers for over 10 years and don't recall a single complaint from anyone about requiring a referrer. In practice it's almost always present.
And unreliable? How would it fail in a way that delivered the correct URL for a referrer check over an HTTPS connection? It won't be even seen by a proxy, let alone modified or removed.
The worst case is a false positive, and only if the end user has explicitly chosen to disable it.
Since the CSRF request will come with the referrer header set to the attacker's site, then validating the referrer should also counter this attack.
This is not the same as the the "same origin policy" in Appendix B of the paper.
Nvidia has already switched away from high-lead solder.
So, should I plan on buying a new card soon, when my solder snaps, or do I have a good one? How do I find out? Is this why my 7600 gave up the ghost so quickly? Have I already been a victim of this problem?