Ah yes. I knew there was a term for it. It's been a while since I took my thermo class. Specific heat is normalized to mass, though, and both granite and basalt are more dense than seawater. Granite is ~2700 kg/m^3, basalt is ~3000kg/m^3, while seawater at high depths is around 1050kg/m^3.
When you factor that in, water still wins, but only by a factor of 1.5 to 2.
Allow my naivete to shine: What's the temperature of all of the rock that water is in contact with, and what's its thermal capacity relative to the water? Could it be that it's slow to warm as you need to warm all the rock it's in contact with?
It was implemented against the Win16 API, and required a Windows runtime to operate. It was no less a Windows program than any other Windows program at the time. You could launch it from DOS, sure, but if that's your criteria, there wasn't a Windows program before Win95, the first Windows version to boot directly to Windows rather than launching from DOS.
Oh, yeah, I definitely remember the pain of bank-switching vs. segmented memory. I was there and programmed both. It stunk.
At least the Apple ][gs could directly address 16MB, although the 65816's addressing modes I hear were less than awesome. I must admit I never wrote any native 65816 code.
Oh, don't get me wrong. I definitely prefer a more style-sheet oriented way of declaring how a document should look, and then writing my document tagged in the elements of that style. Something style-sheet oriented is vastly superior to something more formatting-oriented at a lower level.
The problem is that most GUIs, in an effort to reduce clutter, make it at best cumbersome and at worst impossible to determine if your cursor is inside or outside of a formatting tag. (And then there's Word and Outlook, who add a bunch of heuristic behaviors on top of that that just make it worse. I've had to nuke whole paragraphs just because there's some weird 'hot point' in the middle of a line somewhere that keeps making the editor go gonzo. FrameMaker is not as bad, but it gets weird in other ways, especially with figures, tables, their anchors and their captions. And then there's the brokenness of nearly every browser-based rich-text editing widget ever.)
I would much rather have a WYSIWYG preview and a separate, less WYSIWYG editing mode that was more tag oriented. Heck, I'd write my specifications in TeX or LaTeX if they let me. But, alas, I'm stuck with FrameMaker and Word. At least with FM, they force us to never use local formatting overrides and stick to the style sheet. They strip all formatting overrides when compiling a book.
Ah, boundary conditions on the dates. Makes sense.
I had read that Excel had preview copies out in 1984 (which is fairly quick, considering the Mac itself launched in 1984), but didn't launch officially until 1985. And I suppose, since Windows was still deridingly referred to as "Wintendo" in some circles and generally not widely adopted on PCs, it makes sense that Microsoft would go with an "Excel for MS-DOS 3" marketing stance, even though it really was a Windows app.
FWIW, WordPerfect, my favorite word processor of the early-to-mid-90s (replacing AppleWorks and///EasyPieces on the Apple//e and Apple///) got subsumed in the same way as Lotus 1-2-3 did by Excel. While Word for DOS was nothing special, Word for Windows actually was a proper Windows application by the time Word 6 came out. WordPerfect 5.1 on DOS was great, but WordPerfect 6 lost it somehow. The DOS version overreached, trying to bring WYSIWYG into the character-oriented DOS world. The Windows version clung too strongly to their DOS traditions and never really embraced the GUI properly. It was a messy disaster. Microsoft Word 6, for all its faults, was at least largely consistent with itself and the Windows environment around it. (I still miss Reveal Codes though, to this day.)
I guess you never ran either an IBM PC XT or an Apple ][. Both were comparable in performance for many things. (A 1MHz 6502 pulls around 0.43 MIPS, while a 4.77MHz 8088 pulls about 0.35 MIPS.) And hipsters didn't arrive on the scene until the Second Coming of Steve Jobs.
No, Mod GP -1 inaccurate. Lotus 1-2-3 never ran on the Apple ][ family. It ran on the PC from the get-go. It was launched in 1983, not 1982.
Lotus bought VisiCalc in 1985, not 1986.
Excel didn't come out until 1985 (not 1984), and it was never ported to DOS. Its first appearance on a PC was as a Windows version in 1987. It came with a run-time version of Windows if you didn't already have Windows. Excel managed to kill Lotus 1-2-3 primarily because it was born as a GUI app and was native GUI all the way through. Lotus 1-2-3 stumbled on its way to the GUI, which allowed Excel to eventually overtake it.
Lotus 1-2-3 was born on PCs. It never ran on an Apple ][ family machine. VisiCalc, MultiPlan and AppleWorks were on the Apple ][. (Well, technically AppleWorks only ran on the//e and later with an extended 80-column card. It required 128K or more to run.)
Well, just because the missed advertising didn't affect sales yet, there's no guarantee that would continue to hold. Eventually someone would fill the advertising vacuum and they'd have a turf war on their hands.
We do something similar with our tool releases at work. The release notes indicate bugs that were filed on a previous release and closed with the current release, and if there are open issues what the open issues are. (Usually, it's something very obscure, otherwise it would be fixed.) We do something similar with chip errata. The errata document states which chip revisions are affected, and thus implicitly what chip revision fixes the issue.
Thus, we actually have a two tiered approach. There's the internal system(s) that tracks bugs against the actual development. So, if a bug shows up in a development version, developers and internal testers can file bugs on each other. All that noise has absolutely no business going outside the development team, as it's really just developer-to-developer communication. Then there's the customer issue tracking system. Customer-reported bugs get filed in that system, and they get their own ticket number, and it gets tied to a bug filed in the internal system. The customer bug reports are the ones we comment on in the release notes, along with any notable bugs we discovered in internal testing that customers may not have hit yet.
Disclaimer: My description above is a loose description of the processes we employ at work, and there is variation across teams and business units. It isn't intended to be rigorous. I'm only commenting on my team and teams I've worked closely with. The principle is the same, though. Our dirty laundry (the internal bug tracking system) stays internal. Externally reported bugs get tracked somewhat more opaquely, simply connecting the bug report to the release it's fixed in. It seems quite reasonable to me.
While that may be true, web browsers aren't using SHA-1 for encryption, especially for validating certificates. It's a cryptographically strong hashing function, but not, on its own, encryption.
What about an app that burns the bandwidth of playing a video as part of its 'preload', but never provides feedback that it's doing so? Is the user supposed to be clairvoyant?
And where on the label does the Facebook app say how much data it's going to use?
And how about the fact that for a long time, the FB app was fine, and then a change that FB pushed out to folks surprised them later only after they were using it?
It's worth remembering that not using the facebook app is supposed to hit facebook harder than yourself.
That's only true if there's a wide-scale boycott. Otherwise, network effects suggest you're wrong. It's like arguing "Not using Windows is supposed to hit Microsoft harder than yourself." BS. Microsoft hasn't felt a thing since I switched to other platforms years ago. I, however, have had to deal with incompatibilities and quirkiness. For the vast majority of users it never made sense to switch from Windows and it still doesn't, and the reason why is network effects.
The issue here is that most smart phone plans make you, the user, responsible for paying for the total amount of bandwidth consumed, but the phone and the apps don't give you a good mechanism to allow you to act on that responsibility in a meaningful way. Saying "Well, then, don't use it" is unhelpful and unrealistic.
Ok, as explained elsewhere, this isn't autoplay per se but rather auto preload. That is, the video consumes bandwidth with no outward indication it's doing so. Again, do explain how the miracle of personal responsibility solves this.
On my BB10 (which I otherwise quite enjoy), many websites will autoplay video. I'll click on an article to read it, and then 10-15 seconds later (sometimes faster, sometimes slower), it'll freeze and force me into a full screen video due to autoplay. Sometimes I can get it to stop quickly and can go back to the article, but quite often I just swipe to make the video not-full-screen and immediately close the page.
That gap between opening the page and getting hijacked by the video appears to be buffering time. That burns bandwidth my connection before I even get a chance to know it might be happening. And, as you say, it's a special kind of awfulness. I'd love to disable this autoplay, but there doesn't seem to be any option for this. (FWIW, disabling Flash doesn't do it.)
At least FB has a setting where you can disable this. The fact it's taken multiple 'news' articles on multiple websites to get the word out, though, hints that FB's roll out of the feature is antisocial at best. If nothing else, they should have defaulted it to preloading only if it was operating over WiFi.
Ok, so you're saying "never launch the Facebook app" is the only responsible choice? These are videos that autoplay without audio when they're not even visible on the screen, so you don't even know that this is happening. (Ok, for the FB app, there is a setting to disable this, but the fact that people haven't heard of this without multiple news articles on the topic says that FB's default caught a good fraction of their users by surprise.)
I personally have been bitten by autoplay ad videos on my BB10 when trying to visit news articles. I haven't found a way to disable video auto-play on this phone with its browser at all. (No, disabling Flash doesn't help.) Are you saying that the only responsible action is to never browse the web from my phone, so I never get bitten by a website that might spring an unwanted, unwarranted (and usually unrelated to the article) video on me? If I browse the web, I'm irresponsible?
Please, do explain how personal responsibility plays a role here, and what it translates to for someone who has no interest in viewing any videos ever on his/her smartphone unless they explicitly ask them to be played. Do tell me how to rectify this moral failing.
Wires on silicon aren't a vacuum. The dominant effect is actually RC delay. As you make wires smaller, the resistance goes up (inversely proportional to cross-sectional area). As you make the wires closer together, capacitance goes up (inversely proportional to distance between the conductors). So, as geometries shrink, propagation delays for real signals in real wires on real silicon go up.
I won't even get into buffers which are required to recondition the signal on long routes... (Someone elsewhere on the thread already did.)
Sure, throughput is what matters most for operations you can parallelize. However, as Amdahl's Law cruelly reminds us, there's always parts of the problem that remain serial, and they'll put an upper bound on performance. You can't parallelize the traversal of a linked list, no matter how hard you try. You have to invent new algorithms and programming techniques. (In the specific case of linked lists, there are other options that trade space for efficiency, such as skiplists.)
Gustafson's Law does offer some hope: As we build more capable machines, we'll tackle bigger problems to utilize those machines. That's how we're able to, for example, get wireless data speeds on our cell phones operating on batteries that would make wired modem users of just 10-15 years ago jealous.
But, Gustafson's Law only serves as a counterpoint to Amdahl's Law to the extent that you tackle bigger problems, as opposed to trying to reduce current problems to take less time and energy.
Slashdot Mirror
Thank you for the detailed, thoughtful reply, including all the numbers.
Ah yes. I knew there was a term for it. It's been a while since I took my thermo class. Specific heat is normalized to mass, though, and both granite and basalt are more dense than seawater. Granite is ~2700 kg/m^3, basalt is ~3000kg/m^3, while seawater at high depths is around 1050kg/m^3.
When you factor that in, water still wins, but only by a factor of 1.5 to 2.
Allow my naivete to shine: What's the temperature of all of the rock that water is in contact with, and what's its thermal capacity relative to the water? Could it be that it's slow to warm as you need to warm all the rock it's in contact with?
It was implemented against the Win16 API, and required a Windows runtime to operate. It was no less a Windows program than any other Windows program at the time. You could launch it from DOS, sure, but if that's your criteria, there wasn't a Windows program before Win95, the first Windows version to boot directly to Windows rather than launching from DOS.
Oh, yeah, I definitely remember the pain of bank-switching vs. segmented memory. I was there and programmed both. It stunk.
At least the Apple ][gs could directly address 16MB, although the 65816's addressing modes I hear were less than awesome. I must admit I never wrote any native 65816 code.
Oh, don't get me wrong. I definitely prefer a more style-sheet oriented way of declaring how a document should look, and then writing my document tagged in the elements of that style. Something style-sheet oriented is vastly superior to something more formatting-oriented at a lower level.
The problem is that most GUIs, in an effort to reduce clutter, make it at best cumbersome and at worst impossible to determine if your cursor is inside or outside of a formatting tag. (And then there's Word and Outlook, who add a bunch of heuristic behaviors on top of that that just make it worse. I've had to nuke whole paragraphs just because there's some weird 'hot point' in the middle of a line somewhere that keeps making the editor go gonzo. FrameMaker is not as bad, but it gets weird in other ways, especially with figures, tables, their anchors and their captions. And then there's the brokenness of nearly every browser-based rich-text editing widget ever.)
I would much rather have a WYSIWYG preview and a separate, less WYSIWYG editing mode that was more tag oriented. Heck, I'd write my specifications in TeX or LaTeX if they let me. But, alas, I'm stuck with FrameMaker and Word. At least with FM, they force us to never use local formatting overrides and stick to the style sheet. They strip all formatting overrides when compiling a book.
Ah, boundary conditions on the dates. Makes sense.
I had read that Excel had preview copies out in 1984 (which is fairly quick, considering the Mac itself launched in 1984), but didn't launch officially until 1985. And I suppose, since Windows was still deridingly referred to as "Wintendo" in some circles and generally not widely adopted on PCs, it makes sense that Microsoft would go with an "Excel for MS-DOS 3" marketing stance, even though it really was a Windows app.
FWIW, WordPerfect, my favorite word processor of the early-to-mid-90s (replacing AppleWorks and ///EasyPieces on the Apple //e and Apple ///) got subsumed in the same way as Lotus 1-2-3 did by Excel. While Word for DOS was nothing special, Word for Windows actually was a proper Windows application by the time Word 6 came out. WordPerfect 5.1 on DOS was great, but WordPerfect 6 lost it somehow. The DOS version overreached, trying to bring WYSIWYG into the character-oriented DOS world. The Windows version clung too strongly to their DOS traditions and never really embraced the GUI properly. It was a messy disaster. Microsoft Word 6, for all its faults, was at least largely consistent with itself and the Windows environment around it. (I still miss Reveal Codes though, to this day.)
I guess you never ran either an IBM PC XT or an Apple ][. Both were comparable in performance for many things. (A 1MHz 6502 pulls around 0.43 MIPS, while a 4.77MHz 8088 pulls about 0.35 MIPS.) And hipsters didn't arrive on the scene until the Second Coming of Steve Jobs.
No, Mod GP -1 inaccurate. Lotus 1-2-3 never ran on the Apple ][ family. It ran on the PC from the get-go. It was launched in 1983, not 1982.
Lotus bought VisiCalc in 1985, not 1986.
Excel didn't come out until 1985 (not 1984), and it was never ported to DOS. Its first appearance on a PC was as a Windows version in 1987. It came with a run-time version of Windows if you didn't already have Windows. Excel managed to kill Lotus 1-2-3 primarily because it was born as a GUI app and was native GUI all the way through. Lotus 1-2-3 stumbled on its way to the GUI, which allowed Excel to eventually overtake it.
Lotus 1-2-3 was born on PCs. It never ran on an Apple ][ family machine. VisiCalc, MultiPlan and AppleWorks were on the Apple ][. (Well, technically AppleWorks only ran on the //e and later with an extended 80-column card. It required 128K or more to run.)
Well, just because the missed advertising didn't affect sales yet, there's no guarantee that would continue to hold. Eventually someone would fill the advertising vacuum and they'd have a turf war on their hands.
Wow, that's some comedy gold right there!
We do something similar with our tool releases at work. The release notes indicate bugs that were filed on a previous release and closed with the current release, and if there are open issues what the open issues are. (Usually, it's something very obscure, otherwise it would be fixed.) We do something similar with chip errata. The errata document states which chip revisions are affected, and thus implicitly what chip revision fixes the issue.
Thus, we actually have a two tiered approach. There's the internal system(s) that tracks bugs against the actual development. So, if a bug shows up in a development version, developers and internal testers can file bugs on each other. All that noise has absolutely no business going outside the development team, as it's really just developer-to-developer communication. Then there's the customer issue tracking system. Customer-reported bugs get filed in that system, and they get their own ticket number, and it gets tied to a bug filed in the internal system. The customer bug reports are the ones we comment on in the release notes, along with any notable bugs we discovered in internal testing that customers may not have hit yet.
Disclaimer: My description above is a loose description of the processes we employ at work, and there is variation across teams and business units. It isn't intended to be rigorous. I'm only commenting on my team and teams I've worked closely with. The principle is the same, though. Our dirty laundry (the internal bug tracking system) stays internal. Externally reported bugs get tracked somewhat more opaquely, simply connecting the bug report to the release it's fixed in. It seems quite reasonable to me.
I doubt they exist.
You still need a way to mix a key into the result if you want a symmetric cipher.
In any case, certificate validation doesn't use SHA-1 as a cipher.
While that may be true, web browsers aren't using SHA-1 for encryption, especially for validating certificates. It's a cryptographically strong hashing function, but not, on its own, encryption.
What about an app that burns the bandwidth of playing a video as part of its 'preload', but never provides feedback that it's doing so? Is the user supposed to be clairvoyant?
And where on the label does the Facebook app say how much data it's going to use?
And how about the fact that for a long time, the FB app was fine, and then a change that FB pushed out to folks surprised them later only after they were using it?
That's only true if there's a wide-scale boycott. Otherwise, network effects suggest you're wrong. It's like arguing "Not using Windows is supposed to hit Microsoft harder than yourself." BS. Microsoft hasn't felt a thing since I switched to other platforms years ago. I, however, have had to deal with incompatibilities and quirkiness. For the vast majority of users it never made sense to switch from Windows and it still doesn't, and the reason why is network effects.
Your arguments remind me of the 'Countepoint' guy from Airplane.
The issue here is that most smart phone plans make you, the user, responsible for paying for the total amount of bandwidth consumed, but the phone and the apps don't give you a good mechanism to allow you to act on that responsibility in a meaningful way. Saying "Well, then, don't use it" is unhelpful and unrealistic.
Ok, as explained elsewhere, this isn't autoplay per se but rather auto preload. That is, the video consumes bandwidth with no outward indication it's doing so. Again, do explain how the miracle of personal responsibility solves this.
On my BB10 (which I otherwise quite enjoy), many websites will autoplay video. I'll click on an article to read it, and then 10-15 seconds later (sometimes faster, sometimes slower), it'll freeze and force me into a full screen video due to autoplay. Sometimes I can get it to stop quickly and can go back to the article, but quite often I just swipe to make the video not-full-screen and immediately close the page.
That gap between opening the page and getting hijacked by the video appears to be buffering time. That burns bandwidth my connection before I even get a chance to know it might be happening. And, as you say, it's a special kind of awfulness. I'd love to disable this autoplay, but there doesn't seem to be any option for this. (FWIW, disabling Flash doesn't do it.)
At least FB has a setting where you can disable this. The fact it's taken multiple 'news' articles on multiple websites to get the word out, though, hints that FB's roll out of the feature is antisocial at best. If nothing else, they should have defaulted it to preloading only if it was operating over WiFi.
Ok, so you're saying "never launch the Facebook app" is the only responsible choice? These are videos that autoplay without audio when they're not even visible on the screen, so you don't even know that this is happening. (Ok, for the FB app, there is a setting to disable this, but the fact that people haven't heard of this without multiple news articles on the topic says that FB's default caught a good fraction of their users by surprise.)
I personally have been bitten by autoplay ad videos on my BB10 when trying to visit news articles. I haven't found a way to disable video auto-play on this phone with its browser at all. (No, disabling Flash doesn't help.) Are you saying that the only responsible action is to never browse the web from my phone, so I never get bitten by a website that might spring an unwanted, unwarranted (and usually unrelated to the article) video on me? If I browse the web, I'm irresponsible?
Please, do explain how personal responsibility plays a role here, and what it translates to for someone who has no interest in viewing any videos ever on his/her smartphone unless they explicitly ask them to be played. Do tell me how to rectify this moral failing.
Sorry, dude, that's sarcasm. not satire.
Wires on silicon aren't a vacuum. The dominant effect is actually RC delay. As you make wires smaller, the resistance goes up (inversely proportional to cross-sectional area). As you make the wires closer together, capacitance goes up (inversely proportional to distance between the conductors). So, as geometries shrink, propagation delays for real signals in real wires on real silicon go up.
I won't even get into buffers which are required to recondition the signal on long routes... (Someone elsewhere on the thread already did.)
Can you propose a non-stochastic process that produces alpha particles, and a way of constructing a family of logic gates out of that process?
Sure, throughput is what matters most for operations you can parallelize. However, as Amdahl's Law cruelly reminds us, there's always parts of the problem that remain serial, and they'll put an upper bound on performance. You can't parallelize the traversal of a linked list, no matter how hard you try. You have to invent new algorithms and programming techniques. (In the specific case of linked lists, there are other options that trade space for efficiency, such as skiplists.)
Gustafson's Law does offer some hope: As we build more capable machines, we'll tackle bigger problems to utilize those machines. That's how we're able to, for example, get wireless data speeds on our cell phones operating on batteries that would make wired modem users of just 10-15 years ago jealous.
But, Gustafson's Law only serves as a counterpoint to Amdahl's Law to the extent that you tackle bigger problems, as opposed to trying to reduce current problems to take less time and energy.