Okay, this is way OT, but it might be useful to those who are sick of being redirected to a cache server against their will, particularly since Slashdot doesn't always seem to respond nicely to such things. Just download and install Internet Junkbuster and add the following two lines to the config file:
You'll still be redirected through the cache server; there's nothing you can do about that. But the cache server will never try to fill your requests, so you'll always get fresh data. Our ISP tried a cache server too; as far as I know they're still using it, but we finally got our range of IPs excluded. While they were still caching us, though, this approach worked.
Don't forget "creating hardware bugs we won't acknowledge and certainly won't fix, and then making them standard" Ever try to use a monochrome video card for debugging in a machine with an AGP video card?
fifteen seconds in the microwave, followed by an "accidental" encounter with one of those big magnets out of a hard drive.
Seriously, wonder what the penalty will be for an individual whose ID just suddenly "stops working" for no reason whatsoever. I've had the magstripes on credit cards give up on me, and I'm sure most of us have experienced the joy of static electricity. Can we expect even more overstressed travelers to snap when they're detained in Pittsburgh because their ID stopped working?
Go read the O'Reilly paper again before you resort to obscenities. Yes, you can get a server from a workstation by changing two keys, but doing so causes the system to set a number of other performance-related keys differently, as the original poster stated and the paper would confirm, if you actually bothered to read it.
(A final note before the exposition: the discussion and advocacy of open-source development in this paper should not be construed as a case that closed-source development is intrinsically wrong, nor as a brief against intellectual-property rights in software, nor as an altruistic appeal to `share'. While these arguments are still beloved of a vocal minority in the open-source development community, experience since [CatB] has made it clear that they are unnecessary. An entirely sufficient case for open-source development rests on its engineering and economic outcomes -- better quality, higher reliability, lower costs, and increased choice.)
I want to see some statistics that prove that people who agree with Stallman are only a minority of members of the open source community. Without that, this looks like just another attempt by our friend Eric to minimize the very real concerns many of us have about the real freedom of our software. Yeah, all that other stuff is nice, too, but three out of four (quality, reliability, and choice) are quite possible with proprietary software too. All you need are developers who care about the product and the customers rather than just the stock options.
The news article says only 97 characters remain uncracked, and the info on that website says the last 97 characters are encoded in what is suspected to be a one time pad (seems to me that that's just a way of saying "we can't figure out the algorithm here using just a frequency analysis so we'll call it random.") It looks as though one should concentrate on that part.
You seem to be confused about what DOM is. It has nothing to do with which tags do what, how the document is rendered, or how well CSS is supported. It is the framework by which you access the document contents from within scripts and applets. If you're only writing HTML, it doesn't affect you at all. It only affects you if you're doing scripting of some kind (and if you're really concerned about compatibility, you probably aren't.)
This explains why images[] works. It would appear that the way to find what you're looking for is document.body.getElementsByTagName("DIV").item(n) but that's just a guess.
I'm curious how it will avoid the insanely inefficient process start-up penalties one incurs under Microsoft, as well as how the non-shared data pages will be fast without being copy-on-write.
The FAQ says they will implement a parent and child process as multiple threads in the same process space rather than as multiple processes. No new processes means no process startup penalties. As for the nonshared data pages, NT supposedly supports copy-on-write via the VirtualProtect API function, so that aspect of the performance equation would likely only be a problem on Win9x.
As an aside - don't Microsoft claim that NT is POSIX compliant? If it is, then why do they have to make custom changes to things like Java and Perl?
NT has a POSIX-compliant subsystem. The Win32 subsystem is not POSIX-compliant. Programs executing in the POSIX subsystem have no easy way to communicate with programs running in the Win32 subsystem. The result is that hardly anyone does anything with the POSIX subsystem - why bother, when you can get the same results by just opening a telnet session to a real Unix box?
Odd, I seem to be running a Win32-aware Perl on this WinNT box already. I have a script over here that updates an MS Access database using the Win32::OLE module, and another one over there that can find and close a window by name using the Win32::API module. In fact, the Win32 subdirectory on this installation of Perl (not the ActiveState abortion, by the way, but a real honest-to-God Perl) contains 23 separate modules for everything from admin tasks to general UI tasks. If I wanted them, there are probably more Win32 modules on CPAN.
Here's what annoys me: The FAQ says
We are counting on the Perl Community, in particular those working on globalization issues, to work with us to create quality code that solves real problems.
So if they're counting on the Perl Community to do the work, what exactly is it that they're getting paid for again?
Oh, and of course none of the Win32-specific scripts will work on Unix. But then, none of your scripts that use fork or other various process- and user-management features will run on Win32, either (though one of the goals ActiveState has is to implement fork on the Win32 port.) I don't see how this is a problem.
I note that the essay doesn't address one of JWZ's excuses as to why there isn't more outside work being done: When you finally do figure out how to build all that code, what you get is... a bunch of test apps. Not even a complete browser. To quote JWZ: "What we released was a large pile of interesting code, but it didn't much resemble something you could actually use."
Another thing nobody's mentioned is the ridiculous amounts of memory it officially takes to build the thing. We starving programmers don't usually have 128M of RAM lying around in our home boxen. Until recently, in fact, I did all my non-work development on a 486 with 16M. I still only have a K6/233 with 96M of RAM. I'm sure there are lots of very good programmers in the same situation.
Slashdot Mirror
add-header Cache-Control: max-age=0
add-header Pragma: no-cache
You'll still be redirected through the cache server; there's nothing you can do about that. But the cache server will never try to fill your requests, so you'll always get fresh data. Our ISP tried a cache server too; as far as I know they're still using it, but we finally got our range of IPs excluded. While they were still caching us, though, this approach worked.
Don't forget "creating hardware bugs we won't acknowledge and certainly won't fix, and then making them standard" Ever try to use a monochrome video card for debugging in a machine with an AGP video card?
Seriously, wonder what the penalty will be for an individual whose ID just suddenly "stops working" for no reason whatsoever. I've had the magstripes on credit cards give up on me, and I'm sure most of us have experienced the joy of static electricity. Can we expect even more overstressed travelers to snap when they're detained in Pittsburgh because their ID stopped working?
This is way OT, but James Burke already writes a Connections column for Scientific American. Back issues and even the current issue are on the Web.
Go read the O'Reilly paper again before you resort to obscenities. Yes, you can get a server from a workstation by changing two keys, but doing so causes the system to set a number of other performance-related keys differently, as the original poster stated and the paper would confirm, if you actually bothered to read it.
I want to see some statistics that prove that people who agree with Stallman are only a minority of members of the open source community. Without that, this looks like just another attempt by our friend Eric to minimize the very real concerns many of us have about the real freedom of our software. Yeah, all that other stuff is nice, too, but three out of four (quality, reliability, and choice) are quite possible with proprietary software too. All you need are developers who care about the product and the customers rather than just the stock options.
The usual figure is ten percent of our brains, and it's total bunk.
The news article says only 97 characters remain uncracked, and the info on that website says the last 97 characters are encoded in what is suspected to be a one time pad (seems to me that that's just a way of saying "we can't figure out the algorithm here using just a frequency analysis so we'll call it random.") It looks as though one should concentrate on that part.
You seem to be confused about what DOM is. It has nothing to do with which tags do what, how the document is rendered, or how well CSS is supported. It is the framework by which you access the document contents from within scripts and applets. If you're only writing HTML, it doesn't affect you at all. It only affects you if you're doing scripting of some kind (and if you're really concerned about compatibility, you probably aren't.)
This explains why images[] works. It would appear that the way to find what you're looking for is document.body.getElementsByTagName("DIV").item(n) but that's just a guess.
Here's what annoys me: The FAQ says
So if they're counting on the Perl Community to do the work, what exactly is it that they're getting paid for again?Oh, and of course none of the Win32-specific scripts will work on Unix. But then, none of your scripts that use fork or other various process- and user-management features will run on Win32, either (though one of the goals ActiveState has is to implement fork on the Win32 port.) I don't see how this is a problem.
Maybe I'm just living in the stone age, but a year ago those specs were far beyond 90% of the machines at work, let alone my home machine.
Another thing nobody's mentioned is the ridiculous amounts of memory it officially takes to build the thing. We starving programmers don't usually have 128M of RAM lying around in our home boxen. Until recently, in fact, I did all my non-work development on a 486 with 16M. I still only have a K6/233 with 96M of RAM. I'm sure there are lots of very good programmers in the same situation.