There's no reason the desktop couldn't have location information...just ask the user, or infer it from wifi networks, or get a rough idea based on IP address.
I picked up a firesale Touchpad. I use it pretty much every day. It still works fine, the wireless charger is awesome, and dual-booting Android on it gives access to a bunch of current apps.
It's not perfect, but for $100 it's been a really useful device.
Payphones are not a profit center for the company, so if they're being used less and less then the per-call cost of installing/maintaining the phones will increase. At some point you need to increase the rates to cover the cost of the phones.
The "novel" idea here is that you have a main charger and a bunch of wireless devices. At least some of those devices can *retransmit* some fraction of the received power to other devices.
The main benefit is that you only need to have one of the wireless devices in range of the main power transmitter, and it will re-radiate the power to the other wireless devices.
The innovative part of the claim is actually to have the computer send power to a one device then have that device in turn send some of that power to one or more other devices.
The main benefit is that you can support multiple wireless devices and only one of them needs to be within range of the main charger.
The economy flights that I've been on barely have enough room to fit the laptop (with screen closed) on the tray. There is ZERO room to open up the screen and tilt it back far enough to read comfortably (at least not with my 14" one....maybe with a smaller screen it might be possible).
If I'm actually doing "developing" linux on the laptop (in a mobile context) then I want the highest pixel count I can get. Ideally I'd want something like 2560x1600 on a 17" display.
The retina display mac doesn't actually count because linux doesn't run well on it and even with small text you're limited as to how much you can fit on a 15" screen and still have it be readable.
There used to be quite a few 1920x1200 laptops, but nobody makes them any more so the best current option is 1920x1080.
You're pretty sure that health insurance is meant to cover only catastrophes, but it's not. It's to cover spikes in health care costs that come from occasional expensive events. It's just like car collision insurance: it's a financing strategy that allows people to keep moving through life in a way they can afford, based on statistics. In fact car insurance should pay for routine maintenance that prevents catastrophic costs like engines seizing or bald tires skidding into something.
Sorry, but no. Insurance, by definition, is there to cover events that are too expensive to be able to afford the immediate expense, and unlikely enough that you don't actually expect to need it very often.
Routine maintenance is by definition routine, and therefore shouldn't be covered by insurance. If you start using insurance for routine events, then the overall cost goes up because the insurance company will want to take a share of the profits.
The Linux Foundation pre-bootloader will boot anything (including unsigned OS's) so they use the "present user" test to ensure that they don't become a vector for installing malware (and thus get the key revoked).
The "proper" RHEL/Fedora/SuSE distros will have their own signed bootloader which will only boot distro-signed OS code. These will presumably support automated installs.
When running in secure mode the system will run only code signed by your distro. If you want to run arbitrary code you need to install your own keys and sign your code or else disable secure boot.
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet, especially if the module is actually compiled into the kernel rather than loaded later). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable position to take.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
I had code in udev for a while, though it's probably been replaced now. (Moved from multithreaded to singlethreaded and made it way faster at the same time.)
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable request.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
Slashdot Mirror
There's no reason the desktop couldn't have location information...just ask the user, or infer it from wifi networks, or get a rough idea based on IP address.
I picked up a firesale Touchpad. I use it pretty much every day. It still works fine, the wireless charger is awesome, and dual-booting Android on it gives access to a bunch of current apps.
It's not perfect, but for $100 it's been a really useful device.
Payphones are not a profit center for the company, so if they're being used less and less then the per-call cost of installing/maintaining the phones will increase. At some point you need to increase the rates to cover the cost of the phones.
The "novel" idea here is that you have a main charger and a bunch of wireless devices. At least some of those devices can *retransmit* some fraction of the received power to other devices.
The main benefit is that you only need to have one of the wireless devices in range of the main power transmitter, and it will re-radiate the power to the other wireless devices.
The innovative part of the claim is actually to have the computer send power to a one device then have that device in turn send some of that power to one or more other devices.
The main benefit is that you can support multiple wireless devices and only one of them needs to be within range of the main charger.
If you look at a Hershey chocolate bar, it does in fact have "chocolate" listed in the ingredient list, which is by definition made from cacao.
I don't want to work with you.
The economy flights that I've been on barely have enough room to fit the laptop (with screen closed) on the tray. There is ZERO room to open up the screen and tilt it back far enough to read comfortably (at least not with my 14" one....maybe with a smaller screen it might be possible).
If I'm actually doing "developing" linux on the laptop (in a mobile context) then I want the highest pixel count I can get. Ideally I'd want something like 2560x1600 on a 17" display.
The retina display mac doesn't actually count because linux doesn't run well on it and even with small text you're limited as to how much you can fit on a 15" screen and still have it be readable.
There used to be quite a few 1920x1200 laptops, but nobody makes them any more so the best current option is 1920x1080.
Given that, 1366x768 is seriously crappy.
http://sogknives.com/store/S66.html
If everyone chose to drive Suburbans, then they would actually be less safe overall since there is more energy involved in a collision.
You'd be better off if everyone was driving light vehicles.
I was using git long before I knew any nitty gritty details. Here's a useful site for beginners: Everyday GIT With 20 Commands Or So
While it does affect upgrades, the more important impact is to reduce the amount of choice when building a system.
If true, it likely means it will be harder to find a high-end cpu on a no-frills motherboard, or a low-end cpu on a fancy motherboard.
You're pretty sure that health insurance is meant to cover only catastrophes, but it's not. It's to cover spikes in health care costs that come from occasional expensive events. It's just like car collision insurance: it's a financing strategy that allows people to keep moving through life in a way they can afford, based on statistics. In fact car insurance should pay for routine maintenance that prevents catastrophic costs like engines seizing or bald tires skidding into something.
Sorry, but no. Insurance, by definition, is there to cover events that are too expensive to be able to afford the immediate expense, and unlikely enough that you don't actually expect to need it very often.
Routine maintenance is by definition routine, and therefore shouldn't be covered by insurance. If you start using insurance for routine events, then the overall cost goes up because the insurance company will want to take a share of the profits.
It's signed by a key "rooted" in the generic key. If leaked, Microsoft would just revoke that key.
As noted above, the Linux Foundation pre-bootloader will use a "present user" test, but will then install anything.
The RHEL/Fedora/SuSE bootloaders will not have a "present user" test, but will only load distro-signed OS code.
The Linux Foundation pre-bootloader will boot anything (including unsigned OS's) so they use the "present user" test to ensure that they don't become a vector for installing malware (and thus get the key revoked).
The "proper" RHEL/Fedora/SuSE distros will have their own signed bootloader which will only boot distro-signed OS code. These will presumably support automated installs.
snowball fights, snow forts, quinzhee
Kids get enough screen time. Get them outside.
I imagine they're looking for something like a private FB/email message to a friend planning what false story they're going to tell.
When running in secure mode the system will run only code signed by your distro. If you want to run arbitrary code you need to install your own keys and sign your code or else disable secure boot.
since that counts as public airspace.
This is huge. The OpenOffice document format is fully documented, so it will always be possible to access those documents.
And binary logs would actually make it *much* easier for programmatic tools to parse the logs for events that they care about.
As it stands it's actually quite tricky to automatically sort through a kernel log stream looking for critical events to raise alarms over.
Is Kay Sievers really that dumb?
Yes and no.
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet, especially if the module is actually compiled into the kernel rather than loaded later). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable position to take.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
I had code in udev for a while, though it's probably been replaced now. (Moved from multithreaded to singlethreaded and made it way faster at the same time.)
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable request.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.