Packed executable code has to be unpacked at some point before it is executed, and if the virus scanner is actively monitoring processes it can detect it at that point.
If there's a collapsed comment in the comment tree, clicking opens it instead of doing what you intended. If the comment you're replying to is nested deeply, you have to click over and over to open all the parent comments. Then you have to scroll waaaaay back down to find the comment post form again. It's a pain in the ass.
You know the Reese's ad about how chocolate and peanut better go better together? I bet whoever came up with the ViewSonic ViewPad 10 had the same aspiration. The problem is this dual-OS tablet is not a delectable combination. Think creamed spinach and red licorice, not peanut butter and chocolate.
Probably because a zoom or pan is global, rather than having to scale/offset every tile image individually. Not that that's by any means impossible or even difficult...
Flash and EEPROM memories are different... because of the way they are erased. Flash is divided into blocks, the entirety of the block is erased in a single operation.... EEPROM... cells can be erased individually.
Technically they could very well be made of the same components... the support circuitry differs
The phrase "eeproms emulated in flash" is still nonsensical, because emulation would have to occur in the support circuitry, which is the only difference between the two anyway. If anything, it means that the EEPROM is erased and written by blocks like flash, but the flash controller is designed to seamlessly erase an entire block and then re-write it whenever a single byte is modified in the eeprom, making it look like a memory cell can be erased individually.
However that would make the lifespan of the memory significantly less, not more, so it can't be the explanation for the increase in lifespan of a modern EEPROM as sgt scrub was trying to suggest. The simple fact is that technology has advanced and EEPROM last for far more erase cycles than it used to.
The bootloader is the BIOS (well, part of it). And whether or not the OS ignores the BIOS routines or not depends on the OS, I would assume. The legacy Mac OS relied much more on the BIOS routines - the PC BIOS was much simpler, one reason why it was reverse-engineered and the BIOS on Mac systems wasn't. To run a legacy Mac operating system in an emulator, you need a copy of an original Mac BIOS dumped from its ROM, because the OS calls a lot of routines that were stored on the ROM.
But even the PC BIOS supplied such things as INT 10h (video routines), INT 13h (file system routines), and several other interrupts for serial communication, keyboard, and printer, among other things. Regardless of whether the OS used them or not, user-level programs could (and did) use these interrupts back in the DOS era, which means that anything running legacy DOS apps has to emulate these interrupts.
Now is 300 1-hour photo shoots really a year's work?
Even if 4 hours of work are required for a 1-hour photo shoot that's 1200 / 8 = 150 8-hour days.
Besides the shoot itself (1 hour), he also has to set up and take down equipment (the customer isn't going to want to spend too long waiting around for backdrops and lights when they paid for an hour-long shoot), developing the pictures (not using a computer that develops an entire roll at the same exposure setting like Walgreens, I assume), printing the pictures, sorting the pictures, reviewing the pictures with the customer, and taking the orders for reprints and having them made... I highly doubt that a 1-hour shoot takes any less than a solid day's work.
Whether it is uboot, LinuxBIOS, or a legacy BIOS, it's going to be doing a lot of stuff like checking memory & polling the IDE/SATA ports to detect the hard drives and verify that they're the expected size, loading the BIOS interrupt handler routines, starting basic drivers e.g. for keyboard, network, and hard drive support (any of which might be over USB), monitoring keyboard to show BIOS settings screens on keystroke, and selecting a boot device from which to load the bootstrap code which loads and initializes the OS itself.
I do "get it". My point was only that dargaud's bootloader does almost none of those things. It just copies a kernel from a fixed location in flash memory and jumps to it. Obviously it's going to be much simpler than "everything but the kitchen sink boot projects".
But the example I gave was something that wasn't in the app store (bypassing the second hurdle) and gained root (bypassing the 3rd). And I fail to see how it would be difficult to make something that wouldn't be easily noticed.
I'll grant you that we're not aware of any still-existing exploits that allow for this, but they've been found and exploited in the past, so it's not like iOS is as immune as people would like to act like it is.
OK, so even accepting that, the plaintiff could still say, "Fine, let's at least see if the IP address is traceable to one specific person. If there were two or more people in the house, we'll give up and leave, and concentrate only one the cases where there was just one person in the house." That will still leave a lot of cases where the IP is traceable to a specific person (e.g. if a corporation has assigned the IP to a specific user on their network). So it doesn't seem a sufficient reason to throw out all the subpoenas.
I suspect it would leave very few cases where it is provable that one specific person had done it. Even if there was normally only one person in the house, they could have had a visitor who might have had access to the computer; they might have had an unsecured wireless network; they might have had a secured wireless network but been told by tech support to do a factory reset on their modem and not immediately realized that it was unencrypted afterward; etc. etc. etc. Basically, it could devolve very easily into a million different scenarios that would make it extremely difficult to prove they were guilty. And even if you could prove it, things would be so completely different on a case-by-case basis that lumping them into a single lawsuit would be completely impractical. Which, in fact, it is, unless you're trying to get a bunch of the defendants to settle before the trial, and hoping to get whoever does go to trial quickly declared guilty with little or no substantial proof of guilt.
C : \ U s e r s \ j 4 | \ / | 3 5 \ D e s k t o p \ Z e u s \ ... yeah, no. | \ / are illegal/reserved characters in a Windows pathname...
If you're as pedantic as GP, that's still not a question.
"I wonder if the devs of zeus are going to sue anyone for leaking their code."
Packed executable code has to be unpacked at some point before it is executed, and if the virus scanner is actively monitoring processes it can detect it at that point.
What makes you think they didn't notice?
I grew up drinking flamable well water, and that was long before fracking, 1965-1973.
I just tried it. Still broken.
If there's a collapsed comment in the comment tree, clicking opens it instead of doing what you intended. If the comment you're replying to is nested deeply, you have to click over and over to open all the parent comments. Then you have to scroll waaaaay back down to find the comment post form again. It's a pain in the ass.
You keep using that word. I do not think it means what you think it means.
Mozilla Firefox before 3.5.16 and 3.6.x before 3.6.13, and SeaMonkey before 2.0.11
He knew that.
Still... I'm pretty sure I've seen people who put butter, syrup, and peanut butter on their pancackes.
Saag paneer (curried spinach with fried fresh acid-set cheese) often includes star anise in the spice mix. Star anise tastes a bit like licorice.
Red licorice is generally either strawberry or cherry flavor.
Nobody wanted to use it long enough to find out.
You know the Reese's ad about how chocolate and peanut better go better together? I bet whoever came up with the ViewSonic ViewPad 10 had the same aspiration. The problem is this dual-OS tablet is not a delectable combination. Think creamed spinach and red licorice, not peanut butter and chocolate.
Does anybody else want to try that now?
No? Just me?
Okay...
I cannot see the moderation on comments until at least plus 4. So -1 thru 3 says nothing beside the comment unless its been modded up and then down.
I think that's a deliberate feature; comments which have received only one modpoint don't show the primary moderation until you click the score.
Of course, that also collapses the comment and hides its children, which is a bug.
I'm not sure what interaction benefit the 'click to open parent' gives.
It's a bug.
Where do you live?
Yes. For some reason it does. [PDF]
Probably because a zoom or pan is global, rather than having to scale/offset every tile image individually. Not that that's by any means impossible or even difficult...
Flash and EEPROM memories are different ... because of the way they are erased. ... ... cells can be erased individually.
Flash is divided into blocks, the entirety of the block is erased in a single operation.
EEPROM
Technically they could very well be made of the same components ... the support circuitry differs
The phrase "eeproms emulated in flash" is still nonsensical, because emulation would have to occur in the support circuitry, which is the only difference between the two anyway. If anything, it means that the EEPROM is erased and written by blocks like flash, but the flash controller is designed to seamlessly erase an entire block and then re-write it whenever a single byte is modified in the eeprom, making it look like a memory cell can be erased individually.
However that would make the lifespan of the memory significantly less, not more, so it can't be the explanation for the increase in lifespan of a modern EEPROM as sgt scrub was trying to suggest. The simple fact is that technology has advanced and EEPROM last for far more erase cycles than it used to.
You mean like Google Maps?
The bootloader is the BIOS (well, part of it). And whether or not the OS ignores the BIOS routines or not depends on the OS, I would assume. The legacy Mac OS relied much more on the BIOS routines - the PC BIOS was much simpler, one reason why it was reverse-engineered and the BIOS on Mac systems wasn't. To run a legacy Mac operating system in an emulator, you need a copy of an original Mac BIOS dumped from its ROM, because the OS calls a lot of routines that were stored on the ROM.
But even the PC BIOS supplied such things as INT 10h (video routines), INT 13h (file system routines), and several other interrupts for serial communication, keyboard, and printer, among other things. Regardless of whether the OS used them or not, user-level programs could (and did) use these interrupts back in the DOS era, which means that anything running legacy DOS apps has to emulate these interrupts.
Now is 300 1-hour photo shoots really a year's work?
Even if 4 hours of work are required for a 1-hour photo shoot that's 1200 / 8 = 150 8-hour days.
Besides the shoot itself (1 hour), he also has to set up and take down equipment (the customer isn't going to want to spend too long waiting around for backdrops and lights when they paid for an hour-long shoot), developing the pictures (not using a computer that develops an entire roll at the same exposure setting like Walgreens, I assume), printing the pictures, sorting the pictures, reviewing the pictures with the customer, and taking the orders for reprints and having them made... I highly doubt that a 1-hour shoot takes any less than a solid day's work.
i forgot about eeproms emulated using flash which i guess is what they all are now.
Emulated? Flash memory is a type of EEPROM (electronically erasable programmable read-only memory).
back in the day eeproms could only be flashed between 10 and 100 times.
Back in the day 640k of RAM was enough space for anyone, too. Technology has advanced since then...
Whether it is uboot, LinuxBIOS, or a legacy BIOS, it's going to be doing a lot of stuff like checking memory & polling the IDE/SATA ports to detect the hard drives and verify that they're the expected size, loading the BIOS interrupt handler routines, starting basic drivers e.g. for keyboard, network, and hard drive support (any of which might be over USB), monitoring keyboard to show BIOS settings screens on keystroke, and selecting a boot device from which to load the bootstrap code which loads and initializes the OS itself.
I do "get it". My point was only that dargaud's bootloader does almost none of those things. It just copies a kernel from a fixed location in flash memory and jumps to it. Obviously it's going to be much simpler than "everything but the kitchen sink boot projects".
copy kernel from flash to mem, jump to it, done
Normally a BIOS does power-on checks and loads a library of interrupt handlers. Naturally, leaving all of that out would make it very simple...
But the example I gave was something that wasn't in the app store (bypassing the second hurdle) and gained root (bypassing the 3rd). And I fail to see how it would be difficult to make something that wouldn't be easily noticed.
I'll grant you that we're not aware of any still-existing exploits that allow for this, but they've been found and exploited in the past, so it's not like iOS is as immune as people would like to act like it is.
OK, so even accepting that, the plaintiff could still say, "Fine, let's at least see if the IP address is traceable to one specific person. If there were two or more people in the house, we'll give up and leave, and concentrate only one the cases where there was just one person in the house." That will still leave a lot of cases where the IP is traceable to a specific person (e.g. if a corporation has assigned the IP to a specific user on their network). So it doesn't seem a sufficient reason to throw out all the subpoenas.
I suspect it would leave very few cases where it is provable that one specific person had done it. Even if there was normally only one person in the house, they could have had a visitor who might have had access to the computer; they might have had an unsecured wireless network; they might have had a secured wireless network but been told by tech support to do a factory reset on their modem and not immediately realized that it was unencrypted afterward; etc. etc. etc. Basically, it could devolve very easily into a million different scenarios that would make it extremely difficult to prove they were guilty. And even if you could prove it, things would be so completely different on a case-by-case basis that lumping them into a single lawsuit would be completely impractical. Which, in fact, it is, unless you're trying to get a bunch of the defendants to settle before the trial, and hoping to get whoever does go to trial quickly declared guilty with little or no substantial proof of guilt.
So what if it only happened once? It only takes once to infect someone with a trojan or virus.
Furthermore, the simple fact that that exploit was patched doesn't mean a similar one remains yet undetected.