Don't take Tesla's word that he had his hands off the wheel; he may have had them resting lightly on the wheel. They use a pressure sensor. I've got a Tesla Model X, and have been nagged many times, because my touch is a bit too light for it to detect.
This was an Apple II clone that Apple sued out of existence. They have one in the computer history museum.
The nice think about the Franklin was that it came with 64K by default rather than 48K, and had an arguably nicer keyboard than the Apple II. And it was cheap enough that we could afford a disk drive (Rana?) and a color monitor too.
I am a HUGE fan of the Forza series. But I hate playing racing games with a joystick, and I don't have the space for a real steering wheel & pedals. So the XBox 360's "Wireless Speed Wheel" was perfect for me.
Microsoft lost a customer when they released XBox One without support for XBox 360 controllers and no replacement for the 360's wireless speed wheel. Leaving behind the XBox360 controllers was a blatant money grab, but if they'd have come out with a replacement for the WSW, I'd probably have paid full price & bought the box on launch day. As it is, I still play the original Forza on my 360. And when I needed a next-gen console, there was no reason not to buy the PS4.
I do 10GbE drivers, and the previous generation of tbolt did not really offer 10Gb/s of usable bandwidth to PCIe devices, it was more like 8Gb/s:
If you recall, tbolt muxes PCIe and Display Port. On the PCIe side, the thunderbolt bridge passed 2 lanes of Gen2 PCIe through to devices. Since Gen2 is "5GT/s" per lane, you'd think you'd have 10Gb/s. But not really, as "10Gb/s" does not take into account PCIe overhead, which can be about 20% of the data transfer rate. So on the original "10Gb/s" thunderbolt, you were lucky to get 7Gb/s transfer rate from 10GbE NIC, once you also add in network protocol overheads.
Having a bus-constrained NIC leads to all sorts of weird problems when receiving data.. With flow control disabled in combination with bursty transfers, you often see far less than the 7Gb/s peak, as TCP hunts around to find the constraint and recover from frequent packet loss events.
It sounds like they've built the new part from 2 lanes of Gen3 PCIe, which should be good for ~16Gb/s of usable bandwidth. This is a very welcome change, as 16Gb/s should be enough for a single-port 10GbE NIC running at full speed, and a disk controller talking to a fast SSD or an external RAID array that can deliver ~750MB/s (bytes) of I.O.
Just don't try to use a bonded 2 port 10GbE NIC, or you're back at the bandwidth constrained problem.
In ~2007, after the birth of my first child I had very little time. So I thought to myself "I don't have time to keep up with maintaining a Linux desktop" and I bought a nice iMac, and moved from Linux to Mac.
The experience I had was that everything that was a royal PITA on nix at the time (web browsing, audio, skype, video, photo management, suspend/resume, printing) "just worked" on the Mac. Hurray!
But the problem I had was that the unixy stuff stuff I needed to do my job (X11 across multiple monitors, emacs, serial console control, local command-line tools, etc) did not just work, and was more a PITA to maintain on MacOSX than the flashy stuff was to maintain on Linux. The final straw was when I upgraded to Leopard, and multiple monitor support in X11 was totally hosed at the time of the initial release.
In the end, I wound up giving the iMac to my in-laws after about 9 months, and building another whitebox for 1/2 the price of the iMac, and I have been happy ever after. That 2007 whitebox is now running Kbuntu, and is my 6 year old's PC (while I've built myself a newer one..)
Back in the day, I did FreeBSD drivers / platform support for DEC Alphas. I would occasionally get hardware and/or docs under NDA from DEC. The NDA basically said I could write open source drivers, but I could not share the documentation. This is how a lot of Linux / BSD hardware support still works.
Sorry, I have an x86/amd64 + DEC alpha historical bias, and don't really know a lot about ARM.
As a user, having the "southbridge" stuff integrated onto the CPU card means that you're essentially getting a whole new motherboard when you replace this CPU card. I always view a whole new motherboard as a whole new set of problems, in terms of potentially buggy hardware and drivers. At the very least, it is seems problematic in terms of having to upgrade your kernel to support the latest stuff. In the x86 world, as long as the vendor hasn't changed the CPU socket, you can generally drop in a new CPU with just a BIOS upgrade, and you don't need to worry that you might get a whole new set of buggy peripherial chips.. I've often done that with AMD CPUs.
Maybe a dumb question, but why do you put the core peripherals (USB, Sata, ethernet, VGA) on the CPU card, each requiring these pcmcia pins. Why not use a PCIe interface, and leave the peripherals to the tablet / laptop / motherboard / tv / etc vendor? It seems like this would allow for greater differentiation between "system" vendors, and would require less integration efforts from CPU vendors.
Maybe I'm just old and grumpy, but all of this fancy new crap that obfuscates the boot process really ticks me off. If a machine has trouble booting, the last thing I want is some fancy gui with a pretty stop-watch ticking endlessly at me, rather than seeing "NFS server foo not responding" in black and white. So now rather than having just the actual problem to fix, I've got to use a second machine to figure out how to shut off the god damned gui (or how to get into the grub menu) before I can even get a hint what the actual problem might be.
If you really want to upgrade, you should be able to "hackintosh" your mac. I did this to test 64bit drivers on a macpro1,1. It worked well enough for what I needed it (running 64b kernel), however, I would not use this setup for a daily use machine, as the video card acceleration went away, the power usage increased, etc. I'd keep a separate partition for daily use, and only boot into the "hackintosh" 10.8 setup when you need to work on your project.
If this package is indeed capped, it is just as stupid and sad as the 5GB caps on 4G wireless data plans.
If my sleepy math is right, you reach the old 250GB cap in a little less than 2 hours and the rumored new 300GB cap in a little over 2 hours. If they stick with the proposed 10$ per 50GB overage charge, you can enjoy paying about $25/hr to use your 305Mb/s connection after the first 2 hours.
I've been doing the same thing for years with a similar Macpro1,1 that I use as a dev box for 10GbE ethernet drivers. When 10.6 previews offered a 64b kernel, I was majorly pissed that I had a less than 2 year old $3000 machine that I could not use to test my drivers in 64-bit mode. So I did what you did & turned my MacPro into a hackintosh.
Yes. It is awesome. I got mine 2 months ago, and could not be happier. My wife has my old Nexus One.
The one thing you need to be a aware of is that this phone is HUGE!. Make sure to get a case that has some kind of belt-clip built in, as the phone + case will not fit comfortably in any stand-alone phone holster or most pants/shirt pockets. I'm probably going to have to just throw away the case I bought for it, or try to jury-rig some kind of belt clip into it.
I've run X11 since 1989. I started with TWM, then CTWM, then KDE.
KDE2. was great, KDE3 was fine, KDE4 is bloated. I don't care about eye candy. I don't care about UI guidelines thought up by some hipsters. I don't want widgets. I don't want spinning 3d cubes when I change workspaces. All I want is a desktop env. that works. What I care about:
- The ability to customize window the window manager enough to map Alt-mouse-1 to move, Alt-mouse-2 to resize and Alt-mouse-3 to iconify. These are hardwired in my brain after 23 years.
- The ability for the icon manager to work vertically, so I can stick it on the side of my workspace, rather than the top or bottom. Today's stupid widescreen monitors are too cramped vertically, and I begrudge any pixels taken away from my applications
- multiple desktops
- multiple monitor support
- no fancy GL stuff that screws up VLC or mplayer playing hardware accelerated video.
That's it. That's all. I could give a flying you now what about file managers, widgets, etc.
When my then 4yr old son "moved up" to a new classroom in the co-op daycare we used at the time, I was pleasantly surprised to see they had a real workbench at child height with hammers, nails, a saw, screwdrivers, etc as one of their play "centers". My son enjoyed this, and was never injured.
I'm still surprised they were able to do that & not get sued by some moron. This was 2 years ago, though so they may have changed things..
Nvidia's "half baked" support is actually better, since their drivers are backported to older stable distros. Stuff that requires kernel or bleeding-edge X.org is a royal pain to make work on a box running an older distro.
+1 I had an ATI in my last Linux desktop. Never again.
The proprietary fglrx drivers tend to have weird bugs and as you say, they drop chips that are old enough to have decent support. On the flip-side, the open-source radeon drivers tend to require various bleeding edge bits and pieces to work correctly, so they are nearly impossible to run on stable distros, like an Ubuntu LTS or a RHEL.
Nividia's proprietary drivers just work, once you finally figure out how to blacklist nouveau hard enough that it doesn't get loaded via the initrd. Plus they support VDPAU for projects like MythTV and XBMC.
I do NIC drivers for pretty much all popular *nix OSes. Linux is, by far, the biggest PITA to develop for. Developing for a particular version of Linux is fine, but keeping a driver compatible with all commonly used variants is murder.
Almost every other OS, even open source OSes like FreeBSD, maintain a stable binary device driver interface (DDI). That means that a module compiled for one kernel will work on any other in that major release series (and, depending on the OS, in future releases). For example, my company's NIC drivers compiled for S10 work just fine on both OpenSolaris and Solaris11.
Linux does not do this. Heck, they don't even maintain a stable DDI between the same kernel version compiled with different options. Worse, they change their APIs for no sane reason, adding and removing function arguments, struct elements, etc, just because somebody looking for name recognition wants to "clean up" something.
So if Linux had some kind of stable DDI like,. well, everybody else, a lot of these problems would just go away.
Before somebody whines "Well, just get your driver into the kernel" --- it is. But our customers tend to want the latest version *without* updating to the bleeding edge 3.x kernels. Which means that we have to maintain compile shims all the way back to 2.6.9 (RHEL4). The last I checked, the compile shims alone were ~2000 lines of code, which is nearly the size of the *ENTIRE* driver on some other OSes.
I use ZFS on Ubuntu 11.10 in "production" for my main workstation and fileserver with a 3x3TB raidz pool with an L2 ARC. I/O is blindingly fast, and it has been rock solid. It serves about 10 machines, and feels an order of magnitude faster than the md/lvm based xfs array it replaced.
I write 10GbE drivers for Linux, MacOSX, FreeBSD and Solaris. I make heavy use of Dtrace for both debugging and performance analysis. I feel naked without Dtrace, and I've used the linux dtrace a few times for debugging. Unfortunately, I've never had dtrace run on linux for more than a few minutes without crashing a machine. This is not necessarily bad, and often just a few seconds is all I need. But I would never run linux Dtrace on any production machine, whereas I use it all the time under Solaris / FreeBSD and MacOSX and often have customers run Dtrace probes on those OSes to diagnose issues.
There are far too many BD audio formats already, AC3, DTS, DCA, DTS-master, etc, etc, etc. With a decent ($3000) surround-sound HT setup and 40 year old ears, I cannot tell much difference between any of them. I wish the BD producers focused more on doing better video transfers. I'd much rather they use the space wasted by these new audio formats on higher bitrate video (and the same goes for the useless, space-wasting extra features).
As far as I'm concerned, the only thing these extra audio formats do is make ripping the files & playing them back via an embedded streaming device more complex. My oldest device cannot handle any of these new fancy formats beyond AC3, so I need to remux newer BDs to add an AC3 sound track to the MKV.
Besides spotty hardware supprt, AFAIK it is also missing VDPAU (HD video decoding) support, which is the main reason a lot of HTPC types use Nvidia cards in their linux machines. It is also fairly hard to remove. I think it took me 1/2 hour of re-booting before I finally purged nouveau from my system to clear the way so that the Nvidia driver could attach.
As a Linux (and other *nix) driver guy, I have tons of respect for how Nvidia deals with the constant, gratuitous changes in the Linux kernel APIs.
The telco (unless it is third world) will have massive diesel generators
I guess suburban USA counts as "3rd world" then.
I live roughly 100 miles from Washington DC just outside of Richmond, VA. Our power was restored a few days after hurricane Irene last summer. After our power was restored, our internet (and voip phone) was still out. After a while, I realized that it would come on for a few hours, then go off.
After meeting some neighbors (we'd just moved in 2 weeks before the storm and knew nobody in town), we finally realized that the telcom's local headend was located across a major highway in an area that did not yet have power. The times when we had power were when our neighbors, at their own expense, filled up the tanks on Comcast's diesel generator.
Slashdot Mirror
Don't take Tesla's word that he had his hands off the wheel; he may have had them resting lightly on the wheel. They use a pressure sensor. I've got a Tesla Model X, and have been nagged many times, because my touch is a bit too light for it to detect.
This was an Apple II clone that Apple sued out of existence. They have one in the computer history museum.
The nice think about the Franklin was that it came with 64K by default rather than 48K, and had an arguably nicer keyboard than the Apple II. And it was cheap enough that we could afford a disk drive (Rana?) and a color monitor too.
I am a HUGE fan of the Forza series. But I hate playing racing games with a joystick, and I don't have the space for a real steering wheel & pedals. So the XBox 360's "Wireless Speed Wheel" was perfect for me.
Microsoft lost a customer when they released XBox One without support for XBox 360 controllers and no replacement for the 360's wireless speed wheel. Leaving behind the XBox360 controllers was a blatant money grab, but if they'd have come out with a replacement for the WSW, I'd probably have paid full price & bought the box on launch day. As it is, I still play the original Forza on my 360. And when I needed a next-gen console, there was no reason not to buy the PS4.
I built my current computer a bit more than a year ago. It runs FreeBSD-10 stable. The hardware is:
- Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz (8 cores, 16 threads)
- Supermicro X10SRA motherboard
- Phillips BDM4065UC 40" 4K monitor
- Nvidia GeForce GTX 750
- 32 GB ECC 2133MHz DDR4
- 4x Seagate 5TB enterprise disks
- 1x Samsung 850 Pro 250GB
I'm running ZFS, and the SSD acts as an L2 ARC
This is not true. 4K is supported on the Nvidia Shield, and I think it is supported on the latest 4K Amazon TV box.
I do 10GbE drivers, and the previous generation of tbolt did not really offer 10Gb/s of usable bandwidth to PCIe devices, it was more like 8Gb/s:
If you recall, tbolt muxes PCIe and Display Port. On the PCIe side, the thunderbolt bridge passed 2 lanes of Gen2 PCIe through to devices. Since Gen2 is "5GT/s" per lane, you'd think you'd have 10Gb/s. But not really, as "10Gb/s" does not take into account PCIe overhead, which can be about 20% of the data transfer rate. So on the original "10Gb/s" thunderbolt, you were lucky to get 7Gb/s transfer rate from 10GbE NIC, once you also add in network protocol overheads.
Having a bus-constrained NIC leads to all sorts of weird problems when receiving data.. With flow control disabled in combination with bursty transfers, you often see far less than the 7Gb/s peak, as TCP hunts around to find the constraint and recover from frequent packet loss events.
It sounds like they've built the new part from 2 lanes of Gen3 PCIe, which should be good for ~16Gb/s of usable bandwidth. This is a very welcome change, as 16Gb/s should be enough for a single-port 10GbE NIC running at full speed, and a disk controller talking to a fast SSD or an external RAID array that can deliver ~750MB/s (bytes) of I.O.
Just don't try to use a bonded 2 port 10GbE NIC, or you're back at the bandwidth constrained problem.
SageTV was bought for the Google Fiber project. If you look at the videos of Google Fibre TV, it running SageTV v8.
Now, I just wish I lived in Kansas City, so that I could get Google Fiber TV. I really wish they'd have kept on selling SageTV.
In ~2007, after the birth of my first child I had very little time. So I thought to myself "I don't have time to keep up with maintaining a Linux desktop" and I bought a nice iMac, and moved from Linux to Mac.
The experience I had was that everything that was a royal PITA on nix at the time (web browsing, audio, skype, video, photo management, suspend/resume, printing) "just worked" on the Mac. Hurray!
But the problem I had was that the unixy stuff stuff I needed to do my job (X11 across multiple monitors, emacs, serial console control, local command-line tools, etc) did not just work, and was more a PITA to maintain on MacOSX than the flashy stuff was to maintain on Linux. The final straw was when I upgraded to Leopard, and multiple monitor support in X11 was totally hosed at the time of the initial release.
In the end, I wound up giving the iMac to my in-laws after about 9 months, and building another whitebox for 1/2 the price of the iMac, and I have been happy ever after. That 2007 whitebox is now running Kbuntu, and is my 6 year old's PC (while I've built myself a newer one..)
It is probably not a bad thing.
Back in the day, I did FreeBSD drivers / platform support for DEC Alphas. I would occasionally get hardware and/or docs under NDA from DEC. The NDA basically said I could write open source drivers, but I could not share the documentation. This is how a lot of Linux / BSD hardware support still works.
Sorry, I have an x86/amd64 + DEC alpha historical bias, and don't really know a lot about ARM.
As a user, having the "southbridge" stuff integrated onto the CPU card means that you're essentially getting a whole new motherboard when you replace this CPU card. I always view a whole new motherboard as a whole new set of problems, in terms of potentially buggy hardware and drivers. At the very least, it is seems problematic in terms of having to upgrade your kernel to support the latest stuff. In the x86 world, as long as the vendor hasn't changed the CPU socket, you can generally drop in a new CPU with just a BIOS upgrade, and you don't need to worry that you might get a whole new set of buggy peripherial chips.. I've often done that with AMD CPUs.
Maybe a dumb question, but why do you put the core peripherals (USB, Sata, ethernet, VGA) on the CPU card, each requiring these pcmcia pins. Why not use a PCIe interface, and leave the peripherals to the tablet / laptop / motherboard / tv / etc vendor? It seems like this would allow for greater differentiation between "system" vendors, and would require less integration efforts from CPU vendors.
Maybe I'm just old and grumpy, but all of this fancy new crap that obfuscates the boot process really ticks me off. If a machine has trouble booting, the last thing I want is some fancy gui with a pretty stop-watch ticking endlessly at me, rather than seeing "NFS server foo not responding" in black and white. So now rather than having just the actual problem to fix, I've got to use a second machine to figure out how to shut off the god damned gui (or how to get into the grub menu) before I can even get a hint what the actual problem might be.
Now get off my lawn.
If you really want to upgrade, you should be able to "hackintosh" your mac. I did this to test 64bit drivers on a macpro1,1. It worked well enough for what I needed it (running 64b kernel), however, I would not use this setup for a daily use machine, as the video card acceleration went away, the power usage increased, etc. I'd keep a separate partition for daily use, and only boot into the "hackintosh" 10.8 setup when you need to work on your project.
If this package is indeed capped, it is just as stupid and sad as the 5GB caps on 4G wireless data plans.
If my sleepy math is right, you reach the old 250GB cap in a little less than 2 hours and the rumored new 300GB cap in a little over 2 hours. If they stick with the proposed 10$ per 50GB overage charge, you can enjoy paying about $25/hr to use your 305Mb/s connection after the first 2 hours.
MOD PARENT UP!
I've been doing the same thing for years with a similar Macpro1,1 that I use as a dev box for 10GbE ethernet drivers. When 10.6 previews offered a 64b kernel, I was majorly pissed that I had a less than 2 year old $3000 machine that I could not use to test my drivers in 64-bit mode. So I did what you did & turned my MacPro into a hackintosh.
Yes. It is awesome. I got mine 2 months ago, and could not be happier. My wife has my old Nexus One.
The one thing you need to be a aware of is that this phone is HUGE!. Make sure to get a case that has some kind of belt-clip built in, as the phone + case will not fit comfortably in any stand-alone phone holster or most pants/shirt pockets. I'm probably going to have to just throw away the case I bought for it, or try to jury-rig some kind of belt clip into it.
I've run X11 since 1989. I started with TWM, then CTWM, then KDE.
KDE2. was great, KDE3 was fine, KDE4 is bloated. I don't care about eye candy. I don't care about UI guidelines thought up by some hipsters. I don't want widgets. I don't want spinning 3d cubes when I change workspaces. All I want is a desktop env. that works. What I care about:
- The ability to customize window the window manager enough to map Alt-mouse-1 to move, Alt-mouse-2 to resize and Alt-mouse-3 to iconify. These are hardwired in my brain after 23 years.
- The ability for the icon manager to work vertically, so I can stick it on the side of my workspace, rather than the top or bottom. Today's stupid widescreen monitors are too cramped vertically, and I begrudge any pixels taken away from my applications
- multiple desktops
- multiple monitor support
- no fancy GL stuff that screws up VLC or mplayer playing hardware accelerated video.
That's it. That's all. I could give a flying you now what about file managers, widgets, etc.
When my then 4yr old son "moved up" to a new classroom in the co-op daycare we used at the time, I was pleasantly surprised to see they had a real workbench at child height with hammers, nails, a saw, screwdrivers, etc as one of their play "centers". My son enjoyed this, and was never injured.
I'm still surprised they were able to do that & not get sued by some moron. This was 2 years ago, though so they may have changed things..
Nvidia's "half baked" support is actually better, since their drivers are backported to older stable distros. Stuff that requires kernel or bleeding-edge X.org is a royal pain to make work on a box running an older distro.
+1 I had an ATI in my last Linux desktop. Never again.
The proprietary fglrx drivers tend to have weird bugs and as you say, they drop chips that are old enough to have decent support. On the flip-side, the open-source radeon drivers tend to require various bleeding edge bits and pieces to work correctly, so they are nearly impossible to run on stable distros, like an Ubuntu LTS or a RHEL.
Nividia's proprietary drivers just work, once you finally figure out how to blacklist nouveau hard enough that it doesn't get loaded via the initrd. Plus they support VDPAU for projects like MythTV and XBMC.
I do NIC drivers for pretty much all popular *nix OSes. Linux is, by far, the biggest PITA to develop for. Developing for a particular version of Linux is fine, but keeping a driver compatible with all commonly used variants is murder.
Almost every other OS, even open source OSes like FreeBSD, maintain a stable binary device driver interface (DDI). That means that a module compiled for one kernel will work on any other in that major release series (and, depending on the OS, in future releases). For example, my company's NIC drivers compiled for S10 work just fine on both OpenSolaris and Solaris11.
Linux does not do this. Heck, they don't even maintain a stable DDI between the same kernel version compiled with different options. Worse, they change their APIs for no sane reason, adding and removing function arguments, struct elements, etc, just because somebody looking for name recognition wants to "clean up" something.
So if Linux had some kind of stable DDI like,. well, everybody else, a lot of these problems would just go away.
Before somebody whines "Well, just get your driver into the kernel" --- it is. But our customers tend to want the latest version *without* updating to the bleeding edge 3.x kernels. Which means that we have to maintain compile shims all the way back to 2.6.9 (RHEL4). The last I checked, the compile shims alone were ~2000 lines of code, which is nearly the size of the *ENTIRE* driver on some other OSes.
I use ZFS on Ubuntu 11.10 in "production" for my main workstation and fileserver with a 3x3TB raidz pool with an L2 ARC. I/O is blindingly fast, and it has been rock solid. It serves about 10 machines, and feels an order of magnitude faster than the md/lvm based xfs array it replaced.
I write 10GbE drivers for Linux, MacOSX, FreeBSD and Solaris. I make heavy use of Dtrace for both debugging and performance analysis. I feel naked without Dtrace, and I've used the linux dtrace a few times for debugging. Unfortunately, I've never had dtrace run on linux for more than a few minutes without crashing a machine. This is not necessarily bad, and often just a few seconds is all I need. But I would never run linux Dtrace on any production machine, whereas I use it all the time under Solaris / FreeBSD and MacOSX and often have customers run Dtrace probes on those OSes to diagnose issues.
There are far too many BD audio formats already, AC3, DTS, DCA, DTS-master, etc, etc, etc. With a decent ($3000) surround-sound HT setup and 40 year old ears, I cannot tell much difference between any of them. I wish the BD producers focused more on doing better video transfers. I'd much rather they use the space wasted by these new audio formats on higher bitrate video (and the same goes for the useless, space-wasting extra features).
As far as I'm concerned, the only thing these extra audio formats do is make ripping the files & playing them back via an embedded streaming device more complex. My oldest device cannot handle any of these new fancy formats beyond AC3, so I need to remux newer BDs to add an AC3 sound track to the MKV.
Sigh
Besides spotty hardware supprt, AFAIK it is also missing VDPAU (HD video decoding) support, which is the main reason a lot of HTPC types use Nvidia cards in their linux machines. It is also fairly hard to remove. I think it took me 1/2 hour of re-booting before I finally purged nouveau from my system to clear the way so that the Nvidia driver could attach.
As a Linux (and other *nix) driver guy, I have tons of respect for how Nvidia deals with the constant, gratuitous changes in the Linux kernel APIs.
I guess suburban USA counts as "3rd world" then.
I live roughly 100 miles from Washington DC just outside of Richmond, VA. Our power was restored a few days after hurricane Irene last summer. After our power was restored, our internet (and voip phone) was still out. After a while, I realized that it would come on for a few hours, then go off.
After meeting some neighbors (we'd just moved in 2 weeks before the storm and knew nobody in town), we finally realized that the telcom's local headend was located across a major highway in an area that did not yet have power. The times when we had power were when our neighbors, at their own expense, filled up the tanks on Comcast's diesel generator.