To give you an example of a meeting that spans several timezones; we needed to hold a teleconference with people in the UK, Australia and the US. Within the US, a company with offices in New York and San Francisco faces the same issue; you have people in different timezones, who need to agree on a time.
It's not possible to get a perfect solution to the problem. The best design I've seen stores times in UTC, together with a description of the entry timezone and the offset. Each user has a current local timezone (and it's assumed that users who travel will track these problems for themselves). When a change to DST comes along, the administrator can do some or all of the following:
Adjust meetings such that meetings entered in the timezone that's changing are at the same local time (but a different UTC time).
Adjust meetings such that meetings entered in the timezone that's changing are at the same UTC time (but a different local time).
Alert everyone who's involved with a meeting where one or more participants are in a timezone that's changing to check that the time is still valid.
The system also allows users to override the entry timezone on a per-entry basis. This means that I can enter a meeting in the UK marked as 9am Atlanta time, and be confident that it'll not only appear properly, but that if Atlanta's timezone changes on me, it'll be updated properly.
No, but I have the option to switch banks, which keeps the charges under control; if HSBC has to charge me more/pay me less interest than Chase to make the same profit (because HSBC's RFID cards are insecure, and Chase doesn't issue RFID cards), then I'll switch to Chase. Thus, HSBC either has to fix the security issues with their RFID cards, stop issuing RFID cards, or make less money.
My answer would depend entirely on who pays if the remotely accessible card data is used to make transactions without my authorisation:
If I pay, then it is in my interests to worry about the security of the card, and I'll want a card that's unlikely to be used without my authorisation (a PIN I set required, mechanical action needed to start the process etc). I do not want to risk paying for fraudulent transactions, and I will do what I can to minimise that risk.
If the bank pays, then I can leave the security to the bank; if someone designs a remote reader and uses it to take $10 from every customer, that's the bank's problem, not mine. I therefore don't need to worry about the security of the card design (although I do need to keep authorisation secrets secret), as if RFID cards are as hackable as they appear, the bank will do something about it to avoid eating too large a loss.
If you're running sensibly, your server does the spam checking *before* returning the final 2xx result at end of data. Thus, once you discover that the mail's spammy, you give the server that's sending mail your way a 5xx result, and let it handle sending a bounce mail to the sender. Spam senders tend to just drop mail on 5xx codes, so you've not lost anything.
That way, your mail server never sends bounces. If a server delivering mail to you starts sending backscatter bounces, it's their problem, and they need to find a way to stop it.
I use bash, so you may need to tweak this for your shell of choice. The last line of my.bash_profile is "screen -DR". This reattaches me to my screen session whenever I log in via SSH; the bash instances started by screen only inspect.bashrc, not.bash_profile.
Hope this helps you a little.
That's traditionally been quite true, but it just proves that we're basically better off doing nothing than letting either party make changes!
Not quite. It proves you're better off when the changes your government chooses to make can obtain cross-party support. If both Democrats and Republicans agree that a change is a good idea, it's more likely to be for the benefit of the country as a whole, than if just Democrats like a change, or just Republicans like a change.
Mime types could be encoded on-filesystem if FS designers chose to (Freedesktop.org has a specification for doing so in a cross-desktop fashion if you're using a UNIX with extended attributes). In any case, mapping files to file types by extension has issues to do with user training and multiple extensions (in particular, if I send you Important.jpg.vbs, which extension are you doing to pick on for the filetype, and which one is the system going to use? The wrong answer results in unexpected behaviour, which some Windows malware has exploited).
I agree that case-insensitivity is nice when working in English; however, in Arabic, short-vowel insensitivity would be more useful. In German, you have the complexity of ß versus SS versus ss. French requires you to ignore some accents. In short, the rules for each language are different, and on Windows 98, I had a few problems with foreign colleagues creating file names I couldn't handle (until we agreed on all-uppercase, English only names), because the two filenames were identical to Windows 98 English edition, but not to their foreign edition.
The point at which case sensitivity should be fixed is the point at which an application is prompting for a filename, not lower. If you're using tab-completion, I can do (locale-specific) processing to determine other plausible filenames, and print them for you to choose from. If you're using a GUI application (far more common), I can do case-insensitive handling of typed filenames, and highlight the file you've selected in a dialog box. I can even prompt you when you're creating two files with names that only differ in case, so that you can't do that accidentally. Any lower level, and you get into trouble with different languages having different case sensitivity rules.
And you've just put your finger on the conflict of interest here. Kent State does not want to lose its best athletes just because their off-pitch behaviour is bad; as a result, they don't see expulsion as an option.
Hence, instead of trying to crack down hard on athletes who break the law, they're trying to avoid the image damage those activities can cause.
In the car application though, you only want to store as much energy in the capacitor bank as a modern internal combustion engine can release from the chemical energy in the fuel; thus, just as a car could blow up, releasing all the stored energy in the fuel in one big boom, but tends not to, the capacitor bank's discharge rate is not a threat.
Besides, as Alioth points out, it wouldn't be hard to design in current limiters and encase the storage capacitors in something very hard to damage. The result would be a capacitor bank that was explosion safe unless the vehicle was so badly damaged that an equivalent fuel tank would have blown up.
Just to be clear: the Consumer Protection Distance Selling (Returns) Regulations allow you to return anything you buy at a distance (i.e. mail order, online, telephone) within 7 days of receipt for any reason, at no charge. They're aiming to give you the same chance to inspect the goods as you'd have in a retail store. Some items (such as CDs) are exempted from these regulations, and all other regulations that don't need a specific reason to return goods.
On the other hand, no goods are exempted from the Sale of Goods Act requirement that goods are "fit for purpose". This means that if they're selling something that the legal "reasonable man" would expect to be a CD, they have to make it clear to you at time of sale (before you hand over your money) that this is not a CD, and you can't expect it to play in all CD players. If it doesn't play (and therefore is faulty), it's up to them to demonstrate that it's your equipment at fault, not the "CD".
But high DPI makes text clearer, with or without anti-aliasing. It's easier to read text rendered at 100dpi than text rendered at 72dpi, because the extra pixels make the font shape clearer, and it's even easier to read text rendered at 220dpi.
I've had the joy of working with a 10" 1920x1080 widescreen LCD; with the applications appropriately designed and configured for it, text becomes much clearer and easier to read. Images had to be scaled up to make them viewable, but the experience still converted me to the idea that high DPI is good.
The package you're thinking of is vrms, the virtual Richard M. Stallman. It only scans your dpkg database though, so doesn't catch manually installed non-free software, only the non-free stuff installed via apt or similar mechanisms.
But we've solved the LBA28 limit, by switching to LBA48 (48-bit sector addresses, maximum of 128PiB (131,072TiB) with 512 byte sectors, going up to 512PiB (524,288TiB) with 4k sectors). Multiple block access allows a drive in PIO mode to return up to 16 contiguous sectors; in DMA modes, the drive is allowed to set a limit of up to 128MiB of contiguous sectors. Thus, a larger sector size helps with MSDOS (PIO mode only), but not Windows 2000 or above, or Linux 2.0 or above (or probably Linux 1.2, but I've not investigated that).
The gain is that for large disks, the filesystems already use 4K blocks; having the sector size == 4K just means that the sector size and block size match, so that sector and block numbers match, and the drive can use more efficient ECC to get more usable space.
One of the reaons.xxx is doomed as a TLD is that it's discussed in terms of penalties for non-compliance, with the assumption that porn sites (used to being on the shady edges of the law anyway) will not go looking for loopholes. In practice, they will find ways out of the law; they've got to have good lawyers anyway, and you might as well pay them to do something useful.
What might work is providing sites with an exemption from some laws if they are only accessible via a.xxx TLD. For example, you could enshrine in law that a person is declaring that they're old enough to view porn in their locality if they access the site (whether the appropriate age is 16,18,21 or 185), or that content on.xxx is exempt from obscenity laws, as it's labelled as potentially obscene. By giving porn sites exemption from potentially problematic laws in return for moving to.xxx, you encourage them over.
If the goal really is to protect children and people who don't want to see porn, this sort of relaxation of regulations (possibly combined with stricter enforcement of the regulations that have been relaxed for.xxx) meets their requirements. It will move porn to the.xxx domain, simply because that lowers their running costs.
The other advantage of gas taxes that you missed is that they tend to hit the richest hardest (it's not completely even, as the bottom end of the car driving spectrum drive cars that are barely running, and therefore consume a bit more fuel). Even if everyone buys cars with identical engine efficiencies (taking regenerative braking and other hybrid gains into account), all those luxury items the rich like have weight, and therefore need more fuel to shift (extra suspension, large music collections - CD changers and the like - high end air conditioning etc).
"NMR" pronounced as three individual letters sounds similar to "enema". When hospital staff are underpaid, overworked, or just plain rushed, there's a high risk that they'll misidentify your need and you'll get something you didn't expect.
Assuming your NAT is just a NAT, and not a combined NAT+firewall (in which case you can just drop the NAT in IPv6, and keep the firewall), anyone who can get a packet addressed to 192.168.0.10 to your NAT (loose source routing, ISP foul-up, some form of automatic de-encapsulation of GRE, null encryption ESP tunneling or IP-IP by your router etc) can talk to you.
Branch prediction is when the CPU guesses whether a conditional jump will be taken or not taken, in order to keep the pipeline full (if the pipeline empties, even for one instruction's worth of time, the CPU runs slower). Usually, this guess is partly based on static rules (if it would branch backwards, it'll probably be taken, while forward jumps are probably not taken), and partly on dynamic rules (the last four times I saw this conditional jump, I took it, so I'll assume it'll be taken again this time).
In Cell and other IBM PPE designs, there is no dynamic prediction hardware, so the CPU makes the same guess every time, even when it's obvious to a human that it's wrong. This costs in performance for code like AI, where the chances of taking the jump vary while the game is running.
Even if your figures are reasonable (and as wowbagger's said, they're not), don't forget that you're not replacing a cheap DSP or FPGA with an expensive CPU. You're replacing a cheap DSP, cheapish CPU and associated glue components with an expensive CPU. When you're removing a $5 DSP, a $10 CPU, $5 of glue logic to join them, and $5 of PCB and manufacturing costs to go down to a $25 chip, you're saving nothing per-unit, but simplifying your development costs. Chances are that over the lifetime of your unit, the $25 chip, the $5 DSP and the $10 CPU are the only items that'll fall in price; if they all halve, you've made a saving.
Video-on-Demand, however, _Will_ take it's toll on the operator's network, as each customer's video-feed will be unique to that customer.
I'm sure you're already aware of this, but assuming each customer's STB has its own local storage (HDD probably, or lots of RAM), you could exploit that to reduce your bandwidth requirements, by minimising the time customers spend on their own VoD feeds. Given (bad numbers for sake of example follow) some disk for VOD caching (call it 30 minutes of video), you can have a multicast feed running once every 15 minutes - this means eight possible feeds for a 2 hour event - which all customers of a particular event can use. When a customer joins or leaves a feed, they only need a burst to catch them up with 15 minutes (at most) of video. Further, because your cache covers two overlapping multicast feeds, a customer who pauses or rewinds simply switches from feed to feed so that their local cache is kept full; fast forward is still painful (although even then, there are tricks you can pull to keep you mostly on the multicast feeds), but you've saved lots of backbone bandwidth for the common cases of "sit and watch without interruption" and "sit and watch, pausing when interrupted".
Generally, the.org booths at a show like LinuxWorld are for charitable organisations (like the FSF or Debian) instead of companies (like Novell or Red Hat). I suspect it's the "unwashed GNU/hippies" joke, just slightly subtler than usual.
There is one good reason for wanting to know where speed cameras are, even if you keep within the law: a significant proportion of cameras go up at danger spots. Knowing that this point is likely to be dangerous is helpful, even if you don't speed (the worst case is that it's more dangerous because a certain class of speeding loon likes to brake as hard as possible when they're near a speed camera, crawl past at less than half the limit, then flat out away from it).
My personal experience is that ext3 has a tendency to lose data silently, then "suddenly" supply a huge stack of lost+found entries on fsck. Reiser3 doesn't do that, nor have I ever lost data to Reiser3 without an intervening hardware failure.
YMMV, but I switched from ext3 to Reiser3 around 3 years ago, and I've only lost data since to a disk failure (backups were my friend). Ext3 would lose documents for me from time to time, then spit them back out into lost+found when I fsck'd.
Slashdot Mirror
It's not possible to get a perfect solution to the problem. The best design I've seen stores times in UTC, together with a description of the entry timezone and the offset. Each user has a current local timezone (and it's assumed that users who travel will track these problems for themselves). When a change to DST comes along, the administrator can do some or all of the following:
The system also allows users to override the entry timezone on a per-entry basis. This means that I can enter a meeting in the UK marked as 9am Atlanta time, and be confident that it'll not only appear properly, but that if Atlanta's timezone changes on me, it'll be updated properly.
No, but I have the option to switch banks, which keeps the charges under control; if HSBC has to charge me more/pay me less interest than Chase to make the same profit (because HSBC's RFID cards are insecure, and Chase doesn't issue RFID cards), then I'll switch to Chase. Thus, HSBC either has to fix the security issues with their RFID cards, stop issuing RFID cards, or make less money.
My answer would depend entirely on who pays if the remotely accessible card data is used to make transactions without my authorisation:
If I pay, then it is in my interests to worry about the security of the card, and I'll want a card that's unlikely to be used without my authorisation (a PIN I set required, mechanical action needed to start the process etc). I do not want to risk paying for fraudulent transactions, and I will do what I can to minimise that risk.
If the bank pays, then I can leave the security to the bank; if someone designs a remote reader and uses it to take $10 from every customer, that's the bank's problem, not mine. I therefore don't need to worry about the security of the card design (although I do need to keep authorisation secrets secret), as if RFID cards are as hackable as they appear, the bank will do something about it to avoid eating too large a loss.
Already exists, and there's even choice in the market. Admittedly, it's currently Opteron-only, but it could end up trickling down to 4x4.
That way, your mail server never sends bounces. If a server delivering mail to you starts sending backscatter bounces, it's their problem, and they need to find a way to stop it.
I use bash, so you may need to tweak this for your shell of choice. The last line of my .bash_profile is "screen -DR". This reattaches me to my screen session whenever I log in via SSH; the bash instances started by screen only inspect .bashrc, not .bash_profile.
Hope this helps you a little.
Not quite. It proves you're better off when the changes your government chooses to make can obtain cross-party support. If both Democrats and Republicans agree that a change is a good idea, it's more likely to be for the benefit of the country as a whole, than if just Democrats like a change, or just Republicans like a change.
I agree that case-insensitivity is nice when working in English; however, in Arabic, short-vowel insensitivity would be more useful. In German, you have the complexity of ß versus SS versus ss. French requires you to ignore some accents. In short, the rules for each language are different, and on Windows 98, I had a few problems with foreign colleagues creating file names I couldn't handle (until we agreed on all-uppercase, English only names), because the two filenames were identical to Windows 98 English edition, but not to their foreign edition.
The point at which case sensitivity should be fixed is the point at which an application is prompting for a filename, not lower. If you're using tab-completion, I can do (locale-specific) processing to determine other plausible filenames, and print them for you to choose from. If you're using a GUI application (far more common), I can do case-insensitive handling of typed filenames, and highlight the file you've selected in a dialog box. I can even prompt you when you're creating two files with names that only differ in case, so that you can't do that accidentally. Any lower level, and you get into trouble with different languages having different case sensitivity rules.
Hence, instead of trying to crack down hard on athletes who break the law, they're trying to avoid the image damage those activities can cause.
Besides, as Alioth points out, it wouldn't be hard to design in current limiters and encase the storage capacitors in something very hard to damage. The result would be a capacitor bank that was explosion safe unless the vehicle was so badly damaged that an equivalent fuel tank would have blown up.
On the other hand, no goods are exempted from the Sale of Goods Act requirement that goods are "fit for purpose". This means that if they're selling something that the legal "reasonable man" would expect to be a CD, they have to make it clear to you at time of sale (before you hand over your money) that this is not a CD, and you can't expect it to play in all CD players. If it doesn't play (and therefore is faulty), it's up to them to demonstrate that it's your equipment at fault, not the "CD".
I've had the joy of working with a 10" 1920x1080 widescreen LCD; with the applications appropriately designed and configured for it, text becomes much clearer and easier to read. Images had to be scaled up to make them viewable, but the experience still converted me to the idea that high DPI is good.
The package you're thinking of is vrms, the virtual Richard M. Stallman. It only scans your dpkg database though, so doesn't catch manually installed non-free software, only the non-free stuff installed via apt or similar mechanisms.
The gain is that for large disks, the filesystems already use 4K blocks; having the sector size == 4K just means that the sector size and block size match, so that sector and block numbers match, and the drive can use more efficient ECC to get more usable space.
What might work is providing sites with an exemption from some laws if they are only accessible via a .xxx TLD. For example, you could enshrine in law that a person is declaring that they're old enough to view porn in their locality if they access the site (whether the appropriate age is 16,18,21 or 185), or that content on .xxx is exempt from obscenity laws, as it's labelled as potentially obscene. By giving porn sites exemption from potentially problematic laws in return for moving to .xxx, you encourage them over.
If the goal really is to protect children and people who don't want to see porn, this sort of relaxation of regulations (possibly combined with stricter enforcement of the regulations that have been relaxed for .xxx) meets their requirements. It will move porn to the .xxx domain, simply because that lowers their running costs.
The other advantage of gas taxes that you missed is that they tend to hit the richest hardest (it's not completely even, as the bottom end of the car driving spectrum drive cars that are barely running, and therefore consume a bit more fuel). Even if everyone buys cars with identical engine efficiencies (taking regenerative braking and other hybrid gains into account), all those luxury items the rich like have weight, and therefore need more fuel to shift (extra suspension, large music collections - CD changers and the like - high end air conditioning etc).
"NMR" pronounced as three individual letters sounds similar to "enema". When hospital staff are underpaid, overworked, or just plain rushed, there's a high risk that they'll misidentify your need and you'll get something you didn't expect.
Assuming your NAT is just a NAT, and not a combined NAT+firewall (in which case you can just drop the NAT in IPv6, and keep the firewall), anyone who can get a packet addressed to 192.168.0.10 to your NAT (loose source routing, ISP foul-up, some form of automatic de-encapsulation of GRE, null encryption ESP tunneling or IP-IP by your router etc) can talk to you.
In Cell and other IBM PPE designs, there is no dynamic prediction hardware, so the CPU makes the same guess every time, even when it's obvious to a human that it's wrong. This costs in performance for code like AI, where the chances of taking the jump vary while the game is running.
Even if your figures are reasonable (and as wowbagger's said, they're not), don't forget that you're not replacing a cheap DSP or FPGA with an expensive CPU. You're replacing a cheap DSP, cheapish CPU and associated glue components with an expensive CPU. When you're removing a $5 DSP, a $10 CPU, $5 of glue logic to join them, and $5 of PCB and manufacturing costs to go down to a $25 chip, you're saving nothing per-unit, but simplifying your development costs. Chances are that over the lifetime of your unit, the $25 chip, the $5 DSP and the $10 CPU are the only items that'll fall in price; if they all halve, you've made a saving.
I'm sure you're already aware of this, but assuming each customer's STB has its own local storage (HDD probably, or lots of RAM), you could exploit that to reduce your bandwidth requirements, by minimising the time customers spend on their own VoD feeds. Given (bad numbers for sake of example follow) some disk for VOD caching (call it 30 minutes of video), you can have a multicast feed running once every 15 minutes - this means eight possible feeds for a 2 hour event - which all customers of a particular event can use. When a customer joins or leaves a feed, they only need a burst to catch them up with 15 minutes (at most) of video. Further, because your cache covers two overlapping multicast feeds, a customer who pauses or rewinds simply switches from feed to feed so that their local cache is kept full; fast forward is still painful (although even then, there are tricks you can pull to keep you mostly on the multicast feeds), but you've saved lots of backbone bandwidth for the common cases of "sit and watch without interruption" and "sit and watch, pausing when interrupted".
Generally, the .org booths at a show like LinuxWorld are for charitable organisations (like the FSF or Debian) instead of companies (like Novell or Red Hat). I suspect it's the "unwashed GNU/hippies" joke, just slightly subtler than usual.
That's a fairly major problem when you come to change things.
There is one good reason for wanting to know where speed cameras are, even if you keep within the law: a significant proportion of cameras go up at danger spots. Knowing that this point is likely to be dangerous is helpful, even if you don't speed (the worst case is that it's more dangerous because a certain class of speeding loon likes to brake as hard as possible when they're near a speed camera, crawl past at less than half the limit, then flat out away from it).
YMMV, but I switched from ext3 to Reiser3 around 3 years ago, and I've only lost data since to a disk failure (backups were my friend). Ext3 would lose documents for me from time to time, then spit them back out into lost+found when I fsck'd.