But Windows Phone has no excuse for being late to the party.
WinCE displaced PalmOS, to the extent that most of the Palm-brand phones had WinCE on them. Microsoft is NOT new to the smartphone market--they were there when it got started, before we were even sure we were going to call them smartphones.
Microsoft is not like Apple or Google; both of whom brought phone OSes to market when they had never produced a phone OS before. Apple had experience with Newton, ages ago, but all Google had was the ability to look for things.
That's part of why we're not cutting Microsoft any slack.
The other part is, all the people who said it was unacceptable that the iPhone didn't do X when version 1 or 2 were on the market means that Microsoft should ALREADY KNOW the system MUST do X. They didn't need to release "what they've got so far" to find out what customers really want, they can see what the market has already done.
And Microsoft is huge and has gobs of money; why SHOULD we cut them any slack? This isn't the clever little Silicon Valley start-up upstart taking on the Man. This is the Man.
15/8 and 16/8 may be adjacent, but you can't make a/7 out of them. You're stuck with two/8s. You'd need 14/8 and 15/8 or 16/8 and 17/8 to make 14/7 or 16/7, respectively.
So the value is only in the number of addresses, not in the "adjacency".
Especially since 15 is all-bits-clear in the high nybble and 16 has the lowest bit set in the high nybble; you can't combine them into anything smaller than a/3. (If I'm counting on my fingers right.)
If you've got a table saw, and have the older version, IVAR shelving is available in any width narrower than what is available in-store.
(The "old version" had rabbets cut in the wood with metal L-brackets to hang on the shelf pins. The "new version" has plastic things wedged in to a saw-kerf cut into each shelf end. The "new version" is more secure--the shelves click into place. But the "old version" is far more saw-and-router friendly.)
IBM, at least at their Toronto HQ facilities, even goes so far as to have separate "visitor" and "employee" cafeterias. The "visitor" one is outside the badge-secured area, and adjacent to the training centre.
The "employee" one is inside the secure zone. The food was pretty good, too... back when "Java 1.1" was cool, anyway.
Can't say the same for the new Lab facility on Warden... about the food quality. The caf is in the secure zone. Even the Tim Horton's is in the secure zone.
The GPL does not require you send changes back to the original developer.
The GPL requires you give source code to the people you give binaries to.
So you don't need to make any effort to contact the original developer in maintaining your fork. As long as your downstream gets the source, you're good.
Since the GPL also requires that you permit your downstream receivers to make modifications and distribute copies, the GPL cannot PREVENT the original developer from getting your changes. But that's not the same as REQUIRING you to send them upstream.
There are licenses that require your changes go upstream and/or get vetted by the upstream provider. Or even assign copyright to the upstream--the original Netscape Public License was like that, I believe.
The GPL, though, is all about people who RECEIVE the code. It isn't about people who PROVIDE the code.
'Cause Sun wasn't going to bother. Oracle is even less likely to be interested; Java is probably the only free download from Sun left, they are unlikely to add to the list. It was even more confusing on Mac OS Classic: Macintosh Runtime for Java had a completely orthogonal numbering system to Sun's JRE and JDK.
Sun's idea of "Write Once, Run Anywhere" should have "we feel like letting you" appended to it. Sun also didn't bother with an OS/2 version, an AIX version, a zSeries version or an iSeries version: IBM had to make their own. Heck, it wasn't until it looked like Blackdown JDK looked like it might actually work that Sun cared enough to maintain a Linux port. Even then, Blackdown supported more CPUs than Sun did, so until OpenJDK it continued on.
Then there's the whole field-of-use mess in the certification kit....
(I'm with you on the "safe apps" thing; I've got a script that clears that option, along with other personal biases, when I set up a new account.)
My driver's ed through-the-high-school classes covered all of this. Shift-to-neutral/declutch, e-brake/park-brake, and ignition-off. And the difference between "off" and "lock".
And that was in 1986, when there were still those silly far-left-pedal parking brakes around, that you can only release by leaning under the steering wheel and pulling a handle.
Shift-to-neutral/declutch was also heavily covered in skid control and black ice reactions.
They also covered the basic bit about "machines can be repaired or replaced, people can't."
Maybe more people need to take driver's ed, and pay attention when doing it?
Maybe there should be refresher courses? Many places have your vehicle inspected regularly, how about the driver?
That one is actually a dodgy port replicator board--the drives never see the garbled command packets, so their CRC error count never moves.
A consistent comm problem to the drive itself should result in at least some of the SMART counters moving, but they will NOT fail out the drive because there is no reliable evidence it is a drive problem. For those, re-seat the SATA/SAS cables, reseat the HBA in the PCI/PCIe slot, replace the SATA/SAS cables, replace the HBA, replace the drive. In about that order--there's a lot of crappy cables on the market, and quality independent of retail price.
(I'd recommend having a test rig with a couple of different HBAs so you can determine which part is giving you grief; motherboard and a cheap PCI card is usually enough variety.)
Maybe I've got a lot of weird DVDs, but I don't batch transcode anything from optical media, I only batch rip. So, from my perspective, Blu-Ray just takes longer--it's the same process. (Except I have to use AnyDVD HD for the Blu-Ray, so I actually have to click things in the Windows VM. DVDs are ripped on media load and ejected when done.)
When I do have a bunch of DVDs or BDs that can be batch transcoded--say a season of a TV show--I do that from the ripped files, not from the original media. But I've got so many where the "right" audio track isn't obvious, even right "right" title isn't obvious, so I hand-set Handbrake for nearly everything.
Heh; I build a lot of software from scratch for developers, so that includes both Emacs and VI(mproved).
Last round, when I found out Vim was now a larger download than XEmacs, felt just so... wrong. Fortunately, that was because XEmacs has most of the packages out-of-line with the main download, so it was really bigger in the end, the Universe was still OK.
(And I switched back to GNUmacs 'cause XEmacs progress seems to be stalled.)
You say SATA drives don't have bent pin issues....
But I handed a box to UPS this morning that contained a NewEgg RMA ticket for exactly that issue. I'd never seen it before, in handing close to 200 SATA and SAS drives. The plastic in the power part of the connector was actually out of place, and the little metal fingers had not been laminated to it correctly.
So, it's possible. But, compared to always having a pair of needle-nose pliers around for unbending IDE connector pins (and 50-pin SCSI), wow is it rare.
Mind you, this was on a brand-new-out-of-the-anti-static drive, so I didn't even have a chance to even run the SMART extended offline test....
If you're going to do that, see if you can make sure that when the guy doing it still sees the original image--it's all his site visitors that get the shock pic. I mean alternate pic. Implementation left as an exercise and all that.
If you run shifts, you can do this with local labour. And if you combine it with work-from-home or "hot desking", you don't need multiple buildings, either. Having to pay premium rate for shift workers could be made up in the facilities budget.
And how old is old? I know several people still using the black & white Garmin StreetPilot... you can't get map updates for it, it's that old--circa 1998.
My Zumo is pushing 5 years old; it does all I want, and updates are still available... though now I have to pick and choose what regions to load. So I'm not replacing it.
Serial loggers might be even older, as they have no processing except the satellite receiver, so there's no rush to update them. Any chartplotting is done by the computer they're attached to.
It's possible for managed switches to lock a port to a particular MAC (or a list of them). That's done at the Ethernet layer.
Layer 3 switches can look at the IP address ('cause they're layer 3) and make sure that Approved IP Addresses are associated with Approved MAC Addresses only.
Which is still useless for all but the casual wrong-plug fault, because anyone actually breaking your network security can emit any MAC address they want. So they just need to intercept a couple of frames before switching to their gear.
You'd actually need Ethernet-level encryption or something to stop that. Or all your real connections are in VPN tunnels, and the regular LAN fabric doesn't route to anything except the tunnel server.
In other words, there are almost no networks set up that would prevent this from happening.
Right; I'm thinking of spending the extra $100 for the 3D model (Panasonic TCP50ST30 instead of TCP50S30); it has slightly better black and faster phosphors, which improve the moving resolution in 2D.
I have no intention of ever watching a 3D program on it.
Of course, I'll probably put off deciding until it's time to grouse about no-one wanting 4D....
I've done it by hand, but air-dry, so it's much the same thing.
They don't hold enough water to retain gunk; the two rinse phases (typical machine) are enough to sluice enough water through the upside down ones so you're left with clean water.
I just shook them around several times as they dried to rearrange which ones were upside down. If you're not in a big rush, that's good enough.
(I do the same thing with stuff that tips over in the dishwasher; maybe a quick rinse with hot water in case there's some detergent left, then just stick it in the drying rack with the hand washed stuff.)
Commodore wasn't above crippling the I/O on the C64 to avoid cutting in to the business market for the PET and CBM machines. (Those IEEE-488 parallel bus drives were FAST... most of them had two CPUs and 4-8K of RAM. The 1541 had only one CPU.)
There was a synchronous serial shifter on the C64's CIA chips (precursor to multi-IO chips). But there was something wrong with the hardware, so they had to bit-bang the serial I/O in software instead. Of course, it was their own hardware with the flaw: They'd bought MOS Technologies by then (which lives on as an EPA Superfund site, I believe).
Something similar was dumb on the Amiga. They finally had a true asynchronous UART for the RS-232 interface. But, the hardware handshake lines were done by software... which really fell apart above 19,200 bps.
If you limited yourself to the ROM KERNAL[sic] calls common to the PET, CBM and C64, you could actually write machine code that would run on all 3 series. BASIC code was, if you stuck with the C64 and PET 2001's 2.0 version, even easier to port.
So, one of the great things about Commodore was, we learned how to cope with mistakes....
The current expiry is listed in the WHOIS data for a zone. There should be a set of 3 dates: created, updated, and expires.
As for downtime and bouncing: you need to have your new nameservice in operation before the registration is changed. If you are not using GoDaddy, then this is easy, your nameservice doesn't need to change at all.
Otherwise, you should be able to set up the zone data at the new provider before the registration is transferred to it. Even if you do it in a single transaction, the registration transfer will usually take longer than it takes to populate the new nameserver with your data. (The former requires communication with GoDaddy and the global root servers, the latter is done entirely on the provider's equipment.)
The problem with using "bandwidth", which is the instantaneous use of spectrum (so, like a speed: Mb/s), to mean "data transfer" (Mb) is that it confuses the issue.
We don't want infinite bandwidth. We expect to pay tiered prices based on the bandwidth we purchase: 1 Mb/s really cheap, 5 Mb/s cheap, 10 Mb/s reasonable, 25 Mb/s pricey, and 50 Mb/s spendy.
Once we're done buying bandwidth, we don't expect to have limited data transfer. (DSL lines are always modulated, even when no data is transmitted, so the power argument is pointless--except as a function of bandwidth, not transfer.)
Especially if that limiting is not tied in to congestion management. Congestion management would be bandwidth-limiting and not transfer limit, anyway: we don't have enough backhaul for everyone to use their 50 Mb/s service at 8 PM, so you get effectively 10 Mb/s. But at 10 PM, the speed comes back.
Transfer limits will make sure everyone only uses the 'net when they really need/want it--which will mean peak times. They won't defer to off-peak, this isn't the dishwasher or something that can run at 4 AM. If you want to watch YouTube, you don't want to wait overnight while it downloads, then watch after dinner the next night. (I remember having to do that with a 1200 bps modem. And that was for pictures, not video.)
Yes, please! I've got a shovel, where should I dig the trench on my property?
If that's impractical--which it is--I'll settle for at least regulator recognition of the massive conflict-of-interest created by an Internet provider who also owns content companies.
As someone who lives in Toronto new the sewage treatment plant...
The waste water does go back into the lake. They take some stuff out of it, but that's... uh... the stuff that makes it sewage. Heat sunk into the water by the chillers is allowed to remain.
Ten years ago you could count on maybe 42 MB/s from that 7200 RPM hard disk--top of the line, premium device. Would have been, what, in the $250 for 80GB range?
Today, you can easily get 145 MB/s from a 7200 RPM hard drive--near bottom of the range, commodity price. But--prior to the floods--it would run you $120 for 2TB. (Heck, I just run the 5900 RPM units, they're plenty fast enough.)
High RPM drives don't actually give you much higher sustained read speeds--there's less data per rotation. Their random access performance may be better--but I find this year's 7200 RPM drive beats last year's 15,000 RPM drive easily.
And I can buy a whole, whole, whole lot of 7200 RPM units, plus RAM for cache, save a bunch on power, and wind up with more storage for the department compared to the 15,000s. And spares are easier to source.
But we do love our new SAS SSDs. They do random I/O like it was going out of style. Sustained rates in the 450 MB/s range.
So, most of us use 7200 RPM drives because we need to store lots of stuff. Then we can add SSDs to handle highly random workloads.
I've never found the "microwaves make the water molecules jiggle" explanation.
As an Electrical Engineer, I've found "plane wave propagating in a lossy medium results in heating within that medium" to be a much more compelling explanation.
And, of course, as the thermal energy of water--or any matter--increases, the motion of the molecules increases. So "microwaves make the water molecules jiggle" sure, but they do it by raising the water's temperature--not the jiggling causing the raised temperature.
And as soon as you even suggest "soft" mounts, the people who have been to Sun Brainwash Camp start freaking out. "No," they scream, "soft mounts cause data corruption!"
Apparently, in their world, no program ever checks the return code from a system call. And, also in their world, NFS servers reboot often and without notice--hard mounts don't protect data that the client hasn't sent, after all, they only protect against server reboots (but not failures).
If we have an NFS server go down, I want stuff to crash. We have to validate all the files that were in-flight at the time of the crash anyway. I've seen enough files grow runs of all-zero blocks after an NFS server crash with hard mounts to know that isn't guaranteed safety.
(Oh, BTW, the Sun people love "sync" mounts, too: you can't even disable it in the Sun server daemons. But it has a massively negative effect on performance. There are people that just insist on optimizing for the rare events. And yet, it's nearly impossible to fault out to a new server with NFS hard mounts.)
Slashdot Mirror
But Windows Phone has no excuse for being late to the party.
WinCE displaced PalmOS, to the extent that most of the Palm-brand phones had WinCE on them. Microsoft is NOT new to the smartphone market--they were there when it got started, before we were even sure we were going to call them smartphones.
Microsoft is not like Apple or Google; both of whom brought phone OSes to market when they had never produced a phone OS before. Apple had experience with Newton, ages ago, but all Google had was the ability to look for things.
That's part of why we're not cutting Microsoft any slack.
The other part is, all the people who said it was unacceptable that the iPhone didn't do X when version 1 or 2 were on the market means that Microsoft should ALREADY KNOW the system MUST do X. They didn't need to release "what they've got so far" to find out what customers really want, they can see what the market has already done.
And Microsoft is huge and has gobs of money; why SHOULD we cut them any slack? This isn't the clever little Silicon Valley start-up upstart taking on the Man. This is the Man.
15/8 and 16/8 may be adjacent, but you can't make a /7 out of them. You're stuck with two /8s. You'd need 14/8 and 15/8 or 16/8 and 17/8 to make 14/7 or 16/7, respectively.
So the value is only in the number of addresses, not in the "adjacency".
Especially since 15 is all-bits-clear in the high nybble and 16 has the lowest bit set in the high nybble; you can't combine them into anything smaller than a /3. (If I'm counting on my fingers right.)
It's all about the bitmask.
If you've got a table saw, and have the older version, IVAR shelving is available in any width narrower than what is available in-store.
(The "old version" had rabbets cut in the wood with metal L-brackets to hang on the shelf pins. The "new version" has plastic things wedged in to a saw-kerf cut into each shelf end. The "new version" is more secure--the shelves click into place. But the "old version" is far more saw-and-router friendly.)
IBM, at least at their Toronto HQ facilities, even goes so far as to have separate "visitor" and "employee" cafeterias. The "visitor" one is outside the badge-secured area, and adjacent to the training centre.
The "employee" one is inside the secure zone. The food was pretty good, too... back when "Java 1.1" was cool, anyway.
Can't say the same for the new Lab facility on Warden... about the food quality. The caf is in the secure zone. Even the Tim Horton's is in the secure zone.
The GPL does not require you send changes back to the original developer.
The GPL requires you give source code to the people you give binaries to.
So you don't need to make any effort to contact the original developer in maintaining your fork. As long as your downstream gets the source, you're good.
Since the GPL also requires that you permit your downstream receivers to make modifications and distribute copies, the GPL cannot PREVENT the original developer from getting your changes. But that's not the same as REQUIRING you to send them upstream.
There are licenses that require your changes go upstream and/or get vetted by the upstream provider. Or even assign copyright to the upstream--the original Netscape Public License was like that, I believe.
The GPL, though, is all about people who RECEIVE the code. It isn't about people who PROVIDE the code.
The reason why you get Java from Apple?
'Cause Sun wasn't going to bother. Oracle is even less likely to be interested; Java is probably the only free download from Sun left, they are unlikely to add to the list. It was even more confusing on Mac OS Classic: Macintosh Runtime for Java had a completely orthogonal numbering system to Sun's JRE and JDK.
Sun's idea of "Write Once, Run Anywhere" should have "we feel like letting you" appended to it. Sun also didn't bother with an OS/2 version, an AIX version, a zSeries version or an iSeries version: IBM had to make their own. Heck, it wasn't until it looked like Blackdown JDK looked like it might actually work that Sun cared enough to maintain a Linux port. Even then, Blackdown supported more CPUs than Sun did, so until OpenJDK it continued on.
Then there's the whole field-of-use mess in the certification kit....
(I'm with you on the "safe apps" thing; I've got a script that clears that option, along with other personal biases, when I set up a new account.)
My driver's ed through-the-high-school classes covered all of this. Shift-to-neutral/declutch, e-brake/park-brake, and ignition-off. And the difference between "off" and "lock".
And that was in 1986, when there were still those silly far-left-pedal parking brakes around, that you can only release by leaning under the steering wheel and pulling a handle.
Shift-to-neutral/declutch was also heavily covered in skid control and black ice reactions.
They also covered the basic bit about "machines can be repaired or replaced, people can't."
Maybe more people need to take driver's ed, and pay attention when doing it?
Maybe there should be refresher courses? Many places have your vehicle inspected regularly, how about the driver?
I've seen masses of cabling issues that won't be reported by SMART, either.
The symptom, at least on Linux, is logs full of stuff like this:
kernel: ata12.01: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6
kernel: ata12.01: irq_stat 0x03060002, device error via SDB FIS
kernel: ata12.01: failed command: READ FPDMA QUEUED
kernel: ata12.01: cmd 60/40:00:92:6d:06/00:00:07:00:00/40 tag 0 ncq 32768 in
kernel: res 41/84:40:92:6d:06/00:00:07:00:00/00 Emask 0x410 (ATA bus error)
kernel: ata12.01: status: { DRDY ERR }
kernel: ata12.01: error: { ICRC ABRT }
That one is actually a dodgy port replicator board--the drives never see the garbled command packets, so their CRC error count never moves.
A consistent comm problem to the drive itself should result in at least some of the SMART counters moving, but they will NOT fail out the drive because there is no reliable evidence it is a drive problem. For those, re-seat the SATA/SAS cables, reseat the HBA in the PCI/PCIe slot, replace the SATA/SAS cables, replace the HBA, replace the drive. In about that order--there's a lot of crappy cables on the market, and quality independent of retail price.
(I'd recommend having a test rig with a couple of different HBAs so you can determine which part is giving you grief; motherboard and a cheap PCI card is usually enough variety.)
Maybe I've got a lot of weird DVDs, but I don't batch transcode anything from optical media, I only batch rip. So, from my perspective, Blu-Ray just takes longer--it's the same process. (Except I have to use AnyDVD HD for the Blu-Ray, so I actually have to click things in the Windows VM. DVDs are ripped on media load and ejected when done.)
When I do have a bunch of DVDs or BDs that can be batch transcoded--say a season of a TV show--I do that from the ripped files, not from the original media. But I've got so many where the "right" audio track isn't obvious, even right "right" title isn't obvious, so I hand-set Handbrake for nearly everything.
Heh; I build a lot of software from scratch for developers, so that includes both Emacs and VI(mproved).
Last round, when I found out Vim was now a larger download than XEmacs, felt just so... wrong. Fortunately, that was because XEmacs has most of the packages out-of-line with the main download, so it was really bigger in the end, the Universe was still OK.
(And I switched back to GNUmacs 'cause XEmacs progress seems to be stalled.)
You say SATA drives don't have bent pin issues....
But I handed a box to UPS this morning that contained a NewEgg RMA ticket for exactly that issue. I'd never seen it before, in handing close to 200 SATA and SAS drives. The plastic in the power part of the connector was actually out of place, and the little metal fingers had not been laminated to it correctly.
So, it's possible. But, compared to always having a pair of needle-nose pliers around for unbending IDE connector pins (and 50-pin SCSI), wow is it rare.
Mind you, this was on a brand-new-out-of-the-anti-static drive, so I didn't even have a chance to even run the SMART extended offline test....
If you're going to do that, see if you can make sure that when the guy doing it still sees the original image--it's all his site visitors that get the shock pic. I mean alternate pic. Implementation left as an exercise and all that.
If you run shifts, you can do this with local labour. And if you combine it with work-from-home or "hot desking", you don't need multiple buildings, either. Having to pay premium rate for shift workers could be made up in the facilities budget.
And how old is old? I know several people still using the black & white Garmin StreetPilot... you can't get map updates for it, it's that old--circa 1998.
My Zumo is pushing 5 years old; it does all I want, and updates are still available... though now I have to pick and choose what regions to load. So I'm not replacing it.
Serial loggers might be even older, as they have no processing except the satellite receiver, so there's no rush to update them. Any chartplotting is done by the computer they're attached to.
It's possible for managed switches to lock a port to a particular MAC (or a list of them). That's done at the Ethernet layer.
Layer 3 switches can look at the IP address ('cause they're layer 3) and make sure that Approved IP Addresses are associated with Approved MAC Addresses only.
Which is still useless for all but the casual wrong-plug fault, because anyone actually breaking your network security can emit any MAC address they want. So they just need to intercept a couple of frames before switching to their gear.
You'd actually need Ethernet-level encryption or something to stop that. Or all your real connections are in VPN tunnels, and the regular LAN fabric doesn't route to anything except the tunnel server.
In other words, there are almost no networks set up that would prevent this from happening.
Right; I'm thinking of spending the extra $100 for the 3D model (Panasonic TCP50ST30 instead of TCP50S30); it has slightly better black and faster phosphors, which improve the moving resolution in 2D.
I have no intention of ever watching a 3D program on it.
Of course, I'll probably put off deciding until it's time to grouse about no-one wanting 4D....
I've done it by hand, but air-dry, so it's much the same thing.
They don't hold enough water to retain gunk; the two rinse phases (typical machine) are enough to sluice enough water through the upside down ones so you're left with clean water.
I just shook them around several times as they dried to rearrange which ones were upside down. If you're not in a big rush, that's good enough.
(I do the same thing with stuff that tips over in the dishwasher; maybe a quick rinse with hot water in case there's some detergent left, then just stick it in the drying rack with the hand washed stuff.)
Commodore wasn't above crippling the I/O on the C64 to avoid cutting in to the business market for the PET and CBM machines. (Those IEEE-488 parallel bus drives were FAST... most of them had two CPUs and 4-8K of RAM. The 1541 had only one CPU.)
There was a synchronous serial shifter on the C64's CIA chips (precursor to multi-IO chips). But there was something wrong with the hardware, so they had to bit-bang the serial I/O in software instead. Of course, it was their own hardware with the flaw: They'd bought MOS Technologies by then (which lives on as an EPA Superfund site, I believe).
Something similar was dumb on the Amiga. They finally had a true asynchronous UART for the RS-232 interface. But, the hardware handshake lines were done by software... which really fell apart above 19,200 bps.
If you limited yourself to the ROM KERNAL[sic] calls common to the PET, CBM and C64, you could actually write machine code that would run on all 3 series. BASIC code was, if you stuck with the C64 and PET 2001's 2.0 version, even easier to port.
So, one of the great things about Commodore was, we learned how to cope with mistakes....
The current expiry is listed in the WHOIS data for a zone. There should be a set of 3 dates: created, updated, and expires.
As for downtime and bouncing: you need to have your new nameservice in operation before the registration is changed. If you are not using GoDaddy, then this is easy, your nameservice doesn't need to change at all.
Otherwise, you should be able to set up the zone data at the new provider before the registration is transferred to it. Even if you do it in a single transaction, the registration transfer will usually take longer than it takes to populate the new nameserver with your data. (The former requires communication with GoDaddy and the global root servers, the latter is done entirely on the provider's equipment.)
The problem with using "bandwidth", which is the instantaneous use of spectrum (so, like a speed: Mb/s), to mean "data transfer" (Mb) is that it confuses the issue.
We don't want infinite bandwidth. We expect to pay tiered prices based on the bandwidth we purchase: 1 Mb/s really cheap, 5 Mb/s cheap, 10 Mb/s reasonable, 25 Mb/s pricey, and 50 Mb/s spendy.
Once we're done buying bandwidth, we don't expect to have limited data transfer. (DSL lines are always modulated, even when no data is transmitted, so the power argument is pointless--except as a function of bandwidth, not transfer.)
Especially if that limiting is not tied in to congestion management. Congestion management would be bandwidth-limiting and not transfer limit, anyway: we don't have enough backhaul for everyone to use their 50 Mb/s service at 8 PM, so you get effectively 10 Mb/s. But at 10 PM, the speed comes back.
Transfer limits will make sure everyone only uses the 'net when they really need/want it--which will mean peak times. They won't defer to off-peak, this isn't the dishwasher or something that can run at 4 AM. If you want to watch YouTube, you don't want to wait overnight while it downloads, then watch after dinner the next night. (I remember having to do that with a 1200 bps modem. And that was for pictures, not video.)
Yes, please! I've got a shovel, where should I dig the trench on my property?
If that's impractical--which it is--I'll settle for at least regulator recognition of the massive conflict-of-interest created by an Internet provider who also owns content companies.
As someone who lives in Toronto new the sewage treatment plant...
The waste water does go back into the lake. They take some stuff out of it, but that's... uh... the stuff that makes it sewage. Heat sunk into the water by the chillers is allowed to remain.
Ten years ago you could count on maybe 42 MB/s from that 7200 RPM hard disk--top of the line, premium device. Would have been, what, in the $250 for 80GB range?
Today, you can easily get 145 MB/s from a 7200 RPM hard drive--near bottom of the range, commodity price. But--prior to the floods--it would run you $120 for 2TB. (Heck, I just run the 5900 RPM units, they're plenty fast enough.)
High RPM drives don't actually give you much higher sustained read speeds--there's less data per rotation. Their random access performance may be better--but I find this year's 7200 RPM drive beats last year's 15,000 RPM drive easily.
And I can buy a whole, whole, whole lot of 7200 RPM units, plus RAM for cache, save a bunch on power, and wind up with more storage for the department compared to the 15,000s. And spares are easier to source.
But we do love our new SAS SSDs. They do random I/O like it was going out of style. Sustained rates in the 450 MB/s range.
So, most of us use 7200 RPM drives because we need to store lots of stuff. Then we can add SSDs to handle highly random workloads.
I've never found the "microwaves make the water molecules jiggle" explanation.
As an Electrical Engineer, I've found "plane wave propagating in a lossy medium results in heating within that medium" to be a much more compelling explanation.
And, of course, as the thermal energy of water--or any matter--increases, the motion of the molecules increases. So "microwaves make the water molecules jiggle" sure, but they do it by raising the water's temperature--not the jiggling causing the raised temperature.
And as soon as you even suggest "soft" mounts, the people who have been to Sun Brainwash Camp start freaking out. "No," they scream, "soft mounts cause data corruption!"
Apparently, in their world, no program ever checks the return code from a system call. And, also in their world, NFS servers reboot often and without notice--hard mounts don't protect data that the client hasn't sent, after all, they only protect against server reboots (but not failures).
If we have an NFS server go down, I want stuff to crash. We have to validate all the files that were in-flight at the time of the crash anyway. I've seen enough files grow runs of all-zero blocks after an NFS server crash with hard mounts to know that isn't guaranteed safety.
(Oh, BTW, the Sun people love "sync" mounts, too: you can't even disable it in the Sun server daemons. But it has a massively negative effect on performance. There are people that just insist on optimizing for the rare events. And yet, it's nearly impossible to fault out to a new server with NFS hard mounts.)