Modern virtualization has not much in the way of time overhead due to execution of code. Its primary overheads come from cache and translation table purges as the contexts are switched.
So, if a microcontroller does it, it's OK, but if a PC does it, it's bad? Yeah, I know that bit-banging printer parallel ports is usually a bit retarded in light of there being really affordable digital I/O cards from multiple vendors, but still, if it works, it works. Alas, the fact that nowadays there's plenty of semi-professional CNC gear that's still bit-banged via the printer port, now that's disturbing in light of a PCI-DIO24 card costing only $99. There are also PCIe variants from multiple vendors.
I think that those big failures indicate something about human nature at a much lower level. The green screen (CICS and such) was something that every developer could reasonably comprehend in its entirety, and there weren't really a 100 ways to do anything and everything (AFAIK based on 2nd hand lore). It was "limited", but those limitations made it mesh with human limitations. Bazillions of CICS and architectural lookalike systems were successfully deployed, and are still in use and under maintenance.
Then we've got all the web technologies and suddenly you can do everything in an almost infinite number of ways, and the tech involved can be selected to be almost arbitrarily complex. All this while the people who actually design and implement the stuff haven't magically become any more intellectually-able. They are the same species; there's no particular pressure to select truly cream-of-the-crop uber-developers with extraordinary mental capabilities. This impedance mismatch between the breadth of technology and the limitations of the implementers is a surefire recipe for disaster, especially given the demonstrably natural tendency for PHBs to jump onto "new" technologies for no reason other than those technologies happen to be out there.
There is a reason why there are many very successful projects that run on "legacy" technologies and purposefully limit themselves to what they use in the implementation. Had they not done it, they'd not be successful, it's that simple. I agree with Joel Spolsky that such legacy implementation should never be scrapped by a "total rewrite". You've got something that's CICS but you want to move on - port it to something more modern, web2py for all I care, but do it by a series of easy to understand (perhaps automated, even) transformations. Only when that's done, and you've got exactly the same system on a platform you feel like using in the longer term, should you start adding new features and doing deeper architectural changes.
I've seen and played with a swedish accounting/payroll package that ran on Luxor's ABC 802 computers, with data stored in an ISAM database on a CatNet server (a niche swedish networking system). The entire package was written in BASIC and was reasonably nice in use, IIRC. Now this wasn't a port of the relatively poorly performing Microsoft BASIC. ABC 800 BASIC was an original design and performed well enough to implement such a system. I've seen it run in a small business with dozens of employees and millions of USD in revenue. It almost seems like today's IBM would throw a Java application server with a few gigs of heap at the problem, running on hardware that performs more than 3 orders of magnitude faster than the 1980's vintage solution did. It'd also cost 100x as much, and do nothing more than the original package.
I still have the server, a few ABC 802 machines, and the networking hardware. Heck, I might even have the image of the hard drive with all that data:)
Background: CatNet was a token ring system with intelligent network cards that had their own Z80 CPU and two of Zilog's communication controllers (one for upstream, one for downstream). The server had a CPU card with an HD64180 CPU (an enhanced Z80 with MMU), a network card, a SCSI card, and a SCSI hard drive and a tape drive for backups. There were at least two major versions of CatNet server hardware (I think called CatNet 1 and CatNet 2), I had both. The 1st version had two separate enclosures - one for the server, another for the tape drive. The 2nd version had one enclosure. It was a pretty nifty design. The intelligent network cards also came as an extension card for PCs. There was a compatible implementation of ABC BASIC that ran on PCs and offered the same interface to ISAM and networking as the ABC BASIC running on ABC computers did. That way they leveraged their investment in the software written in BASIC when as the PCs became popular. I do not remember how the development work on this whole thing was split between Luxor, Cat AB and what other third parties were involved, so if anyone who has worked on those systems reads this, no offense was meant. I don't know, for example, whether the ABC BASIC was a port from Luxor's sources (or assembly), or an original re-development by Cat AB, or even by some other third party.
For all I know I might be the last person on the planet to own this hardware, even though I have not played with it for about 15 years or so.
Ebonics is a niche language. I'd hardly call those who speak it uneducated: obviously they were educated by their peers and families in the use of this language. It's no different how any other local dialect is kept alive and well. I'm at a loss as to why anyone would think the flamebait racist generalizations you proffer are anything but your fantasy (albeit shared with other racist trolls out there).
Every time I'm at an airport, and see the backlit billboards pandering various IT and organizational consulting services, I think of the endless stream of waste of our, the taxpayer's, money those companies have caused, are causing, and will, very likely, continue to cause. Every time some smug suit talks about how great outsourcing is, and how their consultants are going to fix everything for everyone, I just chuckle. It's the stories like this that keep my chuckle going. IBM Australia, thank you very much for that. A smile supposedly makes you live longer. The way things are going, I'm immortal.
Setup a source code repository? I expect an ops guy to do that. That's a waste of an engineers time.
Never mind that if you're using a distributed versioning system, you don't even need one central repository, as long as your developers' machines are subject to backups.
Can't but agree. You'd have thought that intelligence work would require one to at least be aware of how to form a rational argument. This includes one's awareness of fallacies common in rhetorics... Well, maybe he thought an explicit use of a fallacy will somehow bolster his argument with the dumb populace. Who knows, maybe it even worked.
It doesn't assume that RAM is volatile, but isn't the fact that it is volatile PART of the reason "did you try turning it off and on again?" works so often?
Nope. The reason is that the CPU starts execution in a certain well defined state and at a certain physical address, where you better had some BIOS or monitor code to get you going. The memory contents are not assumed to be anything in particular and do not affect what a power cycle does.
The legacy PC BIOS, and presumably some other BIOSes, do place a magic word to in memory to differentiate between a cold and warm boot, but that's not that big of a deal if you had nonvolatile memory - remember, the whole thing would need to be designed to support it, BIOS included, so let's not be silly by pretending you take an off-the-shelf PC and just substitute the DIMMs with nonvolatile ones. It doesn't work that way, for crying out loud.
If a program/OS has a memory corruption issue, it seems like there are at least _some_ cases where it would be harder to temporarily work around the issue if the memory is permanent.
Given that every page that's not backed by a file is handed to the applications after being zeroes by the OS, and the OS itself obviously is supposed to initialize its own variables before use, I just don't see how this is of any concern to anyone. It's an imaginary problem.
Just so that you know, RAM contents do persist between power cycles in everyday hardware, including whatever you use to read this post. The RAM contents decay exponentially, with the exponent depending on temperature in such a way that lower temperature increases the half-life of memory contents. It doesn't affect anything, really, since a power cycle explicitly wipes all this memory. Of course if you're after cryptographic keys and such, the fact that main memory is nonvolatile does make a difference, but that's because most code that holds sensitive keys is not written to keep the keys solely in CPU caches.
The application code doesn't assume any such thing, because it's an assumption that is irrelevant to anything most application code could care about. It's the operating system that provides a certain execution environment that the applications are coded to. Just as an application programmer doesn't have to care (if they don't want to) about system going to sleep or being hibernated, you wouldn't care about the sleep or hibernation being implemented with nonvolatile main storage. The execution environment seen by the applications would be the same.
In every virtualized environment out there, the functionality of suspension and resumption of a VM's snapshot (including the implicit current state's snapshot) is equivalent to persistence across power cycles. Pray tell again, how is it a problem, because so far you're really insisting there is a problem, but you just won't share with anyone exactly how is it a problem. You're trying to make an argument, by all means, do make it, don't keep us guessing.
Code that's serious about security will keep at least the sensitive keys, if not the cleartext as well, only in the CPU's caches, and this requires some cooperation from the OS obviously, but it's not something that people usually bother to implement in spite of at least x86 and amd64 architectures letting you do so. The RAM gets entirely out of the picture if you assume that you're running on bare metal. In a virtual machine it might be much harder.
It's not just a serious risk, you can pretty much count on it. SD cards are not meant for permanent data storage when they are not powered. When powered, the built-in controller does patrol reads and reclaims pages that go weak before you lose any data. An unpowered SD card is really meant to be used to move data between things, not to store it for any prolonged periods of time. It's simply not designed for that.
Last I checked, pretty much no code assumes that RAM is volatile. Even the volatile keyword in C doesn't mean that if you store something there, it'll magically disappear, just that it may get modified by "other things" (other threads of execution, other processes, peripherals,...).
I think that you've made up an imaginary problem for yourself. Just think about it. When an operating system maps a fresh regular memory page for a process, it will be zeroed sometime before the process reads it. Or didn't you know that in C/C++, all non-automatic, non-heap variables are always initialized/default constructed, respectively? In C running on a modern OS it can get wasteful, since first the OS zeroes the pages, then usually the C runtime library zeroes them again.
The biggest benefits include immunity to power outages (with cooperation from the hypervisor layer) and ease of diagnostics on systems that "die" and are in need of such diagnosis (say a car ECU after a crash). Saturn V's engine controllers used non-volatile core memory and IIRC it came handy more than once.
not to mention getting your homonyms correct which I can usually do at speed if there are two isolated main forms to resolve, but not for palette/pallet/palate or muddles like Seine/sine/sign/sing/singe/singer/signer/seignior/Seigneur/senior/Seniour/senorita where finger habits start seeing double
That is very interesting - I never imagined that anyone who knows the spelling of those various homophonic forms would have any issues typing them correctly each and every time, save for random typos. People are complex beasts:)
What they do is they use a canned jbig2 image compression library, without much understanding. Very typical, after all the use of a library is supposed to not have you understand the tricky parts of image compression, right? Um, yeah, right.
This shouldn't be buried on page 107. It should be a warning on the first page. Heck, on top of the box the device is shipped in, for all I care. The scanned document should have that setting embedded as both metadata and a visible tag, so that it would be obvious on third generation documents (printouts from PDFs!) that the source could have had such errors. At least it's possible to decode jbig2 and visually mark all blocks on the page that have reference count larger than one. That way, if you still have the PDFs, you know what areas to audit. It's still a big snafu if you ask me.
Just in case people miss the obvious: The differing opening and closing quotes are the correct punctuation marks. It was only due to the typewriters and teletypes that the mangling into one quote has begun. The MS Office quotes are not "smart", they are merely correct.
Wait a minute, wouldn't it eventually piss you off too if you tried to correct obvious and trivial spelling or punctuation mistakes, doing your little contribution, only to be indirectly told "go fuck yourself"?!
Well, if you need to imagine such things, there's your problem right there. In other words: how do you propose those victims will be obtaining the information that 10 years after the fact people are still leering at the pictures? The fact that it's their own pictures doesn't make it any less illegal for them to access those pictures, mind you. I'd say that if a formerly abused child, now adult, would be considered a felon just for, say, checking if the pictures of him/herself are still out there - that's just one more argument for how broken such laws are. The law, as stated, will gladly re-victimize the victim again and again, just so that some lawmaker somewhere can feel good about themselves.
But the issue is that just because one is a well wisher who really, really wishes for "that market" to be "extinguished", it doesn't mean that one's well wishes are executable outside of some imaginary world, you know. Hell being paved with good intentions and all that. One's issue might be the presumed inability to differentiate between the market for pictures of some sort, vs. the production of such pictures. Only the second activity actually hurts the kids, one should recall.
All that I can think of at the moment is: Since trafficking in child pornography is mostly illegal, supposedly there are "hoops" to jump through if you want to be let into one of those trafficking rings. Those hoops can all be summarized as "provide original materials, and we'll guide you just to make sure you're not perusing some law enforcement image database". That's the very real unintended consequence of going hard on child pornography: you actually encourage more of it - presumably a LEO trying to break into one of those rings won't be abusing their own kid just to get in, right?
I think that the sad state of affairs is that there's lots of child pornography available out there, and people who are merely after that sort of material are harming nobody but themselves, in contrast to the people who produce such materials. Limiting access can often imply, the human being a resourceful creature, that they'll "make their own" - and now you've got actual kid abuse precipitated by laws to protect the kids. Sort of like 16 year olds getting jailed for distribution of child pornography when they sext their own nude pictures - how the fuck does it protect anyone, I just don't know. But everyone is a "think of the children" well-wisher, right? Yeah, right.
Slashdot Mirror
Modern virtualization has not much in the way of time overhead due to execution of code. Its primary overheads come from cache and translation table purges as the contexts are switched.
So, if a microcontroller does it, it's OK, but if a PC does it, it's bad? Yeah, I know that bit-banging printer parallel ports is usually a bit retarded in light of there being really affordable digital I/O cards from multiple vendors, but still, if it works, it works. Alas, the fact that nowadays there's plenty of semi-professional CNC gear that's still bit-banged via the printer port, now that's disturbing in light of a PCI-DIO24 card costing only $99. There are also PCIe variants from multiple vendors.
RabidReindeer and nwf, thank you. No fizzy drinks nor keyboards were harmed while reading those posts. Only barely so.
I think that those big failures indicate something about human nature at a much lower level. The green screen (CICS and such) was something that every developer could reasonably comprehend in its entirety, and there weren't really a 100 ways to do anything and everything (AFAIK based on 2nd hand lore). It was "limited", but those limitations made it mesh with human limitations. Bazillions of CICS and architectural lookalike systems were successfully deployed, and are still in use and under maintenance.
Then we've got all the web technologies and suddenly you can do everything in an almost infinite number of ways, and the tech involved can be selected to be almost arbitrarily complex. All this while the people who actually design and implement the stuff haven't magically become any more intellectually-able. They are the same species; there's no particular pressure to select truly cream-of-the-crop uber-developers with extraordinary mental capabilities. This impedance mismatch between the breadth of technology and the limitations of the implementers is a surefire recipe for disaster, especially given the demonstrably natural tendency for PHBs to jump onto "new" technologies for no reason other than those technologies happen to be out there.
There is a reason why there are many very successful projects that run on "legacy" technologies and purposefully limit themselves to what they use in the implementation. Had they not done it, they'd not be successful, it's that simple. I agree with Joel Spolsky that such legacy implementation should never be scrapped by a "total rewrite". You've got something that's CICS but you want to move on - port it to something more modern, web2py for all I care, but do it by a series of easy to understand (perhaps automated, even) transformations. Only when that's done, and you've got exactly the same system on a platform you feel like using in the longer term, should you start adding new features and doing deeper architectural changes.
I've seen and played with a swedish accounting/payroll package that ran on Luxor's ABC 802 computers, with data stored in an ISAM database on a CatNet server (a niche swedish networking system). The entire package was written in BASIC and was reasonably nice in use, IIRC. Now this wasn't a port of the relatively poorly performing Microsoft BASIC. ABC 800 BASIC was an original design and performed well enough to implement such a system. I've seen it run in a small business with dozens of employees and millions of USD in revenue. It almost seems like today's IBM would throw a Java application server with a few gigs of heap at the problem, running on hardware that performs more than 3 orders of magnitude faster than the 1980's vintage solution did. It'd also cost 100x as much, and do nothing more than the original package.
I still have the server, a few ABC 802 machines, and the networking hardware. Heck, I might even have the image of the hard drive with all that data :)
Background: CatNet was a token ring system with intelligent network cards that had their own Z80 CPU and two of Zilog's communication controllers (one for upstream, one for downstream). The server had a CPU card with an HD64180 CPU (an enhanced Z80 with MMU), a network card, a SCSI card, and a SCSI hard drive and a tape drive for backups. There were at least two major versions of CatNet server hardware (I think called CatNet 1 and CatNet 2), I had both. The 1st version had two separate enclosures - one for the server, another for the tape drive. The 2nd version had one enclosure. It was a pretty nifty design. The intelligent network cards also came as an extension card for PCs. There was a compatible implementation of ABC BASIC that ran on PCs and offered the same interface to ISAM and networking as the ABC BASIC running on ABC computers did. That way they leveraged their investment in the software written in BASIC when as the PCs became popular. I do not remember how the development work on this whole thing was split between Luxor, Cat AB and what other third parties were involved, so if anyone who has worked on those systems reads this, no offense was meant. I don't know, for example, whether the ABC BASIC was a port from Luxor's sources (or assembly), or an original re-development by Cat AB, or even by some other third party.
For all I know I might be the last person on the planet to own this hardware, even though I have not played with it for about 15 years or so.
And the man-month. The mythical man-month. Let's not forget the man-month. Have I mentioned the man-month yet? :)
Ebonics is a niche language. I'd hardly call those who speak it uneducated: obviously they were educated by their peers and families in the use of this language. It's no different how any other local dialect is kept alive and well. I'm at a loss as to why anyone would think the flamebait racist generalizations you proffer are anything but your fantasy (albeit shared with other racist trolls out there).
Every time I'm at an airport, and see the backlit billboards pandering various IT and organizational consulting services, I think of the endless stream of waste of our, the taxpayer's, money those companies have caused, are causing, and will, very likely, continue to cause. Every time some smug suit talks about how great outsourcing is, and how their consultants are going to fix everything for everyone, I just chuckle. It's the stories like this that keep my chuckle going. IBM Australia, thank you very much for that. A smile supposedly makes you live longer. The way things are going, I'm immortal.
Setup a source code repository? I expect an ops guy to do that. That's a waste of an engineers time.
Never mind that if you're using a distributed versioning system, you don't even need one central repository, as long as your developers' machines are subject to backups.
Presumably if it's not self-modifying code, you can just statically translate it to x86 or whatever on loading and be done.
Well, YES! I wish a journalist would use that line in a press conference with that guy.
Can't but agree. You'd have thought that intelligence work would require one to at least be aware of how to form a rational argument. This includes one's awareness of fallacies common in rhetorics... Well, maybe he thought an explicit use of a fallacy will somehow bolster his argument with the dumb populace. Who knows, maybe it even worked.
It doesn't assume that RAM is volatile, but isn't the fact that it is volatile PART of the reason "did you try turning it off and on again?" works so often?
Nope. The reason is that the CPU starts execution in a certain well defined state and at a certain physical address, where you better had some BIOS or monitor code to get you going. The memory contents are not assumed to be anything in particular and do not affect what a power cycle does.
The legacy PC BIOS, and presumably some other BIOSes, do place a magic word to in memory to differentiate between a cold and warm boot, but that's not that big of a deal if you had nonvolatile memory - remember, the whole thing would need to be designed to support it, BIOS included, so let's not be silly by pretending you take an off-the-shelf PC and just substitute the DIMMs with nonvolatile ones. It doesn't work that way, for crying out loud.
If a program/OS has a memory corruption issue, it seems like there are at least _some_ cases where it would be harder to temporarily work around the issue if the memory is permanent.
Given that every page that's not backed by a file is handed to the applications after being zeroes by the OS, and the OS itself obviously is supposed to initialize its own variables before use, I just don't see how this is of any concern to anyone. It's an imaginary problem.
Just so that you know, RAM contents do persist between power cycles in everyday hardware, including whatever you use to read this post. The RAM contents decay exponentially, with the exponent depending on temperature in such a way that lower temperature increases the half-life of memory contents. It doesn't affect anything, really, since a power cycle explicitly wipes all this memory. Of course if you're after cryptographic keys and such, the fact that main memory is nonvolatile does make a difference, but that's because most code that holds sensitive keys is not written to keep the keys solely in CPU caches.
The application code doesn't assume any such thing, because it's an assumption that is irrelevant to anything most application code could care about. It's the operating system that provides a certain execution environment that the applications are coded to. Just as an application programmer doesn't have to care (if they don't want to) about system going to sleep or being hibernated, you wouldn't care about the sleep or hibernation being implemented with nonvolatile main storage. The execution environment seen by the applications would be the same.
In every virtualized environment out there, the functionality of suspension and resumption of a VM's snapshot (including the implicit current state's snapshot) is equivalent to persistence across power cycles. Pray tell again, how is it a problem, because so far you're really insisting there is a problem, but you just won't share with anyone exactly how is it a problem. You're trying to make an argument, by all means, do make it, don't keep us guessing.
Code that's serious about security will keep at least the sensitive keys, if not the cleartext as well, only in the CPU's caches, and this requires some cooperation from the OS obviously, but it's not something that people usually bother to implement in spite of at least x86 and amd64 architectures letting you do so. The RAM gets entirely out of the picture if you assume that you're running on bare metal. In a virtual machine it might be much harder.
It's not just a serious risk, you can pretty much count on it. SD cards are not meant for permanent data storage when they are not powered. When powered, the built-in controller does patrol reads and reclaims pages that go weak before you lose any data. An unpowered SD card is really meant to be used to move data between things, not to store it for any prolonged periods of time. It's simply not designed for that.
Last I checked, pretty much no code assumes that RAM is volatile. Even the volatile keyword in C doesn't mean that if you store something there, it'll magically disappear, just that it may get modified by "other things" (other threads of execution, other processes, peripherals, ...).
I think that you've made up an imaginary problem for yourself. Just think about it. When an operating system maps a fresh regular memory page for a process, it will be zeroed sometime before the process reads it. Or didn't you know that in C/C++, all non-automatic, non-heap variables are always initialized/default constructed, respectively? In C running on a modern OS it can get wasteful, since first the OS zeroes the pages, then usually the C runtime library zeroes them again.
The biggest benefits include immunity to power outages (with cooperation from the hypervisor layer) and ease of diagnostics on systems that "die" and are in need of such diagnosis (say a car ECU after a crash). Saturn V's engine controllers used non-volatile core memory and IIRC it came handy more than once.
When you start seeing those advertised by the Reynolds Corporation, you'll know that big heatsinks it's going to be :)
not to mention getting your homonyms correct which I can usually do at speed if there are two isolated main forms to resolve, but not for palette/pallet/palate or muddles like Seine/sine/sign/sing/singe/singer/signer/seignior/Seigneur/senior/Seniour/senorita where finger habits start seeing double
That is very interesting - I never imagined that anyone who knows the spelling of those various homophonic forms would have any issues typing them correctly each and every time, save for random typos. People are complex beasts :)
Never mind that this is like usability 101.
What they do is they use a canned jbig2 image compression library, without much understanding. Very typical, after all the use of a library is supposed to not have you understand the tricky parts of image compression, right? Um, yeah, right.
This shouldn't be buried on page 107. It should be a warning on the first page. Heck, on top of the box the device is shipped in, for all I care. The scanned document should have that setting embedded as both metadata and a visible tag, so that it would be obvious on third generation documents (printouts from PDFs!) that the source could have had such errors. At least it's possible to decode jbig2 and visually mark all blocks on the page that have reference count larger than one. That way, if you still have the PDFs, you know what areas to audit. It's still a big snafu if you ask me.
Just in case people miss the obvious: The differing opening and closing quotes are the correct punctuation marks. It was only due to the typewriters and teletypes that the mangling into one quote has begun. The MS Office quotes are not "smart", they are merely correct.
Wait a minute, wouldn't it eventually piss you off too if you tried to correct obvious and trivial spelling or punctuation mistakes, doing your little contribution, only to be indirectly told "go fuck yourself"?!
Well, if you need to imagine such things, there's your problem right there. In other words: how do you propose those victims will be obtaining the information that 10 years after the fact people are still leering at the pictures? The fact that it's their own pictures doesn't make it any less illegal for them to access those pictures, mind you. I'd say that if a formerly abused child, now adult, would be considered a felon just for, say, checking if the pictures of him/herself are still out there - that's just one more argument for how broken such laws are. The law, as stated, will gladly re-victimize the victim again and again, just so that some lawmaker somewhere can feel good about themselves.
But the issue is that just because one is a well wisher who really, really wishes for "that market" to be "extinguished", it doesn't mean that one's well wishes are executable outside of some imaginary world, you know. Hell being paved with good intentions and all that. One's issue might be the presumed inability to differentiate between the market for pictures of some sort, vs. the production of such pictures. Only the second activity actually hurts the kids, one should recall.
All that I can think of at the moment is: Since trafficking in child pornography is mostly illegal, supposedly there are "hoops" to jump through if you want to be let into one of those trafficking rings. Those hoops can all be summarized as "provide original materials, and we'll guide you just to make sure you're not perusing some law enforcement image database". That's the very real unintended consequence of going hard on child pornography: you actually encourage more of it - presumably a LEO trying to break into one of those rings won't be abusing their own kid just to get in, right?
I think that the sad state of affairs is that there's lots of child pornography available out there, and people who are merely after that sort of material are harming nobody but themselves, in contrast to the people who produce such materials. Limiting access can often imply, the human being a resourceful creature, that they'll "make their own" - and now you've got actual kid abuse precipitated by laws to protect the kids. Sort of like 16 year olds getting jailed for distribution of child pornography when they sext their own nude pictures - how the fuck does it protect anyone, I just don't know. But everyone is a "think of the children" well-wisher, right? Yeah, right.