First, I don't think you can have a civil society that includes land rights without public land ownership registration. If you've got a model you think would work I'd be happy to hear it. And if you object to it you can just not buy land and bypass the whole process -- for example, you can pay someone to own land on your behalf and lease it back from them without creating any public record of that lease.
Second, you're making a leap from "addresses must be public", which is self-evident -- any sort of private/encrypted/etc. "address" cannot be used to route packets/mail/fire departments/etc. and therefore isn't a useful address -- to "addresses associated with other records might compromise privacy". That second statement is also true, but it's not the argument being made here, nor is it applicable to a discussion of the collection of MAC addresses and SSIDs, neither of which contain any private information of any sort.
Given the fact that space exists and radio signal strength decreases over distance, it is easily possible to associate these WiFi addresses with another address -- your physical location. But again, there's no inherently private information in that tuple because they are all just address. It's not any different that being able to translate your street address into a set of lat/long coordinates; it's really just two different ways to talk about the same location.
Now if you had a method to relate MACs or SSIDs to individual identities or other private information -- say you had an HTTP cookie and could run some javascript to get the router's MAC address -- then you'd actually have the ability to compromise privacy. But all that comes from linking individually meaningless address information to some record that already contains private data. In that discussion I'd be right with you, but in this one you're just arguing that you don't like the UPCs on your food because they define a different address space than you had when cashiers had to map products to prices using names or price tags or some other addressing/message-passing system.
Turning off the SSID broadcast doesn't actually keep anyone packet sniffing from seeing your SSID -- the SSID is necessarily included in clear text in every association request. Moreover, since the normal network detection scheme (i.e. beacon frames) don't work with SSID broadcast disabled, many operating systems (including Windows) send out preemptive association requests as a method to detect proximity to such networks. So by disabling SSID on the home router you not only don't protect yourself from local sniffing but you turn your laptop into a beacon that broadcasts your SSID every where you go.
How are those customers expecting to see local SSIDs, or for their router to know which packets are destined for it, if the names and addresses aren't sent in the clear? Address are necessarily public in any message-passing system -- be it your WiFi MAC or your mailing address, it has to be available in clear text to all routers or messages cannot be delivered. The fact that some people think computers are magic or otherwise exempt from such common-sense, no-technical-knowledge-required rules is no reason to be angry at Google or LinkSys or anyone else making or using WiFi equipment.
You couldn't get a detailed location from that picture (or at least you didn't know -- there actually might be a good deal of information available from things like the angle of the sun/etc.). But you did get a lot of other potentially private information about the layout and contents of the bedroom. The point is that publishing photos to the Internet inherently reduces your privacy, and the possibility of location stamps is only a small part of that. Focusing on EXIF data ignores the larger problem -- we shouldn't be teaching people to think "what if this photo contains my camera's serial number" we should be teaching them to think "do I want everyone in the world to know what I was doing at this place and time" and maybe choosing to not publish the photo at all if they're worried about that, rather than running it through some EXIF stripper that removes 0.01% of the information in file.
MakeMKV works on linux/windows/mac. Strips DRM from the entire disc structure leaving things in the native format or rips video/audio/subtitle streams to an MKV without transcoding or streams live via HTTP so you can interface it with mplayer/etc. for direct playback from the disc without ripping. Also does DVDs.
If someone starts selling movies on solid-state media, I agree, Blu-Ray will fall to that. But currently it's *much* more expensive than pressing a disc, so it's not something that's just around the corner. And the MPAA is not so big on the downloading. Those facts might change over time but if we're going to speculate about what might replace Blu-Ray in the future you might as well talk about how new magic technology will distribute movies via fiber optic connection from a kiosk to your brain-drive -- why would anyone want to carry around solid-state media.
Back in the real world where the future isn't clear, Blu-Ray is currently an incremental upgrade over DVD and as people replace their equipment it will slowly become standard. Think about how long it took for DVD to become the standard optical drive in new computers -- most people didn't see the point, didn't have computers fast enough to play DVDs, didn't have DVD player software, didn't own DVD videos, couldn't exchange burnt DVD with their friends, etc. But over time it became the standard and now even the $300 Dell comes with a DVD drive. Blu-Ray will likely follow a similar path.
If someone invents a new, cheaper, better way to distribute movies and the MPAA can be brought on board Blu-Ray certainly might be supplanted as the "current" video technology. However, unless the new format is also backwards compatible Blu-Ray will probably continue to supplant DVD sales, as Blu-Ray can play all current video disc formats and people still own video discs.
Or just read the article summary, where it says 50% of new player sales were Blu-Ray. That seems fairly mainstream.
The headline-grabbing premise of the article claims "Blu-Ray is failing", but the actual argument being made to convince us of that is "Blu-Ray has not entirely replaced DVD in the first few years", which most people would not consider to be the same. There's absolutely no argument stated that even tried to convince us that Blu-Ray sales are on the decline or that Blu-Rays won't continue to grow and eventually supplant DVDs just like most incremental, backward-compatible upgrades.
You can't use ping or traceroute on IPv6 addresses, and it has nothing to do with not recognizing the address -- both those tools use ICMP packets which are unique to IPv4. However there's a ping6 and a traceroute6 tool that do the same thing using ICMPv6 packets and are already installed on you Mac.
Also, you could just use.local, or whatever DNS records happen to be assigned to your machine (all machines are supposed to have host names in addition to their numbers, and on your Mac you get mdns automatically) which will resolve to both your IPv4 and IPv6 address and allow the program to choose whichever address family it likes.
If you use IPv6 autoconfig you don't need to "keep track" of MAC->IP mappings because the IP address is the MAC address, plus the well-known network prefix. DNS is also handled via autoconf by using well-known site-local address (fec0:0:0:ffff::1).
Good 3D projectors do use high display rates. They take the 24 FPS/eye video but switch between the individual eye images much faster (displaying the same image repeated) so that the maximum blanking period at each eye is reduced. But most places don't have good 3D projectors. Most places use something that can only do ~48Hz and so you end up with huge blanking periods, low perceived brightness, and lots of flicker. Using a higher frame rate does not necessarily guarantee that displays will improve, but if you force the "normal" refresh rate up to 48Hz it's likely the that the 3D refresh rate will similarly increase.
Or we could just use dual image generators and display both images simultaneously which would bring us back to the very-low inter-frame blanking period in modern projectors, but that's more expensive than just running a single image generator faster. (Though I'd like to think it's be that much more expensive -- you need another display engine, but you can use the same lamp and same optics for both images -- so that someday we might actually get it).
It's not as simple as the image refresh rate. The full image refresh rate on NTSC is only 29.97Hz but that rarely bothers people. Even the single-field refresh rate for NTSC is only ~60Hz, but again it affects many fewer people than 60Hz refresh rates on some computer monitors.
The 60Hz refresh on computers is a problem with mis-match phosphors vs. scan rate. On mutli-sync monitors the phosphors need to have a decay fast enough to ensure they've gone dark when running at the maximum refresh rate -- if you're running a monitor capable of 120Hz at only 60Hz that means the pixels are dark 50% of the time even when displaying pure white. There are some methods to mitigate this mis-match, but they're not ideal and low-end monitors rarely implemented them effectively (if at all).
Properly-matched phosphors (like in a TV or other fixed-rate CRT) do not have this prolonged dark period between scans -- they're designed so that a full-brightness pixel takes exactly 1 refresh period to decay, more or less eliminating the dark period and greatly reducing the flicker effect.
And when you're talking about film it's another story entirely, as the inter-frame period is not necessarily related to the frame rate at all. I could show 1 frame per second and have a 1ns switching time between frames that would be imperceptible in spite of the slow image refresh, or I could have a standard 24 FPS film but play in a projector with an inter-frame period of 0.04 seconds which would make the film look like a series of strobe-flashed images.
Also, what's unnaturally smooth? If vision is discrete in some period less than 48Hz then extra frames will not make it look any "smoother". And if vision is not discrete on that timescale then these movies will look smoother than other movies but still not as smooth as real life.
A) You can't get a contract without an early termination fee even if you bring your own equipment. B) The cost of the early termination fee often greatly exceeds the value of the equipment subsidy. For the high-end phones the value may be comparable, but entry-level, voice-only phones are not worth $400. C) On many carriers it's essentially impossible to convince their sales staff that you can create an account without a contract. Try it some time -- I have with 1 regional and 2 national carriers and was only successful at one of them (T-Mobile).
Officially Cisco calls it "Cisco IOS" and Apple just says "iOS". But I agree, it's worth getting the capitalization correct. And both companies could pick better names -- putting the letters "OS" into your OS name is both redundant and non-unique in many contexts.
iTunes is distributed for free; there is no revenue recognized. It's also not bundled with their OS -- it's available for OSes that Apple doesn't even sell.
You can argue that they shouldn't bother accounting XCode as part of the OS. Or that they're misunderstanding SarbOX. But their behavior is internally consistent.
You don't have to track anywhere near that much information. You just give the code a limited lifetime -- it is invalidated when scanned at a postal center, or after say 72 hours of inactivity (at which point it could be refunded or just lost). Immediately after the code is invalidated, return it to the pool of available codes to keep the maximum amount of entropy available in that pool. Given a limited lifetime the code can be fairly short and not require any information about the letter other than the amount of postage it needs, all without serious risk of someone guessing or re-using the code.
There's some additional risk to individuals, as codes can be copied in addition to just being stolen or lost like stamps. But that's not a problem for the postal service, and given the relatively low value of the postage and the simple security measures required to protect the code it's probably something individuals are willing to accept.
The risk of loss to the postal service is probably smaller than with regular stamps. The centralized, automatic, electronic distribution makes it difficult for employees or other brick-and-mortal thieves to steal postage except for the very small number of people with access to the system, and "forged" codes are much, much less likely to work than forged stamps if the code selection is appropriately random.
I will make the same comment I make every time someone posts this idiotic "rebuttal" to a statement that says "the old version is more reliable".
First, GPS as commonly used by individual, still requires maps. Based on your discussion I'm assuming that you're excluding GPS as a position-fix system and the use of external maps (which may be paper and which function without the GPS unit). Also note that on most GPS units with integrated maps the maps still work even if GPS position fixes are not available, they just lose the "you are here" feature -- i.e. they lose some functionality already not present in paper maps.
So really you're just comparing paper vs silicone as a storage and playback system. This is an argument that's been had many times, and I think most everyone would agree that both forms of storage are have their own advantages and disadvantages, and that both forms of storage are susceptible to some forms of damage or loss -- you can lose or burn both, both need protection from water and other forms of surface abrasion or staining, etc. Silicone requires an external, powered reader. Paper has a much lower storage capacity. If you're going to talk about which one is more reliable you really need to pick a specific scenario. If your requirement is "I cannot be dependent on a powered reader" then paper wins. If your requirement is "I need to store reasonably detailed maps for all of North America in my glove box" than silicone wins. If you have both requirements neither paper nor silicone is appropriate.
Also, a compass can be jammed with a bit of iron and a paper map can be jammed with a bit of jam. And paper maps don't work in the dark, whereas GPS-based system generally include their own illumination.
So if you want to play this "know how do do things the old way" game, try this view of all maps (paper or otherwise) as new and unreliable technology: Maps can get lost, stained, ripped, burned or otherwise become unreadable or unavailable, but dead reckoning cannot. Dead reckoning can be done without any batteries or light source, while maps and GPS both require some power/light source to be usable. Maps/GPS only work when people have been sent ahead to scout the area, while dead reckoning works so long as you know the relative position of your endpoint, even if you have to go around unknown obstacles. Maps/GPS require the ability to see landmarks or otherwise get a position fix, whereas dead reckoning requires not such external reference.
Clearly anyone using maps instead should also know how to navigate via path integration or some other fully-internalized navigational system, or they risk becoming lost when their fancy new "map" technology fails in some way. Plus I'm not sure this whole "paper" thing is going to catch on anyway, since it's so susceptible to damage compared to other, more established inscription technologies like stone.
Then you should look for solutions to appropriately value those resources so that people can make their own decisions about what to do in their free time rather than whinging every time someone uses a few drops of oil for a project you didn't personally approve.
What's wrong with a quiz? It's difficult to asses technical skills via a verbal interview -- asking someone to do 20 minutes of work for you lets them demonstrate their skills and gives you a standardized basis to compare candidates.
I know. I can't figure this one out. At this point writing your own router OS for SOHO-level things is like writing your own database -- you could, but it's going to be expensive and in most ways not as good as the pre-fab options.
Just put the top dev from your software team on the DD-WRT project to make sure your device and marketing features are supported, tell the guys that actually work on low-level drivers (if any -- most PHY units are now sold with prefab driver stubs from companies other than the router mfgs) to make a linux driver instead of whatever they're doing now, and lay off the entire rest of the team (or at least find something useful for them to do). You'd get better software for less cost and could still brand it however you wanted. It's not like the 4 pages of HTML in the quick-setup wizard would be hard to port to another backend.
One of the reasons the Arduino is so popular is because it allows programmers -- people who don't know the first thing about electronics or micro-controllers -- to build hardware devices. As you note, this is often inefficient from a production standpoint because $0.03 worth of transistors will do the same job. But the Arduino is not meant for production runs, and that $0.03 worth of transistors has a prerequisite of $20k in hardware engineering -- if you don't already have that electronics knowledge it may well be moreefficient to use the $20 Arduino to toggle your LEDs.
A programmers union might raise the overall pay. It might not. It's easy to look at 100 years of unions in say "look it's good overall" but the evidence in more specific and more recent cases is less clear.
For the sake of argument though, let's just say that average programmer wages increase after unionization, and enough so to overcome the costs of running the union, so that at least the "average" programmer see some increase in take-home pay. It's certainly within the realm of possibility, and it's not unreasonable to investigate the options.
Now let's say you are in the top 10% of programmers, and now thanks to a collective bargaining agreement you're required to join the union at unionized shops. You now have no chance at getting pay that reflects your top 10% status, since the collective bargaining deals the average programmer's skills and output and their highly-skilled negotiators (which apparently you didn't think to hire on your own behalf) aren't even talking about the pay for highly-skilled individuals, because it's not their goal.
And that's not even getting into the way that unions traditionally organize wages and layoff schedules around seniority, meaning that people who have stuck around in their job long enough cannot get payed more for no practical reason, that layoffs are larger than necessary because they're targeted at the lowest-wage workers, that performance has virtually no impact on pay, and that workers are forced to stay in bad jobs because changing employers would make them lose either seniority, none of which sound like a good idea even for average programmers, let alone highly skilled one.
If you could organize a union without seniority rules, and with the ability to pay more to high performers and less to weak performers, and with the ability to layoff whomever you thought would provide the most cost savings, I might join. But then I'm not sure what that union would be negotiating.
That's the long and short of it. They make OS X Server for people that want file sharing for their small office, or who want a tiny web/mail/etc. server to play with and are comfortable with OS X. They aren't expecting anyone to use it for more than a handful of users, except maybe as departmental node hung off an existing enterprise setup -- it does integrate fairly well with AD or LDAP/Kerberos or NIS/YP and can re-share NFS via AFP and things like that, allowing easier integration of Mac clients into a mixed-platform enterprise environment.
Yeah, everyone seems to be missing the fact the DMCA violations require the intent to violate copyright, not just the ability to do so. If he was hacking with any intent other than stealing games it's perfectly legitimate, even under the DMCA.
There are plenty of uses for cryptographic hashes that do not involve passwords.
For one thing, many people's definition of "integrity" includes protection against deliberate tampering, not just protection against bit rot/transmission errors, and CRC's linear nature makes it completely unsuitable for such use. For another CRC's "statistical guarantees for the longest run of possible errant bytes" make it good at detecting burst errors, but also make it possible for single-bit errors to go completely unnoticed.
Not to mention there are lots of functions that even you would consider worthy of cryptographic hashes -- like SSL/TLS negotiation -- that some people do on the order of billions a day. They'd probably like fast hash functions. Or at the other end of the scale, some of us would like to speak HTTPS to my embedded systems running at ~100 MHz, and deliberately slow hash functions are right out for that sort of application.
But hey, if your whole world is unprotected serial-line data transmission and password files then I guess cryptographic hash functions are only useful for password files.
I've done that with my DVDs, but I haven't yet found a playback solution for Blu-Ray that reads menus/etc. I can rip the main titles easily enough, but if you want to do any of the fancier things (like the PiP commentary/etc.) you need a full-fledged Blu-Ray playback system.
AFAIK the only option is PowerDVD, which is Windows-only and which isn't scriptable. Are there other choices? Preferably something that doesn't require Windows, but I'd even settle for "needs Windows" if the playback controls are scriptable and it won't complain about reading from imaged, decrypted folders instead of a physical disk.
And yes, I know the menus/etc. can sometimes be annoying (though Blu-Rays are much better than DVDs in that respect) but sometimes I do want to use them. Plus if the the playback interface is scriptable you can often default to "play the stinking movie" while still maintaining access to the menus if you want them, just like many HTC DVD systems do.
Slashdot Mirror
First, I don't think you can have a civil society that includes land rights without public land ownership registration. If you've got a model you think would work I'd be happy to hear it. And if you object to it you can just not buy land and bypass the whole process -- for example, you can pay someone to own land on your behalf and lease it back from them without creating any public record of that lease.
Second, you're making a leap from "addresses must be public", which is self-evident -- any sort of private/encrypted/etc. "address" cannot be used to route packets/mail/fire departments/etc. and therefore isn't a useful address -- to "addresses associated with other records might compromise privacy". That second statement is also true, but it's not the argument being made here, nor is it applicable to a discussion of the collection of MAC addresses and SSIDs, neither of which contain any private information of any sort.
Given the fact that space exists and radio signal strength decreases over distance, it is easily possible to associate these WiFi addresses with another address -- your physical location. But again, there's no inherently private information in that tuple because they are all just address. It's not any different that being able to translate your street address into a set of lat/long coordinates; it's really just two different ways to talk about the same location.
Now if you had a method to relate MACs or SSIDs to individual identities or other private information -- say you had an HTTP cookie and could run some javascript to get the router's MAC address -- then you'd actually have the ability to compromise privacy. But all that comes from linking individually meaningless address information to some record that already contains private data. In that discussion I'd be right with you, but in this one you're just arguing that you don't like the UPCs on your food because they define a different address space than you had when cashiers had to map products to prices using names or price tags or some other addressing/message-passing system.
Turning off the SSID broadcast doesn't actually keep anyone packet sniffing from seeing your SSID -- the SSID is necessarily included in clear text in every association request. Moreover, since the normal network detection scheme (i.e. beacon frames) don't work with SSID broadcast disabled, many operating systems (including Windows) send out preemptive association requests as a method to detect proximity to such networks. So by disabling SSID on the home router you not only don't protect yourself from local sniffing but you turn your laptop into a beacon that broadcasts your SSID every where you go.
How are those customers expecting to see local SSIDs, or for their router to know which packets are destined for it, if the names and addresses aren't sent in the clear? Address are necessarily public in any message-passing system -- be it your WiFi MAC or your mailing address, it has to be available in clear text to all routers or messages cannot be delivered. The fact that some people think computers are magic or otherwise exempt from such common-sense, no-technical-knowledge-required rules is no reason to be angry at Google or LinkSys or anyone else making or using WiFi equipment.
You couldn't get a detailed location from that picture (or at least you didn't know -- there actually might be a good deal of information available from things like the angle of the sun/etc.). But you did get a lot of other potentially private information about the layout and contents of the bedroom. The point is that publishing photos to the Internet inherently reduces your privacy, and the possibility of location stamps is only a small part of that. Focusing on EXIF data ignores the larger problem -- we shouldn't be teaching people to think "what if this photo contains my camera's serial number" we should be teaching them to think "do I want everyone in the world to know what I was doing at this place and time" and maybe choosing to not publish the photo at all if they're worried about that, rather than running it through some EXIF stripper that removes 0.01% of the information in file.
MakeMKV works on linux/windows/mac. Strips DRM from the entire disc structure leaving things in the native format or rips video/audio/subtitle streams to an MKV without transcoding or streams live via HTTP so you can interface it with mplayer/etc. for direct playback from the disc without ripping. Also does DVDs.
If someone starts selling movies on solid-state media, I agree, Blu-Ray will fall to that. But currently it's *much* more expensive than pressing a disc, so it's not something that's just around the corner. And the MPAA is not so big on the downloading. Those facts might change over time but if we're going to speculate about what might replace Blu-Ray in the future you might as well talk about how new magic technology will distribute movies via fiber optic connection from a kiosk to your brain-drive -- why would anyone want to carry around solid-state media.
Back in the real world where the future isn't clear, Blu-Ray is currently an incremental upgrade over DVD and as people replace their equipment it will slowly become standard. Think about how long it took for DVD to become the standard optical drive in new computers -- most people didn't see the point, didn't have computers fast enough to play DVDs, didn't have DVD player software, didn't own DVD videos, couldn't exchange burnt DVD with their friends, etc. But over time it became the standard and now even the $300 Dell comes with a DVD drive. Blu-Ray will likely follow a similar path.
If someone invents a new, cheaper, better way to distribute movies and the MPAA can be brought on board Blu-Ray certainly might be supplanted as the "current" video technology. However, unless the new format is also backwards compatible Blu-Ray will probably continue to supplant DVD sales, as Blu-Ray can play all current video disc formats and people still own video discs.
Or just read the article summary, where it says 50% of new player sales were Blu-Ray. That seems fairly mainstream.
The headline-grabbing premise of the article claims "Blu-Ray is failing", but the actual argument being made to convince us of that is "Blu-Ray has not entirely replaced DVD in the first few years", which most people would not consider to be the same. There's absolutely no argument stated that even tried to convince us that Blu-Ray sales are on the decline or that Blu-Rays won't continue to grow and eventually supplant DVDs just like most incremental, backward-compatible upgrades.
You can't use ping or traceroute on IPv6 addresses, and it has nothing to do with not recognizing the address -- both those tools use ICMP packets which are unique to IPv4. However there's a ping6 and a traceroute6 tool that do the same thing using ICMPv6 packets and are already installed on you Mac.
Also, you could just use .local, or whatever DNS records happen to be assigned to your machine (all machines are supposed to have host names in addition to their numbers, and on your Mac you get mdns automatically) which will resolve to both your IPv4 and IPv6 address and allow the program to choose whichever address family it likes.
If you use IPv6 autoconfig you don't need to "keep track" of MAC->IP mappings because the IP address is the MAC address, plus the well-known network prefix. DNS is also handled via autoconf by using well-known site-local address (fec0:0:0:ffff::1).
Good 3D projectors do use high display rates. They take the 24 FPS/eye video but switch between the individual eye images much faster (displaying the same image repeated) so that the maximum blanking period at each eye is reduced. But most places don't have good 3D projectors. Most places use something that can only do ~48Hz and so you end up with huge blanking periods, low perceived brightness, and lots of flicker. Using a higher frame rate does not necessarily guarantee that displays will improve, but if you force the "normal" refresh rate up to 48Hz it's likely the that the 3D refresh rate will similarly increase.
Or we could just use dual image generators and display both images simultaneously which would bring us back to the very-low inter-frame blanking period in modern projectors, but that's more expensive than just running a single image generator faster. (Though I'd like to think it's be that much more expensive -- you need another display engine, but you can use the same lamp and same optics for both images -- so that someday we might actually get it).
It's not as simple as the image refresh rate. The full image refresh rate on NTSC is only 29.97Hz but that rarely bothers people. Even the single-field refresh rate for NTSC is only ~60Hz, but again it affects many fewer people than 60Hz refresh rates on some computer monitors.
The 60Hz refresh on computers is a problem with mis-match phosphors vs. scan rate. On mutli-sync monitors the phosphors need to have a decay fast enough to ensure they've gone dark when running at the maximum refresh rate -- if you're running a monitor capable of 120Hz at only 60Hz that means the pixels are dark 50% of the time even when displaying pure white. There are some methods to mitigate this mis-match, but they're not ideal and low-end monitors rarely implemented them effectively (if at all).
Properly-matched phosphors (like in a TV or other fixed-rate CRT) do not have this prolonged dark period between scans -- they're designed so that a full-brightness pixel takes exactly 1 refresh period to decay, more or less eliminating the dark period and greatly reducing the flicker effect.
And when you're talking about film it's another story entirely, as the inter-frame period is not necessarily related to the frame rate at all. I could show 1 frame per second and have a 1ns switching time between frames that would be imperceptible in spite of the slow image refresh, or I could have a standard 24 FPS film but play in a projector with an inter-frame period of 0.04 seconds which would make the film look like a series of strobe-flashed images.
Also, what's unnaturally smooth? If vision is discrete in some period less than 48Hz then extra frames will not make it look any "smoother". And if vision is not discrete on that timescale then these movies will look smoother than other movies but still not as smooth as real life.
A) You can't get a contract without an early termination fee even if you bring your own equipment.
B) The cost of the early termination fee often greatly exceeds the value of the equipment subsidy. For the high-end phones the value may be comparable, but entry-level, voice-only phones are not worth $400.
C) On many carriers it's essentially impossible to convince their sales staff that you can create an account without a contract. Try it some time -- I have with 1 regional and 2 national carriers and was only successful at one of them (T-Mobile).
Officially Cisco calls it "Cisco IOS" and Apple just says "iOS". But I agree, it's worth getting the capitalization correct. And both companies could pick better names -- putting the letters "OS" into your OS name is both redundant and non-unique in many contexts.
iTunes is distributed for free; there is no revenue recognized. It's also not bundled with their OS -- it's available for OSes that Apple doesn't even sell.
You can argue that they shouldn't bother accounting XCode as part of the OS. Or that they're misunderstanding SarbOX. But their behavior is internally consistent.
You don't have to track anywhere near that much information. You just give the code a limited lifetime -- it is invalidated when scanned at a postal center, or after say 72 hours of inactivity (at which point it could be refunded or just lost). Immediately after the code is invalidated, return it to the pool of available codes to keep the maximum amount of entropy available in that pool. Given a limited lifetime the code can be fairly short and not require any information about the letter other than the amount of postage it needs, all without serious risk of someone guessing or re-using the code.
There's some additional risk to individuals, as codes can be copied in addition to just being stolen or lost like stamps. But that's not a problem for the postal service, and given the relatively low value of the postage and the simple security measures required to protect the code it's probably something individuals are willing to accept.
The risk of loss to the postal service is probably smaller than with regular stamps. The centralized, automatic, electronic distribution makes it difficult for employees or other brick-and-mortal thieves to steal postage except for the very small number of people with access to the system, and "forged" codes are much, much less likely to work than forged stamps if the code selection is appropriately random.
I will make the same comment I make every time someone posts this idiotic "rebuttal" to a statement that says "the old version is more reliable".
First, GPS as commonly used by individual, still requires maps. Based on your discussion I'm assuming that you're excluding GPS as a position-fix system and the use of external maps (which may be paper and which function without the GPS unit). Also note that on most GPS units with integrated maps the maps still work even if GPS position fixes are not available, they just lose the "you are here" feature -- i.e. they lose some functionality already not present in paper maps.
So really you're just comparing paper vs silicone as a storage and playback system. This is an argument that's been had many times, and I think most everyone would agree that both forms of storage are have their own advantages and disadvantages, and that both forms of storage are susceptible to some forms of damage or loss -- you can lose or burn both, both need protection from water and other forms of surface abrasion or staining, etc. Silicone requires an external, powered reader. Paper has a much lower storage capacity. If you're going to talk about which one is more reliable you really need to pick a specific scenario. If your requirement is "I cannot be dependent on a powered reader" then paper wins. If your requirement is "I need to store reasonably detailed maps for all of North America in my glove box" than silicone wins. If you have both requirements neither paper nor silicone is appropriate.
Also, a compass can be jammed with a bit of iron and a paper map can be jammed with a bit of jam. And paper maps don't work in the dark, whereas GPS-based system generally include their own illumination.
So if you want to play this "know how do do things the old way" game, try this view of all maps (paper or otherwise) as new and unreliable technology:
Maps can get lost, stained, ripped, burned or otherwise become unreadable or unavailable, but dead reckoning cannot. Dead reckoning can be done without any batteries or light source, while maps and GPS both require some power/light source to be usable. Maps/GPS only work when people have been sent ahead to scout the area, while dead reckoning works so long as you know the relative position of your endpoint, even if you have to go around unknown obstacles. Maps/GPS require the ability to see landmarks or otherwise get a position fix, whereas dead reckoning requires not such external reference.
Clearly anyone using maps instead should also know how to navigate via path integration or some other fully-internalized navigational system, or they risk becoming lost when their fancy new "map" technology fails in some way. Plus I'm not sure this whole "paper" thing is going to catch on anyway, since it's so susceptible to damage compared to other, more established inscription technologies like stone.
Then you should look for solutions to appropriately value those resources so that people can make their own decisions about what to do in their free time rather than whinging every time someone uses a few drops of oil for a project you didn't personally approve.
What's wrong with a quiz? It's difficult to asses technical skills via a verbal interview -- asking someone to do 20 minutes of work for you lets them demonstrate their skills and gives you a standardized basis to compare candidates.
I know. I can't figure this one out. At this point writing your own router OS for SOHO-level things is like writing your own database -- you could, but it's going to be expensive and in most ways not as good as the pre-fab options.
Just put the top dev from your software team on the DD-WRT project to make sure your device and marketing features are supported, tell the guys that actually work on low-level drivers (if any -- most PHY units are now sold with prefab driver stubs from companies other than the router mfgs) to make a linux driver instead of whatever they're doing now, and lay off the entire rest of the team (or at least find something useful for them to do). You'd get better software for less cost and could still brand it however you wanted. It's not like the 4 pages of HTML in the quick-setup wizard would be hard to port to another backend.
One of the reasons the Arduino is so popular is because it allows programmers -- people who don't know the first thing about electronics or micro-controllers -- to build hardware devices. As you note, this is often inefficient from a production standpoint because $0.03 worth of transistors will do the same job. But the Arduino is not meant for production runs, and that $0.03 worth of transistors has a prerequisite of $20k in hardware engineering -- if you don't already have that electronics knowledge it may well be moreefficient to use the $20 Arduino to toggle your LEDs.
A programmers union might raise the overall pay. It might not. It's easy to look at 100 years of unions in say "look it's good overall" but the evidence in more specific and more recent cases is less clear.
For the sake of argument though, let's just say that average programmer wages increase after unionization, and enough so to overcome the costs of running the union, so that at least the "average" programmer see some increase in take-home pay. It's certainly within the realm of possibility, and it's not unreasonable to investigate the options.
Now let's say you are in the top 10% of programmers, and now thanks to a collective bargaining agreement you're required to join the union at unionized shops. You now have no chance at getting pay that reflects your top 10% status, since the collective bargaining deals the average programmer's skills and output and their highly-skilled negotiators (which apparently you didn't think to hire on your own behalf) aren't even talking about the pay for highly-skilled individuals, because it's not their goal.
And that's not even getting into the way that unions traditionally organize wages and layoff schedules around seniority, meaning that people who have stuck around in their job long enough cannot get payed more for no practical reason, that layoffs are larger than necessary because they're targeted at the lowest-wage workers, that performance has virtually no impact on pay, and that workers are forced to stay in bad jobs because changing employers would make them lose either seniority, none of which sound like a good idea even for average programmers, let alone highly skilled one.
If you could organize a union without seniority rules, and with the ability to pay more to high performers and less to weak performers, and with the ability to layoff whomever you thought would provide the most cost savings, I might join. But then I'm not sure what that union would be negotiating.
That's the long and short of it. They make OS X Server for people that want file sharing for their small office, or who want a tiny web/mail/etc. server to play with and are comfortable with OS X. They aren't expecting anyone to use it for more than a handful of users, except maybe as departmental node hung off an existing enterprise setup -- it does integrate fairly well with AD or LDAP/Kerberos or NIS/YP and can re-share NFS via AFP and things like that, allowing easier integration of Mac clients into a mixed-platform enterprise environment.
Yeah, everyone seems to be missing the fact the DMCA violations require the intent to violate copyright, not just the ability to do so. If he was hacking with any intent other than stealing games it's perfectly legitimate, even under the DMCA.
There are plenty of uses for cryptographic hashes that do not involve passwords.
For one thing, many people's definition of "integrity" includes protection against deliberate tampering, not just protection against bit rot/transmission errors, and CRC's linear nature makes it completely unsuitable for such use. For another CRC's "statistical guarantees for the longest run of possible errant bytes" make it good at detecting burst errors, but also make it possible for single-bit errors to go completely unnoticed.
Not to mention there are lots of functions that even you would consider worthy of cryptographic hashes -- like SSL/TLS negotiation -- that some people do on the order of billions a day. They'd probably like fast hash functions. Or at the other end of the scale, some of us would like to speak HTTPS to my embedded systems running at ~100 MHz, and deliberately slow hash functions are right out for that sort of application.
But hey, if your whole world is unprotected serial-line data transmission and password files then I guess cryptographic hash functions are only useful for password files.
I've done that with my DVDs, but I haven't yet found a playback solution for Blu-Ray that reads menus/etc. I can rip the main titles easily enough, but if you want to do any of the fancier things (like the PiP commentary/etc.) you need a full-fledged Blu-Ray playback system.
AFAIK the only option is PowerDVD, which is Windows-only and which isn't scriptable. Are there other choices? Preferably something that doesn't require Windows, but I'd even settle for "needs Windows" if the playback controls are scriptable and it won't complain about reading from imaged, decrypted folders instead of a physical disk.
And yes, I know the menus/etc. can sometimes be annoying (though Blu-Rays are much better than DVDs in that respect) but sometimes I do want to use them. Plus if the the playback interface is scriptable you can often default to "play the stinking movie" while still maintaining access to the menus if you want them, just like many HTC DVD systems do.