This happened before with games and other software in the '80s They tried some seriously intrusive copy protection and found that it just angered their good customers and cut into sales, so now copy protection on games is pretty pedestrian and generally kept minimal.
Copy protection has been on the rise since around 1999-2000 or so. If you're referring to stuff like documentation checks, I think the only reason it hasn't come back into fashion is that paper manuals drive up the cost of producing the game package. Key discs, server-bound activation, and now bizarre bits like custom drivers and rootkits are turning up in game DRM; if and when publishers can count on TCPA support being available, such as on x86 Macs, I'd expect to start seeing DRM schemes that require them.
That trailing dot is significant, and is exactly what is needed to deal with phishy web sites in that context-- it indicates an absolute DNS name, much like a leading / indicates an absolute path name.
The DNS mess isn't as bad as it could be though:
With all the trouble people have gotten into with it, it's probably a good thing that DNS lacks an equivalent of '..' references.
At least the UK gave up their old convention of big-endian domain names. There's no convincing them to drive on the right though.
Perhaps the most interesting use of EICAR is to try to smuggle it past a scanner. For example, see if the scanner still finds it if you change its file extension or MIME type to plain text, if you wrap it up in a.zip,.rar,.tar,.gz,.bz2,.7z or.shar file possibly nested multiple levels, if you base64 or uuencode it, if you stick it inside an InstallShield or Wise installer package, if you apply an executable file compressor like lzexe or pklite to it, or other such chicanery.
Of course, we also indoctrinate our kids in America to wear clothes, not soley for warmth. We don't explain why, and I doubt most people could. For the most part, we just do it.
Well, as far as I know in most of the USA it's against the law not to wear clothes in public, and indoctrinating kids to obey laws makes a fair bit of sense to me.
Unfortunately, the password itself doesn't incriminate you, the content of your files does. If you don't cough the password up, you'll be held in contempt of court and locked up until the case ends, which if you're up on charges is... umm... probably as long as the sentence would have been in the first place. If the password itself consists of incriminating text, the court will apply immunity to that text only to bypass the Fifth. Either way you lose.
Okaaay, what we have here is either an impostor or a revenant. Personally I'm voting impostor since the poster misses the point altogether, and even the reanimated corpse of this brilliant fellow wouldn't misunderstand something this simple so fundamentally.
There is an EICAR-like test for spam already, the GTUBE. However, what the EICAR and GTUBE tests are intended to accomplish is to determine whether any given hunk of input is in fact being scanned for unwanted content (be it spam, malware, or what have you) or whether it has successfully been obfuscated to the point that the filter misses it altogether. It's not a suitable test for the effectiveness of a filter at catching the evolving stream of real-world spam or malware.
What is Acrylamide? It is just a chemical that food manufacturors put in French Fries and Chips.
Actually, toxic as it is, it's the natural result of high temperature cooking: amino acids and sugars will react. This process (the Maillard reaction) is relatively well understood. However, if asparagine is the input amino acid, when the resulting glycoside breaks down, acrylamide is left as one of the fragments. Of course, this doesn't change the fact that fried potatoes aren't the healthiest thing to eat...
OpenBSD is also code-reviewed from top to bottom on a regular basis. Nothing gets "thrown in". Linux achieves its stability largely by identification and removal of bugs once it's in the field, relying on a large base of early adopters more than it does code review.
Given ESR's musings on the cathedral and the bazaar, it seems to me one might view OpenBSD as a rather "bizarre" sort of cathedral, and Linux as a bazaar overrun by cults of personality. In Microsoft's world, on the other hand, you can't even get in to see the interior of the cathedral until the clergy grants you access.
You're a non-database person that doesn't understand the difference between a query and a compiled, cached stored procedure that lives right next to the DB engine itself.
So what's a prepared statement for then? For database engines that benefit from it, connectivity drivers will create temporary stored procedures behind prepared statements. Other databases, like MSSQL 2000, match the repeated, identical (except for argument values) SQL string against an in-memory cache of recent queries and re-use the prior query plan. Dynamic SQL may need recompilation whether it's generated at the client or the database. Either way, you get application queries at stored procedure speeds.
If you have processing to do that doesn't express well in DML but has to happen server-side for performace, you're probably not using SQL, you're using a scripting language with embedded SQL such as PL/SQL or Transact-SQL, or maybe Java on Oracle, C# on MSSQL 2005, or even a custom C library loaded in-process on the server. From one perspective it's a subroutine rather than a DML statement-- but invoking the stored procedure is still a query.
Again, I still contend that a competent database architect/developer/DBA will use database-specific stored procedures where performance is important.
The number of queries for which performance is even an issue is probably 5% or less of the total number of queries written. The bulk of queries I've seen are trivial DML anyway. Those few queries that are taking too long or soaking up more than their share of the server's resources are the only ones that should need to be tuned, and it's not that big a deal to migrate a few queries into stored procedures.
Granted, often the slow operations are indeed things that could benefit from specialized features, like Oracle's CONNECT BY clause or Microsoft's CONTAINS predicate. After all, it's less work than restructuring graph traversals and free text searches to work well on pure ANSI SQL after the application is already deployed.:-)
To me, and many others, buying a car for fuel economy is like buying a computer for low electrical consumption.
You hit the nail on the head with that. It's a smaller market, but you can't tell me that low electrical energy consumption doesn't matter to notebook or palmtop users desperate for battery life, or datacenters at the edge of their cooling capacity. You might say it's an environment of sorts driving that demand.
In my experience, even the dry-process Imagen printers were finicky. Last time I had to deal with one was in the mid-90's, and it was such a testy beast that the systems guys insisted that absolutely nobody was to touch it other than to pick up printouts from the output tray-- not even to refill the input paper trays.
Back in the mid 90's, I jumped onto the original FVWM as a sort of lightweight MWM clone with a pile of TWMish features. The default L&F at the time also, re-colored to bisque, seamlessly complemented tcl/tk applications like the newsreader I'd written. FVWM was as responsive as TWM as well, and that's on a crummy old Sparcstation 1.
The poor design decisions will be fixed and the JVM will be eliminated.
I doubt either of those things will actually happen. Most of the standard library is a creeping horror from a security and extensibility standpoint, but the fundamental design hasn't changed noticeably since 1.1-- they've just heaped another cargo ship full of additional cruft into the standard runtime with each major release. Stack-based security with principals attached is clumsy, but it appears to be getting treated as the state of the art by both the Java and.Net camps. They both need to be hit with a capability and design pattern cluestick. I'd say to hit them with a COM stick, but they'd probably use the painful parts like object registries and reference counting, and miss the important lesson: abandon globals and statics, interfaces and parameters are the key.
As for elimination of the JVM, it won't likely happen for a few reasons, most notably that even in a system which entirely precompiles to native code, the JVM is still the basis of the language's functionality specification. A C-like Java compiler can certainly produce correct code so long as the same program does the same thing as it would on a JVM. Also, dynamic loading in Java is specified in terms of JVM bytecode.
The result will be a fast compiled language with an elegant syntax.
LMAO! The syntax is about as elegant as C without a preprocessor. In such a fix, one becomes dependent on souped-up editors to churn out boilerplate code. Velocity works as a nice simple preprocessor; for more intricate macros JSE might be a better idea.
I don't think Java should try to morph into C or C++. In my opinion the JVM is the strongest link in the chain; in exchange for a hit in startup time you get the speed of a compiled language, the flexibility of a symbolic interpreter and the safety of fully checked memory access rolled into one. It's probably not the best thing to build grep or wc on, but it's great for bigger things like daemons and windowed apps.
Running out of pins is no excuse to cut the addressing registers short. Consider the hypothetical Proteon processor with only 24 address lines but 64-bit address registers; its successor the Deuteron exposes 32 of those lines, the Trition in a few years will expose 40, the Tetrion after that should easily do 48, and so on without breaking old code, unless someone was masochistic enough to write code that depends on address space wrapping around at the end of the decoded lines.
Java requires users to install a massive runtime evironment or SDK just to run Java applications. Trying to get this setup and working is annoying at best.
I can't argue much with that one. The standard library ballooned beyond belief and nearly beyond recognition in release 5. Sun's extension libraries (Activation Framework, Advanced Imaging, 3D, etc) are an even bigger pain in the installer because of restrictive licensing.
In a lot of areas Java is simply too object-oriented. Many of the APIs are annoying to use because of this.
I disagree. In a lot of areas Java suffers from excessively concrete standard libraries, stranding it uncomfortably between procedural and OO, and between process-based and capability-based authorization.
java.io.File, java.io.RandomAccessFile, RandomAccessFile, java.net.Socket, java.awt.Toolkit, and even java.lang.System all should have been pure interfaces; any functionality that can observe or touch the real world should not be available as a static member or concrete class. Pass an instance of System as an argument to main() from which I/O may then spring: what the capabilities crowd call the powerbox pattern.
The "safeness" of Java is an illusion that caught many people off guard. What they learned is that although it prevents a certain class of errors (memory leaks; memory smashing)...
Memory smash bugs tend to translate into gaping security holes, and they are regularly and frequently being found in all kinds of network-facing code. I, for one, welcome our new memory-smashless language overlords.;-)
As for memory leaks, when a garbage-collected program leaks memory it's typically due to references being kept alive that shouldn't be, which is arguably less common than failing to clean up on all code paths.
...if you program fails it still crashes.
What's a catch block for then? For some classes of faults there's nothing sensible to do except scream at the user and move on. Resource exhaustion errors are probably the worst to try to recover from, as you may not have the resources left over to properly recover.
Bad logic is bad logic no matter how "safe" the language is.
Agreed there; inadequate validation and/or containment of input is another common class of exploitable bugs.
I dunno about gold, but platinum is a notable catalyst, and the finer the bits of platinum are, the more efficiently it catalyzes due to its increased surface area.
Slagging the incumbent administration is fine, indeed, the American Way. Slagging the nation itself, on the other hand, is a sure way to draw hostility.
Slashdot Mirror
The DNS mess isn't as bad as it could be though:
Aha! So that is why they are modularizing IIS. Makes it easier to subtract value for lower price points.
Occasional sightings of Pisces swimeatus continue to this day.
And why do we have the law?
:-)
I purposely wasn't attempting to address that question.
Perhaps the most interesting use of EICAR is to try to smuggle it past a scanner. For example, see if the scanner still finds it if you change its file extension or MIME type to plain text, if you wrap it up in a .zip, .rar, .tar, .gz, .bz2, .7z or .shar file possibly nested multiple levels, if you base64 or uuencode it, if you stick it inside an InstallShield or Wise installer package, if you apply an executable file compressor like lzexe or pklite to it, or other such chicanery.
Unfortunately, the password itself doesn't incriminate you, the content of your files does. If you don't cough the password up, you'll be held in contempt of court and locked up until the case ends, which if you're up on charges is ... umm ... probably as long as the sentence would have been in the first place. If the password itself consists of incriminating text, the court will apply immunity to that text only to bypass the Fifth. Either way you lose.
Okaaay, what we have here is either an impostor or a revenant. Personally I'm voting impostor since the poster misses the point altogether, and even the reanimated corpse of this brilliant fellow wouldn't misunderstand something this simple so fundamentally.
There is an EICAR-like test for spam already, the GTUBE. However, what the EICAR and GTUBE tests are intended to accomplish is to determine whether any given hunk of input is in fact being scanned for unwanted content (be it spam, malware, or what have you) or whether it has successfully been obfuscated to the point that the filter misses it altogether. It's not a suitable test for the effectiveness of a filter at catching the evolving stream of real-world spam or malware.
OpenBSD is also code-reviewed from top to bottom on a regular basis. Nothing gets "thrown in". Linux achieves its stability largely by identification and removal of bugs once it's in the field, relying on a large base of early adopters more than it does code review.
:-)
Given ESR's musings on the cathedral and the bazaar, it seems to me one might view OpenBSD as a rather "bizarre" sort of cathedral, and Linux as a bazaar overrun by cults of personality. In Microsoft's world, on the other hand, you can't even get in to see the interior of the cathedral until the clergy grants you access.
Okay, have I stretched this metaphor too much?
You're a non-database person that doesn't understand the difference between a query and a compiled, cached stored procedure that lives right next to the DB engine itself.
:-)
So what's a prepared statement for then? For database engines that benefit from it, connectivity drivers will create temporary stored procedures behind prepared statements. Other databases, like MSSQL 2000, match the repeated, identical (except for argument values) SQL string against an in-memory cache of recent queries and re-use the prior query plan. Dynamic SQL may need recompilation whether it's generated at the client or the database. Either way, you get application queries at stored procedure speeds.
If you have processing to do that doesn't express well in DML but has to happen server-side for performace, you're probably not using SQL, you're using a scripting language with embedded SQL such as PL/SQL or Transact-SQL, or maybe Java on Oracle, C# on MSSQL 2005, or even a custom C library loaded in-process on the server. From one perspective it's a subroutine rather than a DML statement-- but invoking the stored procedure is still a query.
Again, I still contend that a competent database architect/developer/DBA will use database-specific stored procedures where performance is important.
The number of queries for which performance is even an issue is probably 5% or less of the total number of queries written. The bulk of queries I've seen are trivial DML anyway. Those few queries that are taking too long or soaking up more than their share of the server's resources are the only ones that should need to be tuned, and it's not that big a deal to migrate a few queries into stored procedures.
Granted, often the slow operations are indeed things that could benefit from specialized features, like Oracle's CONNECT BY clause or Microsoft's CONTAINS predicate. After all, it's less work than restructuring graph traversals and free text searches to work well on pure ANSI SQL after the application is already deployed.
To me, and many others, buying a car for fuel economy is like buying a computer for low electrical consumption.
You hit the nail on the head with that. It's a smaller market, but you can't tell me that low electrical energy consumption doesn't matter to notebook or palmtop users desperate for battery life, or datacenters at the edge of their cooling capacity. You might say it's an environment of sorts driving that demand.
In my experience, even the dry-process Imagen printers were finicky. Last time I had to deal with one was in the mid-90's, and it was such a testy beast that the systems guys insisted that absolutely nobody was to touch it other than to pick up printouts from the output tray-- not even to refill the input paper trays.
Back in the mid 90's, I jumped onto the original FVWM as a sort of lightweight MWM clone with a pile of TWMish features. The default L&F at the time also, re-colored to bisque, seamlessly complemented tcl/tk applications like the newsreader I'd written. FVWM was as responsive as TWM as well, and that's on a crummy old Sparcstation 1.
The poor design decisions will be fixed and the JVM will be eliminated.
.Net camps. They both need to be hit with a capability and design pattern cluestick. I'd say to hit them with a COM stick, but they'd probably use the painful parts like object registries and reference counting, and miss the important lesson: abandon globals and statics, interfaces and parameters are the key.
I doubt either of those things will actually happen. Most of the standard library is a creeping horror from a security and extensibility standpoint, but the fundamental design hasn't changed noticeably since 1.1-- they've just heaped another cargo ship full of additional cruft into the standard runtime with each major release. Stack-based security with principals attached is clumsy, but it appears to be getting treated as the state of the art by both the Java and
As for elimination of the JVM, it won't likely happen for a few reasons, most notably that even in a system which entirely precompiles to native code, the JVM is still the basis of the language's functionality specification. A C-like Java compiler can certainly produce correct code so long as the same program does the same thing as it would on a JVM. Also, dynamic loading in Java is specified in terms of JVM bytecode.
The result will be a fast compiled language with an elegant syntax.
LMAO! The syntax is about as elegant as C without a preprocessor. In such a fix, one becomes dependent on souped-up editors to churn out boilerplate code. Velocity works as a nice simple preprocessor; for more intricate macros JSE might be a better idea.
I don't think Java should try to morph into C or C++. In my opinion the JVM is the strongest link in the chain; in exchange for a hit in startup time you get the speed of a compiled language, the flexibility of a symbolic interpreter and the safety of fully checked memory access rolled into one. It's probably not the best thing to build grep or wc on, but it's great for bigger things like daemons and windowed apps.
does turning an ok short story into a crappy movie count as remixing?
I think it's more like severe dilution.
Running out of pins is no excuse to cut the addressing registers short. Consider the hypothetical Proteon processor with only 24 address lines but 64-bit address registers; its successor the Deuteron exposes 32 of those lines, the Trition in a few years will expose 40, the Tetrion after that should easily do 48, and so on without breaking old code, unless someone was masochistic enough to write code that depends on address space wrapping around at the end of the decoded lines.
java.io.File, java.io.RandomAccessFile, RandomAccessFile, java.net.Socket, java.awt.Toolkit, and even java.lang.System all should have been pure interfaces; any functionality that can observe or touch the real world should not be available as a static member or concrete class. Pass an instance of System as an argument to main() from which I/O may then spring: what the capabilities crowd call the powerbox pattern.
Memory smash bugs tend to translate into gaping security holes, and they are regularly and frequently being found in all kinds of network-facing code. I, for one, welcome our new memory-smashless language overlords.As for memory leaks, when a garbage-collected program leaks memory it's typically due to references being kept alive that shouldn't be, which is arguably less common than failing to clean up on all code paths.
What's a catch block for then? For some classes of faults there's nothing sensible to do except scream at the user and move on. Resource exhaustion errors are probably the worst to try to recover from, as you may not have the resources left over to properly recover. Agreed there; inadequate validation and/or containment of input is another common class of exploitable bugs.I dunno about gold, but platinum is a notable catalyst, and the finer the bits of platinum are, the more efficiently it catalyzes due to its increased surface area.
Slagging the incumbent administration is fine, indeed, the American Way. Slagging the nation itself, on the other hand, is a sure way to draw hostility.
Oops. He must be using a buggy Pentium.
This one is valid as-is in 8 languages.