It would certainly be possible to do something like this in software...specify a certain USB slot as "storage-only" and raise big warnings if it tries to do anything else.
While there may always be a desire for manual override, you could conceivably program a lot of this sort of thing. You could have rules like "when someone detected entering ensuite bathroom, if bedroom lights are out and it's after sunset then slowly ramp up lights to 20% else bring up lights to 100%"
In many pieces of software the algorithms are obvious and straightforward, it's just tedius to implement them and make them interface vwith the rest of the system. I would say it's actually rare that the algorithms are particularly innovative.
For others ZFS will remain better, but you better have battery-backed disk cache or a monitored UPS (neither of which are appropriate requirements for large swaths of the Fedora user base).
Actually, a large swath of the Fedora user base runs laptops, which depending on how you look at it could be considered either a battery-backed disk cache or a monitored UPS.
There are customs on the road - flashing your lights to signal to someone (truckers ESPECIALLY follow this - or used to) to go ahead and pull in front of you; the flashing indicates "you're clear" and when you move over, you signal "thanks" by flashing rear fogs or brake lights (many truck drivers do that to this day, but many do not any more) once you're in your lane.
I suspect this is a regional thing. I've never seen it here, and I've done a fair bit of long-distance driving.
People in the larger vehicle of a 2 vehicle crash, tend to have longer lifespans post-incident.
If everyone took that as gospel the end result would be an arms race of ever-larger vehicles. There is evidence that a newer smaller car is at least as good as an older larger one. Also, I'd rather be in a crash between two small cars than two big trucks. Lastly, the likelihood of me personally dying in a car crash is about 0.7%. Why would I base my car-buying on that?
If the same shows are being constantly streamed over the ISP's network, it might make sense for the large ISPs to strike a deal with Netflix to cache their data within the ISP's network and avoid the need for upstream traffic.
I work as a software developer for linux. I've been running linux for a decade. Some things still don't work properly and it's mostly related to hardware support.
I recently got a new laptop for the family and then work upgraded my business laptop. Both of them use a touchpad that doesn't have proper linux support because the vendor doesn't want to release the specs. Thus when running Linux all the fancy multi-touch gestures don't work, horizontal scrolling doesn't work, and I can't configure sensitivity, tap-to-click, disable-when-typing, etc.
Similarly, multi-monitor support is kind of flaky. It doesn't remember which outputs I was using so X always starts up using the laptop display even when it's in a dock.
Lastly, the wireless networking manager in KDE can't connect to a wireless access point that isn't broadcasting its SSID. You need to enable broadcast, configure the network, then disable broadcast again. This is fine when it's your own network, but if it's not yours this is a real pain.
1) Boot up in linux 2) use dd to copy over MBR and partition table 3) for each partition on source disk, mount it and equivalent partition on target disk, copy all contents, unmount 4) reboot, repartition any free space on the new disk
If you're using lilo or something else that can't handle stuff moving around, just use dd to copy everything in one step without mounting the devices. This is less efficient in that it will copy the free space as well, but the target will be an exact copy of the source.
The equipment vendors are aware that "deep packet inspection" has negative connotations, and at least some of them are now using the term "traffic and policy management" or TPM.
I think the solution to multimonitor gaming (at least for FPS games) is to have reduced levels of detail in the side monitors. Since they're really only there to provide immersion and the player shouldn't be focussing on them anyway, it should be possible to show a lot less detail and still give the same "feel" to the player.
They're not comparing to your dad's turntable. They're using fancy turntables with cartridges that cost more than your computer. Under ideal conditions, vinyl can sound really good.
It should be possible to make the material transparent in the radio spectrum but reflective in the visible/infrared spectrum. This would be the best of both worlds.
The Jesuits in particular have a long history of intellectual research, so it's not surprising that one or more of them may *get* the distinction between hacking and cracking.
Instead of sticking with an old kernel release and backporting patches, why not move forward to the latest kernel?
Money.
Suppose you have some embedded hardware that you paid the hardware vendor $$$ to provide support for version X of Redhat. As long as Redhat keeps version X alive, you're happy. If Redhat jumps to version Y with a new kernel, you now need to pay $$$ again for support of that embedded hardware. Or maybe the hardware vendor paid $$$ to Redhat, and if Redhat jumps to version Y they're contractually obligated to rewrite the support for that hardware.
Alternately, as long as a product stays on Redhat X the managers may not think it needs to be regression-tested, but if Redhat stops maintaining version X and forces everyone to jump to version Y then the whole product needs to be regression-tested from scratch. This costs money.
There is/will be a web interface for RedHat customers with formal support to see the individual broken-out patches. This move just makes it so that they're not available to non-paying customers. (i.e. Oracle)
It would certainly be possible to do something like this in software...specify a certain USB slot as "storage-only" and raise big warnings if it tries to do anything else.
The country-specific google sites don't all support site blocking. In particular, google.ca doesn't.
While there may always be a desire for manual override, you could conceivably program a lot of this sort of thing. You could have rules like "when someone detected entering ensuite bathroom, if bedroom lights are out and it's after sunset then slowly ramp up lights to 20% else bring up lights to 100%"
In many pieces of software the algorithms are obvious and straightforward, it's just tedius to implement them and make them interface vwith the rest of the system. I would say it's actually rare that the algorithms are particularly innovative.
For others ZFS will remain better, but you better have battery-backed disk cache or a monitored UPS (neither of which are appropriate requirements for large swaths of the Fedora user base).
Actually, a large swath of the Fedora user base runs laptops, which depending on how you look at it could be considered either a battery-backed disk cache or a monitored UPS.
There are customs on the road - flashing your lights to signal to someone (truckers ESPECIALLY follow this - or used to) to go ahead and pull in front of you; the flashing indicates "you're clear" and when you move over, you signal "thanks" by flashing rear fogs or brake lights (many truck drivers do that to this day, but many do not any more) once you're in your lane.
I suspect this is a regional thing. I've never seen it here, and I've done a fair bit of long-distance driving.
People in the larger vehicle of a 2 vehicle crash, tend to have longer lifespans post-incident.
If everyone took that as gospel the end result would be an arms race of ever-larger vehicles. There is evidence that a newer smaller car is at least as good as an older larger one. Also, I'd rather be in a crash between two small cars than two big trucks. Lastly, the likelihood of me personally dying in a car crash is about 0.7%. Why would I base my car-buying on that?
If the same shows are being constantly streamed over the ISP's network, it might make sense for the large ISPs to strike a deal with Netflix to cache their data within the ISP's network and avoid the need for upstream traffic.
I work as a software developer for linux. I've been running linux for a decade. Some things still don't work properly and it's mostly related to hardware support.
I recently got a new laptop for the family and then work upgraded my business laptop. Both of them use a touchpad that doesn't have proper linux support because the vendor doesn't want to release the specs. Thus when running Linux all the fancy multi-touch gestures don't work, horizontal scrolling doesn't work, and I can't configure sensitivity, tap-to-click, disable-when-typing, etc.
Similarly, multi-monitor support is kind of flaky. It doesn't remember which outputs I was using so X always starts up using the laptop display even when it's in a dock.
Lastly, the wireless networking manager in KDE can't connect to a wireless access point that isn't broadcasting its SSID. You need to enable broadcast, configure the network, then disable broadcast again. This is fine when it's your own network, but if it's not yours this is a real pain.
1) Boot up in linux
2) use dd to copy over MBR and partition table
3) for each partition on source disk, mount it and equivalent partition on target disk, copy all contents, unmount
4) reboot, repartition any free space on the new disk
If you're using lilo or something else that can't handle stuff moving around, just use dd to copy everything in one step without mounting the devices. This is less efficient in that it will copy the free space as well, but the target will be an exact copy of the source.
The equipment vendors are aware that "deep packet inspection" has negative connotations, and at least some of them are now using the term "traffic and policy management" or TPM.
Doesn't that sound nice and innocuous?
It's impossible to cover every possible scenario in unit tests. Also, unit tests don't cover the system as a whole.
I think the solution to multimonitor gaming (at least for FPS games) is to have reduced levels of detail in the side monitors. Since they're really only there to provide immersion and the player shouldn't be focussing on them anyway, it should be possible to show a lot less detail and still give the same "feel" to the player.
between being expendable and having finished the previous set of tasks that were assigned to you.
And has anyone documented a repeatable real world test for 'bufferbloat' or is this still an academic issue?
Yeah, bufferbloat is real and easily reproducible. Run the Netalyzr test: http://netalyzr.icsi.berkeley.edu/
They're not comparing to your dad's turntable. They're using fancy turntables with cartridges that cost more than your computer. Under ideal conditions, vinyl can sound really good.
Sitting 12 feet away from an 96-inch image is about right for watching movies.
Or at least a waveguide.
It should be possible to make the material transparent in the radio spectrum but reflective in the visible/infrared spectrum. This would be the best of both worlds.
The Jesuits in particular have a long history of intellectual research, so it's not surprising that one or more of them may *get* the distinction between hacking and cracking.
Instead of sticking with an old kernel release and backporting patches, why not move forward to the latest kernel?
Money.
Suppose you have some embedded hardware that you paid the hardware vendor $$$ to provide support for version X of Redhat. As long as Redhat keeps version X alive, you're happy. If Redhat jumps to version Y with a new kernel, you now need to pay $$$ again for support of that embedded hardware. Or maybe the hardware vendor paid $$$ to Redhat, and if Redhat jumps to version Y they're contractually obligated to rewrite the support for that hardware.
Alternately, as long as a product stays on Redhat X the managers may not think it needs to be regression-tested, but if Redhat stops maintaining version X and forces everyone to jump to version Y then the whole product needs to be regression-tested from scratch. This costs money.
There is/will be a web interface for RedHat customers with formal support to see the individual broken-out patches. This move just makes it so that they're not available to non-paying customers. (i.e. Oracle)
Everyone thinks cheap goods due to outsourcing is a great idea...till their own job is outsourced.
So things are a bit muddy around ownership, jurisdiction, etc.
So things are a bit muddy as to whether ARIN has any jurisdiction in this case.