Now be careful, because inheritance was not really intended for code reuse. If it does help with code reuse, that's a positive consequence, but it's not what inheritance is for, first and foremost. See Liskov substitution principle and all that jazz.
The law of unintended consequences would strike, and there would be an under-the-table economy using the currency of another country, the latter only too willing to expand its economy on foreign soil. All the cash that anyone would be spending would go to that other country only to be converted into dollars. I'm sure there are some people already making bets on that happening, a bets they'd handsomely profit on. Nothing of substance would change: there would still be illegal immigration into the U.S., only that some extra part of it would be diverted from the local economy to the foreign soil. That is in addition to whatever immigrants, legal or not, are already sending back home (not that it's a bad thing, I merely acknowledge status quo).
Anecdote: I have a Volvo S40 '00. Time has come for new exhaust (from the manifold onwards) and new suspensions (front and back), because everything was original parts. Previous owner had an unfixed oil leak, so I replaced the coolant hoses that were starting to disintegrate due to being soaked in oil. Had the timing belt changed, fuel filter, other regular maintenance items, and all of the console lightbulbs (they were all burned out, every one of them!). But that car has got 400.000 km on it.
The radiator's side tanks blew out once because the coolant pressure is a "tad" high, as there's a small leak that gets the compressed gases from the cylinder into the coolant system. Apparently the leak is only big enough for the gases to pass through, and slowly at that -- I've attached a digital pressure logger to a cap I got from the junkyard, and it takes a good hour for the pressure to reach the asymptote. The coolant does not leak into the cylinders, merely leaks at the remaining factory original hose clamps. I have to finish changing those. The engine is otherwise fine, so I'm not bothering with a head job, as the situation has been stable for as long as I had the car.
Thankfully, contemporary cars -- I'd expect -- only use PWM signals to drive the blower and dispense with the archaic blower resistor idea. I mean, gimme a break, didn't we have transistors 30 years ago?!
I don't think it was a competent design, then. Even 10 years ago, a state-of-the-art dongle had non-imprinting memory for key storage, tamper detection, and was resilient against a whole lot of attacks (power line spikes, electrostatic and magnetic spikes, etc). These days a decent dongle is a single chip and two capacitors (one for decoupling, and a memory backing supercap), and there are four traces going to the USB chip, and there are a couple potted wires for tamper detect. The only way to look at it without it losing its data is using an X-ray.
You can't realistically break a good dongle, not using crude tools, anyway. The "dongle" can be broken, but you break the easy end of things: the software that depends on it. For that, you don't need any physical tools nor skills, just software tools.
If the video editing software would have a feature set comparable in scope and complexity to the cad software, then I'm sure it shouldn't be any cheaper. I wouldn't expect it to be, at least. Just to give you an idea: Final Cut Pro 7 is a toy in comparison.
Non-standard fonts are uploaded with the job. Many drivers upload all fonts anyway, and I'm fine with that. The applications that push too much of their own data structures through were written by people who didn't bother reading the green book (Postscript Lanugage Program Design). Ch. 5.3 is quite on topic, but the entire book is pretty much required reading if you want to generate PostScript within an application. Those applications do not represent what's wrong with Postscript, but merely what was wrong with the PS-spitting code.
In writing postscript output, you can use a very small subset of the language if you so desire. If all you have is a bitmap at printer's native resolution, it's quite trivial to wrap it in a postscript job. Unfortunately, postscript interpreters are quite a niche market and AFAIK there are no robust implementations out there, in the sense of full-coverage "almost-safety-rated" test suite -- contrast that with how well tested sqlite is, for example. That's why sometimes print drivers that use anything but the most trivial capabilities have to work around bugs in the postscript implementation in the printer...
It's very good that they will enforce use of avahi/Bonjour for discovery. CUPS by default does UDP broadcasts for discovery. That sucks if you have a subnet with many machines on it.
Postscript is proprietary but is well documented, so that's not an issue in practice.
As for the printer making choices, that's not informative because you've completely skipped the reality of it. Yes, the printer selects some defaults. Every print job has full control as to overriding the defaults, and any sane generic postscript print driver will not make its output dependent on the defaults -- precisely because, as you say, they may vary between printers. Heck, postscript guarantees that there is a set of standard fonts available, and those fonts have fixed metrics, so text rendered using those fonts will look almost exactly the same, and it will definitely have same spacing, kerning, etc. So, the details of a glyph's shape may be slightly different, but this will not affect the layout of the page.
As for print times, you're right of course, but that's not an issue in practice as well, since the drivers, if designed taking green book advice, are supposed not to do any computation in the printer, other than leveraging the always-present transformation matrix.
A generic postscript driver is entirely capable of producing documents that will look exactly the same on a wide array of printers, without taking into account much else besides the postscript level implemented by the printer -- and even that can be interrogated at runtime, selecting subparts of the job matching available postscript level.
In an engineering project of any decent magnitude, your choice is either paper printouts or dozens of monitors. Oh, and make sure you have a desk shaped like an annular segment so that those monitors can be within a reasonable distance from your head. Sorry, the paperless myth is just that. If it's an email that doesn't refer to much else, then two monitors are enough. If you need to cross-reference lots of information (in budgets, engineering, widely considered research activities), clicking between multiple windows is an annoyance and productivity killer.
There's a big difference between Postscript and PDF. Printable PDFs don't have any code that the printer will execute, they contain precalculated graphic primitives only. Postscript is a programming language. You can write a raytracer that runs on the printer in it, if you so desire.
+1 Informative. The patient was lucky to have lived through this. I love this tidbit:
His heart alternated between fibrillation and asystole for 15 minutes, during which time cardiac massage and internal defibrillation, while digitally plugging the holes maintained perfusion.
They used their fingers to plug two holes in the right ventricle, for several minutes. Those surgeons deserve a crate of beer.
If you seriously think that getting around dongle protection is "8 mins with a soldering iron", then you obviously have no clue about it, none at all. Dongles can be bypassed, but it usually involves some real reverse-engineering work, and to be efficient at that you need decent tools (say IDA and Decompiler from Hex-Rays).
You are living on some cloud nine. We have seats of parametric 3D cad software: about $4500 per seat, with a discount, too. Yearly maintenance is $1500 or so per seat. It works out because there's no one else who provides it any cheaper than that, and the file formats are completely proprietary and their binary structure is intentionally obfuscated. We attempted to move to a different system, by writing scripts for the source software to export all the data to a human-readable text file, and then writing other scripts for the target software to read it in. It turned out that the underlying representation of data in both pieces of software differed enough that we'd need to license a not-cheap 3D geometry engine just to massage the data. Overall cost of migration looked like it'd pay itself back in the per-seat difference savings over ~15 years. IOW: they know exactly what they are doing with their pricing. You'd need a 100 seats to have payback in a reasonable amount of time (3 years), and then you're still betting on other things (lack of new killer features on the more expensive end, etc).
Usually if the dongle dies/walks you can't even start the software up, never mind saving anything, so that's a silly objection. This doesn't mean that the saved data is lost, duh, and the saved data wouldn't be in any way linked to a particular license (it may have a license# embedded, but doesn't mean it's unreadable with a different license#).
The encryption won't get cracked, that'd be quite silly methinks. Whatever key is used on the application side will get replaced with a different one, and then you can encrypt whatever you want and send it to the application. Then you use a filter driver that pretends to be the USB device, and that's it. Of course the saving code would need to be captured, but all you need for that is one working system: capture it from the memory (say a VM snapshot), roll into the hack, end of story. The only thing is: how much work would it take, and if there's anyone out there who'd wish to implement it. Popularity is a losing proposition here: the more popular your software, the more likely it'd be to find an able and willing hacker. You can almost be sure that eventually one crucial order from somewhere in Asia will come, and the software/dongle combo will be used solely for reverse engineering.
I.e. if you affect the placement of files on the block device
Like, um, all defragmentation tools will do? If you're depending on a fixed location of a file on the block device on a Windows machine, you're stupid. That's it.
OpenGL? The heck? You need some sort of a scenegraph on top of that. In OpenGL if you want to draw a fine circle, you have to tesselate it yourself. I presume that has been done enough times by now and you'd be insane to suggest that the OP goes to do it yet once again.
But you have precisely skirted the issue. History is a collection of facts. Claiming that you can make predictions based on those facts requires something more than a mere assertion. Sciences in general collect facts and then make theories as explanation of facts. Those allow us to make predictions. Since history doesn't offer theories, your claim that one "simply learns from history" is a semicircular tautology: yeah, history is a bunch of facts, and like any bunch of facts, you can learn it. That still doesn't mean you can use those to predict anything -- IOW, it doesn't make you any more able to apply this knowledge in any way.
As soon as you claim that there are some ways of using "imagination and pattern recognition", you need to be very careful because, you know, those need to be reproducible in controlled conditions. I posit that historical facts are entirely useless as presented in usual study of history, because there are absolutely no sound methods given to use such facts, predictably and reliably, in any sort of forward-looking way. That's it.
History is an interesting art and I don't claim otherwise, but just like someone may dislike the art of painting and usually it doesn't get one looked down upon, same freedom of choice should apply to a dislike of history, without the silly implication that it makes you dumber somehow (it's implied all over the place in this and other threads). I also don't claim that facts that historians have collected cannot be used in some sort of reasoning, but that falls very short of the oft repeated claim that "those who don't learn from history are bound to repeat it". The latter claim is that you use historical facts to predict possible outcomes and to modify your behavior. For this claim to hold any water, I'd like to see some studies. Otherwise it's bullshit in the same category as homeopathy. I mean, if it's so obviously clear, then why can no one show, in a controlled fashion, that it is in fact so? Where is the damn catch?
It's not about what he could have done. You could have blown something up too, right? Malicious intent is a pretty well established legal concept I'd think. Either he did bugger something up or he didn't, it's not impossible to play safe, those systems are not from some intragalactic technology transfer. When you drive drunk, your abilities are compromised and that's like russian roulette. Accessing a 3rd party production server can't always be russian roulette because obviously the owners/operators manage to do it right somehow, and I can't generally imagine that they'd be making a shell access any more dangerous than it inherently is (don't rm -rf duh).
Seconded. I still deal with eZ8, a Harvard architecture platform that has 2kb of RAM and 16kb of code EEPROM on the particular chip I'm using. And then there's XMOS XS1 with 64kb of RAM that has to fit all the code and data for up to 8 threads of execution, running at an aggregate 500MIPS. Yet you can code some pretty amazing stuff on both.
Slashdot Mirror
Now be careful, because inheritance was not really intended for code reuse. If it does help with code reuse, that's a positive consequence, but it's not what inheritance is for, first and foremost. See Liskov substitution principle and all that jazz.
Thank you, one always learns something!
The law of unintended consequences would strike, and there would be an under-the-table economy using the currency of another country, the latter only too willing to expand its economy on foreign soil. All the cash that anyone would be spending would go to that other country only to be converted into dollars. I'm sure there are some people already making bets on that happening, a bets they'd handsomely profit on. Nothing of substance would change: there would still be illegal immigration into the U.S., only that some extra part of it would be diverted from the local economy to the foreign soil. That is in addition to whatever immigrants, legal or not, are already sending back home (not that it's a bad thing, I merely acknowledge status quo).
That's insane, but yeah, you're right...
Anecdote: I have a Volvo S40 '00. Time has come for new exhaust (from the manifold onwards) and new suspensions (front and back), because everything was original parts. Previous owner had an unfixed oil leak, so I replaced the coolant hoses that were starting to disintegrate due to being soaked in oil. Had the timing belt changed, fuel filter, other regular maintenance items, and all of the console lightbulbs (they were all burned out, every one of them!). But that car has got 400.000 km on it.
The radiator's side tanks blew out once because the coolant pressure is a "tad" high, as there's a small leak that gets the compressed gases from the cylinder into the coolant system. Apparently the leak is only big enough for the gases to pass through, and slowly at that -- I've attached a digital pressure logger to a cap I got from the junkyard, and it takes a good hour for the pressure to reach the asymptote. The coolant does not leak into the cylinders, merely leaks at the remaining factory original hose clamps. I have to finish changing those. The engine is otherwise fine, so I'm not bothering with a head job, as the situation has been stable for as long as I had the car.
Thankfully, contemporary cars -- I'd expect -- only use PWM signals to drive the blower and dispense with the archaic blower resistor idea. I mean, gimme a break, didn't we have transistors 30 years ago?!
I don't think it was a competent design, then. Even 10 years ago, a state-of-the-art dongle had non-imprinting memory for key storage, tamper detection, and was resilient against a whole lot of attacks (power line spikes, electrostatic and magnetic spikes, etc). These days a decent dongle is a single chip and two capacitors (one for decoupling, and a memory backing supercap), and there are four traces going to the USB chip, and there are a couple potted wires for tamper detect. The only way to look at it without it losing its data is using an X-ray.
You can't realistically break a good dongle, not using crude tools, anyway. The "dongle" can be broken, but you break the easy end of things: the software that depends on it. For that, you don't need any physical tools nor skills, just software tools.
If the video editing software would have a feature set comparable in scope and complexity to the cad software, then I'm sure it shouldn't be any cheaper. I wouldn't expect it to be, at least. Just to give you an idea: Final Cut Pro 7 is a toy in comparison.
Non-standard fonts are uploaded with the job. Many drivers upload all fonts anyway, and I'm fine with that. The applications that push too much of their own data structures through were written by people who didn't bother reading the green book (Postscript Lanugage Program Design). Ch. 5.3 is quite on topic, but the entire book is pretty much required reading if you want to generate PostScript within an application. Those applications do not represent what's wrong with Postscript, but merely what was wrong with the PS-spitting code.
They're magical, after all :)
In writing postscript output, you can use a very small subset of the language if you so desire. If all you have is a bitmap at printer's native resolution, it's quite trivial to wrap it in a postscript job. Unfortunately, postscript interpreters are quite a niche market and AFAIK there are no robust implementations out there, in the sense of full-coverage "almost-safety-rated" test suite -- contrast that with how well tested sqlite is, for example. That's why sometimes print drivers that use anything but the most trivial capabilities have to work around bugs in the postscript implementation in the printer...
It's very good that they will enforce use of avahi/Bonjour for discovery. CUPS by default does UDP broadcasts for discovery. That sucks if you have a subnet with many machines on it.
Postscript is proprietary but is well documented, so that's not an issue in practice.
As for the printer making choices, that's not informative because you've completely skipped the reality of it. Yes, the printer selects some defaults. Every print job has full control as to overriding the defaults, and any sane generic postscript print driver will not make its output dependent on the defaults -- precisely because, as you say, they may vary between printers. Heck, postscript guarantees that there is a set of standard fonts available, and those fonts have fixed metrics, so text rendered using those fonts will look almost exactly the same, and it will definitely have same spacing, kerning, etc. So, the details of a glyph's shape may be slightly different, but this will not affect the layout of the page.
As for print times, you're right of course, but that's not an issue in practice as well, since the drivers, if designed taking green book advice, are supposed not to do any computation in the printer, other than leveraging the always-present transformation matrix.
A generic postscript driver is entirely capable of producing documents that will look exactly the same on a wide array of printers, without taking into account much else besides the postscript level implemented by the printer -- and even that can be interrogated at runtime, selecting subparts of the job matching available postscript level.
In an engineering project of any decent magnitude, your choice is either paper printouts or dozens of monitors. Oh, and make sure you have a desk shaped like an annular segment so that those monitors can be within a reasonable distance from your head. Sorry, the paperless myth is just that. If it's an email that doesn't refer to much else, then two monitors are enough. If you need to cross-reference lots of information (in budgets, engineering, widely considered research activities), clicking between multiple windows is an annoyance and productivity killer.
There's a big difference between Postscript and PDF. Printable PDFs don't have any code that the printer will execute, they contain precalculated graphic primitives only. Postscript is a programming language. You can write a raytracer that runs on the printer in it, if you so desire.
+1 Informative. The patient was lucky to have lived through this. I love this tidbit:
His heart alternated between fibrillation and asystole for 15 minutes, during which time cardiac massage and internal defibrillation, while digitally plugging the holes maintained perfusion.
They used their fingers to plug two holes in the right ventricle, for several minutes. Those surgeons deserve a crate of beer.
If you seriously think that getting around dongle protection is "8 mins with a soldering iron", then you obviously have no clue about it, none at all. Dongles can be bypassed, but it usually involves some real reverse-engineering work, and to be efficient at that you need decent tools (say IDA and Decompiler from Hex-Rays).
You are living on some cloud nine. We have seats of parametric 3D cad software: about $4500 per seat, with a discount, too. Yearly maintenance is $1500 or so per seat. It works out because there's no one else who provides it any cheaper than that, and the file formats are completely proprietary and their binary structure is intentionally obfuscated. We attempted to move to a different system, by writing scripts for the source software to export all the data to a human-readable text file, and then writing other scripts for the target software to read it in. It turned out that the underlying representation of data in both pieces of software differed enough that we'd need to license a not-cheap 3D geometry engine just to massage the data. Overall cost of migration looked like it'd pay itself back in the per-seat difference savings over ~15 years. IOW: they know exactly what they are doing with their pricing. You'd need a 100 seats to have payback in a reasonable amount of time (3 years), and then you're still betting on other things (lack of new killer features on the more expensive end, etc).
Usually if the dongle dies/walks you can't even start the software up, never mind saving anything, so that's a silly objection. This doesn't mean that the saved data is lost, duh, and the saved data wouldn't be in any way linked to a particular license (it may have a license# embedded, but doesn't mean it's unreadable with a different license#).
The encryption won't get cracked, that'd be quite silly methinks. Whatever key is used on the application side will get replaced with a different one, and then you can encrypt whatever you want and send it to the application. Then you use a filter driver that pretends to be the USB device, and that's it. Of course the saving code would need to be captured, but all you need for that is one working system: capture it from the memory (say a VM snapshot), roll into the hack, end of story. The only thing is: how much work would it take, and if there's anyone out there who'd wish to implement it. Popularity is a losing proposition here: the more popular your software, the more likely it'd be to find an able and willing hacker. You can almost be sure that eventually one crucial order from somewhere in Asia will come, and the software/dongle combo will be used solely for reverse engineering.
I.e. if you affect the placement of files on the block device
Like, um, all defragmentation tools will do? If you're depending on a fixed location of a file on the block device on a Windows machine, you're stupid. That's it.
OpenGL? The heck? You need some sort of a scenegraph on top of that. In OpenGL if you want to draw a fine circle, you have to tesselate it yourself. I presume that has been done enough times by now and you'd be insane to suggest that the OP goes to do it yet once again.
But you have precisely skirted the issue. History is a collection of facts. Claiming that you can make predictions based on those facts requires something more than a mere assertion. Sciences in general collect facts and then make theories as explanation of facts. Those allow us to make predictions. Since history doesn't offer theories, your claim that one "simply learns from history" is a semicircular tautology: yeah, history is a bunch of facts, and like any bunch of facts, you can learn it. That still doesn't mean you can use those to predict anything -- IOW, it doesn't make you any more able to apply this knowledge in any way.
As soon as you claim that there are some ways of using "imagination and pattern recognition", you need to be very careful because, you know, those need to be reproducible in controlled conditions. I posit that historical facts are entirely useless as presented in usual study of history, because there are absolutely no sound methods given to use such facts, predictably and reliably, in any sort of forward-looking way. That's it.
History is an interesting art and I don't claim otherwise, but just like someone may dislike the art of painting and usually it doesn't get one looked down upon, same freedom of choice should apply to a dislike of history, without the silly implication that it makes you dumber somehow (it's implied all over the place in this and other threads). I also don't claim that facts that historians have collected cannot be used in some sort of reasoning, but that falls very short of the oft repeated claim that "those who don't learn from history are bound to repeat it". The latter claim is that you use historical facts to predict possible outcomes and to modify your behavior. For this claim to hold any water, I'd like to see some studies. Otherwise it's bullshit in the same category as homeopathy. I mean, if it's so obviously clear, then why can no one show, in a controlled fashion, that it is in fact so? Where is the damn catch?
It's not about what he could have done. You could have blown something up too, right? Malicious intent is a pretty well established legal concept I'd think. Either he did bugger something up or he didn't, it's not impossible to play safe, those systems are not from some intragalactic technology transfer. When you drive drunk, your abilities are compromised and that's like russian roulette. Accessing a 3rd party production server can't always be russian roulette because obviously the owners/operators manage to do it right somehow, and I can't generally imagine that they'd be making a shell access any more dangerous than it inherently is (don't rm -rf duh).
Seconded. I still deal with eZ8, a Harvard architecture platform that has 2kb of RAM and 16kb of code EEPROM on the particular chip I'm using. And then there's XMOS XS1 with 64kb of RAM that has to fit all the code and data for up to 8 threads of execution, running at an aggregate 500MIPS. Yet you can code some pretty amazing stuff on both.