How hot does the engine run with that much extra compression? I'd imagine it'd be pretty rough on the cylinder walls if you did it for anything longer than 1/4mi dragging.
I don't think it's beyond the realm of engineering or anything -- maybe we need to look back into ceramic composite cylinders, which I think was a focus of research back in the 70s or 80s -- but I'd be surprised if you could take an engine designed for 87 octane gasoline and increase the compression to what's optimal for E85, without increasing the wear pretty substantially.
I can't believe this could even be an issue. Why don't your lawmakers make it illegal for those responsible for financing medical care to discriminate against people with illnesses?
Because at any given time, most voters either are, or think that they are, healthy; thus they're pretty receptive to arguments that eliminating pre-existing condition restrictions would raise their own costs. Basically, nobody who's healthy wants to pay for anybody else's healthcare.
Of course, when those people get sick it's a different story. But as long as there are more people who think they're healthy than people who are sick, the 'healthy' people discriminate against the 'sick' ones.
As the population ages, however, more people have moved from 'healthy' to 'sick' (or at least from seeing health insurance as a cost center to be minimized, to a profit center that they benefit from), and there's beginning to be a corresponding shift in attitudes with regards to insurance. Exactly how far this shift in attitudes will go and what the actual political effect of it will be, remains to be seen. I am personally quite doubtful that it will amount to much of anything beyond a tweaking of the system already in existence, but I'm admittedly hugely cynical about the political process in the U.S.
There's no point in arguing with -- much less negotiating or compromising with -- someone whose objection to your conduct is based on religious or moral grounds. They're not just going to give up because you tried to meet them in the middle; they're just going to wait until the time is right and then finish you off.
I don't think you can do that without violating the HDMI spec. The whole point of HDMI is to prevent you from having unencrypted HD video; if you could just toss on an adapter to go from HDMI to DVI (the latter is unencrypted by definition), then HDMI wouldn't need to exist.
What you could do would be eliminate HDMI and just have DVI, and then people who want HDMI use a DVI -> HDMI cable (which exist); this direction is trivial because HDMI devices will play DVI, IIRC. But this is sort of a no-go because people wouldn't buy a computer that "didn't do HDMI," plus at least on Windows there are probably applications that won't work without the encrypted signal path provided by HDMI. (On Linux I don't think that will ever be the case or matter.)
What the heck are baby monitors doing on the 2.4GHz ISM band anyway? It's not like they're a new invention, unknown before that band opened up; they've existed for decades and everyone had pretty much worked around them, on 49 MHz. From a quick Google search I can see that there are still lots of monitors that operate in that range, so I'm mystified why they're on 2.4.
Is this just "gigahertz are better than megahertz" marketing, like happened with cordless phones? I can't see any good reason to go to 2.4; it doesn't penetrate structures nearly as well as 49MHz does, and 49 has all the bandwidth you need for audio.
What the FCC (and similar organizations in other countries) ought to do is give baby monitors and similar "dumb" devices a band to work on, with defined channels (so you could adjust yours if your neighbor bought one) -- I think this may already all be done on 49 -- and tell them to stay there and stay off of the 2.4 ISM. Reserve 2.4GHz for smarter devices that operate in spread-spectrum modes and don't crap all over each other quite so badly.
It certainly could, but it doesn't seem like YouTube wants to do that. They're doing the absolute minimum required as a result of S. Korea's asinine new law -- if users say they're not from S.K., then it's not YouTube's problem anymore.
I suppose the S.K. government could try to force YouTube to do IP-based geolocation on everyone regardless of what country they specify, but that would be a pretty major escalation; they'd basically be in the position of having to threaten Chinese-style censorship in order to get compliance. I'd hope that would backfire.
Still, the whole thing is unusually ballsy given that Google usually seems to have little problem handing over user data to any government who comes knocking.
Question regarding the reliability of fanless computers: wouldn't a fanless system eventually overheat and die if it wasn't dusted periodically?
It seems like 10 or 15 years of dust in a typical office environment, even without fans moving a lot of air around, could seriously impair the effectiveness of heatsinks and cause failure.
If you went this route and really wanted zero-maintenance, I'd think you'd need to factor in dust and over-engineer the heatsinks significantly, so that you'd have the radiative capacity to stay below temperature cutoffs for the full lifetime of the machine.
I wonder if somewhere, somebody has tables showing dust buildup and its effects on electrical equipment over time in typical office environments...seems like it must be a well-thought-over issue.
> Tapes are slow, unreliable and expensive. I would not use them for any purpose.
I'll give you the slow and expensive part, but unreliable? That I'm not sure I'd agree with at all.
With the possible exception of helical-scan DAT, which was a good idea poorly implemented in many cases, tape drives and data stored on tape is extremely reliable. You can record data to a magnetic tape, put it on a shelf, and it will still be readable in 20 years. Heck, it'll probably still be readable in 50 or 100 years; the limiting factor is really the drive, not the tape. And enterprise-grade tape drives (practically all that's being manufactured anymore; they've pretty much cut it out with the cheap DATs) are built quite well.
Hard-drive based backups are very nice and I do think they're appropriate for most users, but tapes still have a place. If you need to store a lot of data either offline or nearline, the operating cost of a tape library is very low. (They don't require any electricity just sitting there, and you don't have to worry about periodically spinning them up or anything.) For archival purposes they are also excellent.
I'd perhaps even concede that tapes are a poor "backup" media, but an excellent "archival" one, if you were to split those functions out separately.
Where I would never use tape is for nightly backups that are just going to be overwritten the next day, but for saving data for the long term they are a good low-maintenance option.
Cell phones designed for home use are sort of the 'next big thing,' at least to the cell companies. Each of the 3 major carriers seems to either have one out already, or in the works.
It makes sense -- right now, they've pretty much saturated the market for cell phones: I don't know a man, woman, or child in the U.S. that wants a cell phone that doesn't have one (people who truly can't afford them excepted, although the barrier to entry is getting lower by the month; there are some prepaid phones that verge on being disposable they're so cheap). Once you've put a device in everybody's pocket in the country, where can you go? The logical step is to start chipping away at the other places where they still use non-cell phones. Offices are tough (you have PBXes and complex switching requirements), so instead the carriers are going for the remaining home phones.
To me it seems a bit ironic that the "smart home phone" -- a mythical central-hub unit that does voice, video, and text communication, plus provides news and other information feeds -- which has been a broken promise from wireline phone companies forliterallydecades, is finally going to be delivered... only the network behind it will be a wireless one, not POTS, and far from being the local telcos' salvation, it may be the final nail in their coffin. (That is, unless they really get over their reluctance and embrace a future of being bit-pushing broadband ISPs.)
You can buy unlocked phones in the U.S., too. On AT&T's and T-Mobile's networks, there's nothing preventing you from doing it. Verizon and the other CDMA carriers are a bit tougher, and you do admittedly get mostly older phones on the secondary market there, but that's what you get for going with a proprietary, non-standard technology.
I use T-Mobile and have bought my own GSM phones for years; sometimes I've chosen to buy phones that are a few years behind the bleeding edge because I'm a cheap bastard, but I certainly haven't been forced to. I think most Americans don't do this because they're addicted to the subsidy business model that the carriers promote in order to lock customers in. The subsidies have deflated their idea of what a phone ought to cost, down to a level that's far less than fair market value. Phones that are at least $100 are "free," and something like the iPhone 3G which is probably at least a $500 product (I think it goes for even more than that, sold legitimately unlocked in jurisdictions where the law requires that option), is "$200".
But if you want to buy an unlocked phone you can do that, and you can run whatever software you want to on it. On my Nokia E61, for instance, I have a WiFi tethering program (JoikuSpot -- it's awesome) and the phone has a SIP VOIP client and a VPN client built right into the operating system. And it has none of the remote-update or kill-switch "features" that seem to be de rigueur on branded smartphones. No bullshit tie-in to a proprietary application store or code-signing requirements, either -- you can download and run all the crap from the Internet you want. You can buy one right now, drop your SIM card in, and away you go.
If people buy subsidized and/or crippled phones through their cell carriers than they pretty much deserve the crippled pieces of shit that they get. Good phones without restrictions are there for the buying if you're willing to pay what they actually cost, and what people in other countries routinely pay.
Maybe possibly in your universe of infinite energy and ecology resources..."for any reason, ever". Yeah right. Shot down that brainfart argument in 2 seconds, right there.
Is that you, Timecube Guy? I have no idea what you're getting on about, but just to restate for clarity:
There's no reason to have the management interface exposed on the WAN side. No good reasons, anyway. The router developers leave it in there as an option so that you can do remote administration, but enabling it vastly increases the attack surface that someone has available to them. (You have to worry about a whole web+ssh server, probably thousands of lines of code that are difficult to upgrade and patch, instead of just the packet filter.)
If you really need the ability to remote administer the router, the way to do it is to forward a single port to a machine inside the LAN, one that you can easily keep patched and up to date, and then connect to it from the outside and use it to administer the router from the normal LAN-side interface. This keeps your external exposure minimized to a single system, keeps you on a nonstandard port of your choice, allows you to do much more sophisticated authentication than the router's interface generally allows (i.e. you can do publickey-only), and allows better logging.
Frankly I'd encourage developers of router firmware to remove the WAN-side management option completely, or at least bury it somewhere deep in the "Advanced Settings" type menus, and make clear that it's only something you should use when the router is being installed inside a LAN already.
If we all used $100 machines, that were 500mhz, and 10GB's of HD space etc, Microsoft will just create trimmed down versions to run on it, thus not getting rid of Microsoft.
Then they'd at least have to start competing on the merits of their software, rather than simply being able to shove it down the throats of all concerned, as a sort of entrance fee for getting a computer that plays well with the rest of the ecosystem.
There's nothing wrong with that; if Microsoft can produce software that people actually want to buy, versus feel that they have to buy because everyone else is using it, kudos to them. That's the sort of behavior that we should be encouraging.
A lot of smart people work for Microsoft (they do pay fairly well, after all) and they ought to be able to turn out some good stuff; that they seem to regularly turn out steaming piles of crap is a testament to what I can only imagine must be truly abysmal management. But if they were forced to really compete on a level playing field I suspect a fair amount of cool stuff could come out of there, if they put their collective minds to it. There is something to be said for being the largest software company in the world: it's not as though they don't have the capability.
(Just as a sidebar: Microsoft's Mac division actually used to produce some fairly nice products; I think they were most compelling when they weren't the dominant tools on the platform, and Mac users were more evenly split between Word/Claris/Nisus/etc. They've gotten a bit lazier in recent years, seemingly aiming just for parity with the PC version, but there were several versions in the past that had very unique features, like a synchronized audio/text notebook in Word -- I've still yet to find anything like it. And Microsoft's hardware, particularly their mice, have never been bad, probably because they've always had to compete with the rest of the market.)
Microsoft doesn't just hurt the rest of the IT industry with its dominance, it also handicaps itself -- albeit in a way it finds comfortable (and profitable). Companies are only ever as innovative as they need to be, and Microsoft's position has allowed it to be very lazy for a fairly long time.
IBM showed that it's possible for a former monopolist to re-invent itself and contribute to the same industry it once attempted to contain, so I have hope that Microsoft could do the same thing if they could kick the dependency on what's effectively a rent drawn from most of the world's desktop systems. They'll never do it willingly, but I think eventually it'll happen and they'll have no choice.
Trying to enforce policy by trying to make the clients only connect to a specific server is stupid; a much better way (and the way I've actually seen implemented successfully) is to use a standard client program, a standard server running inside the LAN, and then enforce policy at the corporate firewall to prevent a user from connecting their client to a public server.
This way you can use whatever client/server combo you want: Jabber, SILC, AIM-style, SameTime, etc.
The way I'd enforce the gateway policy is simply to block ALL traffic from machines inside to machines outside. Machines inside the network, save specifically-designated servers working on specifically designated ports, don't get to talk to machines outside. Period. If they want to communicate with the outside world, they do it through a protocol-specific proxy. That would make it fairly easy to block connections out to IM servers; you just configure the HTTP proxy to never allow connections to the known public servers for that IM client, and to any server except on well-known HTTP ports. That will keep 99% of users from doing anything.
It's not totally secure, of course -- a highly-motivated user could set up a relay or IM server of their own, running on their own server (which wouldn't be blacklisted), on a common HTTP port, and there'd be no way to detect it except via packet inspection. However most people who are likely to do that are going to be in IT already.
I've worked in a number of healthcare and financial institutions that do the total-firewall plus filtering proxy thing; it actually allows them to be a lot less restrictive with their endpoint policies than they would otherwise have to be. You don't have to obsess quite so much about locking down every possible setting of every possible local program on the client machine when there's no way for the machines to pass traffic outside the network except through a small number of closely-monitored application proxies.
The only downside to this approach is that it can be a real bitch to get working if you have any legacy (non-web) client/server apps that weren't set up to use a proxy; if you start punching whole-port holes in your firewall to accommodate stuff like that, you quickly end up with nothing but a false sense of security.
That would be nice, but it is not easy to do. The Linux distros that run on embedded routers are mostly set up to have only a single, root, user. DD-WRT is definitely this way, and I think Tomato is as well. It might be possible to rebuild it with multiple users but that is definitely not how it's designed right now.
Personally what I'd recommend is not having any of the router's management interfaces exposed to the WAN side of things, for any reason, ever. If you think you might need to administer the router remotely, set up a hardened system inside the LAN somewhere, forward a nonstandard port to sshd on it, and then log into that machine and do SOCKS port-forwarding to connect to the router. This is how I run my home network and it takes literally only a second or two longer to connect to the router this way, versus if I had it directly accessible.
That's a pretty terrible idea; I'm pretty pleased that the guy distributed the software as Python source and not as skeezy.exe files -- distributing the latter is just asking for virus propagation, since these files are by their nature going to get passed around by somewhat unconventional means, and normal safeguards against tampering, like posting an MD5 hash, aren't practical (since the original site may and probably will disappear).
Plus, distributing it this way ensures that everyone with a copy of the decryptor has a copy of the source; if most people had binaries and only a very few had source, it would make it much easier for Adobe to go after the few source-code copies, change the DRM system slightly, and basically seal the breach. When most users only have compiled binaries and not source code, you're as vulnerable as closed-source software to being taken out by a targeted series of lawsuits or some other campaign of intimidation. (And in doing so you make those lawsuits or intimidation much more likely, since any fool can see that it might actually work. It's to the developer's benefit to disseminate the code and the ideas it contains as widely as possible; in doing so they make themselves less of a big, fat target.)
Interpreted-only scripts are an ideal choice for this sort of thing. They're safe, they're basically self-documenting, they ensure source code dissemination, and frankly if push ever comes to shove, they give the developer a tiny bit more plausible deniability than he might otherwise have if he distributed binaries that were obviously meant to be a moron-friendly piracy tool.
I disagree completely with the quality assessment.
I have never viewed anything on a computer (and have no desire to), but I own a Roku hooked up to a 720p projector and the quality out of it is fantastic in HD mode. I have a standard 3Mbit cable modem connection from Comcast and it has never dropped out of HD mode on any show that has it as an option.
I can't compare the service to Blu-Ray (or HD-DVD) because I don't have a player, but it's an obvious step up from DVD. The SO and I watched the first season of Heroes on DVD, and recently started watching the second season in HD on the Roku, and have been very impressed at the difference. If you look closely and know what to look for, you can sometimes see compression artifacts, but it's better than most "HD" programming on digital cable.
The SD programming is inferior to a DVD but not by much; it's the sort of thing I'll notice but most non-geeks don't. It's better than NTSC (analog) cable, at least in my opinion. It's not bad for watching TV shows and 'popcorn flicks' that aren't all about the photography or visual spectacle.
If your only experience of Netflix's streaming service has been on a computer or through their browser-based service, I would give the Roku a fair shot and view it practically as a separate deal altogether.
I didn't give two squirts to the idea of streaming video until we got the Roku; now I'm open to the possibility that it may be the future if they can knock down or subsidize the initial investment. I wouldn't be surprised if within the next few years, we start to see Netflix do some sort of cellphone-esque contracting program, giving you a free Roku (or other streaming box) in return for a 1 or 2-year commitment.
That's great, for people who live in those states. Until we have a national system though, we will continue to need toll booths and continue to have drivers using them.
Not really -- that's just what the article is about. Once a critical mass of users have transponders, you can just eliminate the human toll-takers, and go to a fully-automated system. If a car goes through without a transponder (or with a broken one, or one wrapped in tinfoil, or whatever), the car, license plate, and driver are all photographed and the registered owner of the car (really, the registered owner of that plate number) gets a bill in the mail. (A bad system just would just photograph the plate, but better systems have additional cameras for context, which is helpful in detecting fraud.)
It's not a perfect system -- it's possible to swap or forge plates, or make plates unreadable with lighting systems or other tricks -- but it's probably cheaper than paying somebody to sit in a booth and collect tolls.
Plus, if you make the toll that you pay without a transponder significantly higher (or just less convenient, or both) than the toll you pay with one, then you don't even need to make transponders mandatory. People will buy and install them voluntarily to save the money and time. This is the case on a lot of automated toll roads right now. The 'Dulles Toll Road' and its extension, the 'Dulles Greenway,' outside DC is almost entirely automatic; many exits never have a human operator. If you don't have an EZ-Pass transponder, you have to use an ATM-like machine to pay with a credit card. You are basically not supposed to use these exits without a credit card or an EZ-Pass transponder (and there are quite a few warning signs to this effect), but if you do, you just get a bill in the mail. I assume this bill involves a fine or surcharge to discourage doing it repeatedly, but I'm not quite sure.
Personally I don't have much of a problem with this, but I grew up in the Northeast where toll roads were just a fact of life. If you want to go somewhere, you should be prepared to pay the tolls; it's a good way of making sure people who use infrastructure pay the bulk of its associated maintenance expenses. (The only problem is when tolls become a general revenue source instead of just a way of funding the upkeep of a particular road/bridge/etc.) I think a lot of people are fairly sick of paying for highways and commuter roads that they don't use, and which just contribute to massive sprawl anyway; toll roads not only decrease the tax burden of infrastructure maintenance, but they also decrease pollution, encourage carpooling, and encourage living closer to work rather than in exurbs. They also help build transportation costs into the price paid by consumers for goods, rather than hiding it in taxes where it can be much more distortive.
The issue of whether something is or isn't infringement depends on whether it would be confusing, and cause consumers to assume that one product is produced by another company -- essentially free-riding on the other's reputation.
My understanding is that the Apple Records vs. Apple Computer suit never got to the point of determining whether that was the case. If the suit had gone forward, a judge would have needed to rule on it one way or the other. But before that happened they arrived at some sort of deal, in which Apple Computer agreed to stay out of the music business and Apple Records out of computers. That deal persisted until 1997, when Apple Computer basically bought Apple Records out and acquired sole ownership of the "Apple" marque.
As for TCP/IP, that would be nice to allow diskless boots. PXE anyone?
Not only that, but a minimal TCP/IP stack in the BIOS would remove much of the reason for purchasing expensive remote-management add-in cards (and sacrificing PCI slots as a result) in order to perform hard reboots and view the boot console over a network. (Those cards are in themselves an alternative to even more expensive out-of-band management systems, using either the serial port or proprietary hardware interfaces.)
Although there would be some obvious security concerns with such a system -- you wouldn't want to enable it by default on non-headless systems, clearly -- it would be a pretty neat feature and would go a long way towards making commodity servers (built up from semi-generic components, like Rackspace's) feature competitive with the big names. And it'd be nice, just in general, to get a standardized approach to true headless operation that was vendor-agnostic and didn't require the purchase of additional addon parts.
It would be better not to put them all in one place.
If you are going to get 200 CDs pressed, you'd do well to keep a few dozen of them in your capsule, and distribute the rest.
If it's a project at a school, insert a copy of the CD in the back of every copy of that year's yearbook. Make sure to send several copies of the yearbook with the CD insert to all the local libraries in the area. Chances are that will ensure that at least one of them will survive for 50 years. At least in my area, the libraries have yearbooks from all the local schools going back to the 40s, which I presume is when they started producing them. (They have class photos going back a lot further than that, too.)
In general, if you can make information interesting (or at least package it with something interesting), you can practically let other people do all the archival work for you.
I suspect most recent community-college grads would be more familiar with portable electronics and the marketplace in general than this guy comes off being.
Only someone well-insulated from the outside world, in a position where their incompetence is somehow mistaken for an asset, could produce a product while knowing so little about the people they're trying to sell it to.
You're making something of a ridiculous comparison.
Nobody is planning on attacking an F-22 with Predator. That's not the purpose of the Predator, or of any other current UAV. It's not what they're designed for, and it makes no sense. Criticizing them on that basis is like arguing that you can't shoot and disable a tank with a handgun; very true, but only an idiot would try. It doesn't really say anything about the fundamental design of the handgun, or whether bigger guns operating on the same principles might not be useful against the tank.
The F-22 is the pinnacle of more than 100 years of manned flight experience, and it represents an investment of trillions of dollars over the course of decades by the U.S. alone (for it and its antecedents, which it builds off of). It's a stunning machine.
Current UAVs are the very bleeding edge of an emerging technology that wasn't realistically possible until perhaps a decade ago. Someday they'll probably be regarded as the Sopwith Camels of unmanned aviation (and perhaps only then if someone is speaking kindly).
Given that manned aviation is starting to run into some fundamental limitations (amount of force the human body can bear, minimum size of an adult human, need for oxygen and sleep), plus it has political concerns (risk of dead or captured pilots and resulting changes in public support for military action), which UAVs simply do not have, it seems very likely that an increasing amount of resources will be spent on unmanned platforms rather than manned.
A great many of the advantages currently enjoyed by manned aircraft will probably be transferred to UAVs (there's no reason why you can't build a UAV with a low radar cross-section, for example), and it seems arguable at best that the one difference they will always have -- the presence of a human operator in the manned one -- will always translate into combat superiority. There seem to be many situations where that could be a serious liability rather than an advantage.
The Global Hawk has a fairly autonomous flight-control system. It is a reconnaissance, rather than a ground-attack, aircraft. (Basically its role is to do what the U-2 does, only with less chance of a Gary Powers situation.)
I think there has been some thought put to arming the Global Hawk, but it wouldn't be terribly effective for that. My suspicion is that future UAVs will take on combat roles more directly. Long range bombing, perhaps someday even replacing the B-2 fleet, seems like a good match, since those missions are typically well-scripted in advance and very tough on pilots due to their length.
Serious question: is there really any advantage to all the "lossless" formats that have popped up, versus just taking an uncompressed AIFF or WAV file (44.1kHz PCM bitstream dumped into a minimal container) and compressing it with something like Zip/GZip/BZip2 inside a Zip or TAR container?
There's been quite the proliferation of lossless formats (FLAC, Monkey's Audio, Apple Lossless, etc.), all incompatible and basically none seemingly getting a critical mass of users, outside of particular niche markets. But it seems like WAV+BZIP or something like it would be pretty trivial to implement and non-proprietary, so you'd be able to play it just about anywhere. Plus, just about anyone would be able to create them, so the chicken/egg problem would be solved, and you wouldn't have to depend on little self-bootstrapping communities of users.
You wouldn't have to give up metadata, or decompress in order to read it; you can smack whatever you want onto (the front of, I think? maybe it's the back of) a Zip container file and it will just be ignored.
It seems hard to imagine that the gains from using a special-purpose algorithm that's tuned for audio data is really significant enough to outweigh the interoperability disadvantages of creating yet another audio file format, versus just using a well-known and freely-available general-purpose file compression library.
Slashdot Mirror
How hot does the engine run with that much extra compression? I'd imagine it'd be pretty rough on the cylinder walls if you did it for anything longer than 1/4mi dragging.
I don't think it's beyond the realm of engineering or anything -- maybe we need to look back into ceramic composite cylinders, which I think was a focus of research back in the 70s or 80s -- but I'd be surprised if you could take an engine designed for 87 octane gasoline and increase the compression to what's optimal for E85, without increasing the wear pretty substantially.
I can't believe this could even be an issue. Why don't your lawmakers make it illegal for those responsible for financing medical care to discriminate against people with illnesses?
Because at any given time, most voters either are, or think that they are, healthy; thus they're pretty receptive to arguments that eliminating pre-existing condition restrictions would raise their own costs. Basically, nobody who's healthy wants to pay for anybody else's healthcare.
Of course, when those people get sick it's a different story. But as long as there are more people who think they're healthy than people who are sick, the 'healthy' people discriminate against the 'sick' ones.
As the population ages, however, more people have moved from 'healthy' to 'sick' (or at least from seeing health insurance as a cost center to be minimized, to a profit center that they benefit from), and there's beginning to be a corresponding shift in attitudes with regards to insurance. Exactly how far this shift in attitudes will go and what the actual political effect of it will be, remains to be seen. I am personally quite doubtful that it will amount to much of anything beyond a tweaking of the system already in existence, but I'm admittedly hugely cynical about the political process in the U.S.
There's no point in arguing with -- much less negotiating or compromising with -- someone whose objection to your conduct is based on religious or moral grounds. They're not just going to give up because you tried to meet them in the middle; they're just going to wait until the time is right and then finish you off.
I don't think you can do that without violating the HDMI spec. The whole point of HDMI is to prevent you from having unencrypted HD video; if you could just toss on an adapter to go from HDMI to DVI (the latter is unencrypted by definition), then HDMI wouldn't need to exist.
What you could do would be eliminate HDMI and just have DVI, and then people who want HDMI use a DVI -> HDMI cable (which exist); this direction is trivial because HDMI devices will play DVI, IIRC. But this is sort of a no-go because people wouldn't buy a computer that "didn't do HDMI," plus at least on Windows there are probably applications that won't work without the encrypted signal path provided by HDMI. (On Linux I don't think that will ever be the case or matter.)
What the heck are baby monitors doing on the 2.4GHz ISM band anyway? It's not like they're a new invention, unknown before that band opened up; they've existed for decades and everyone had pretty much worked around them, on 49 MHz. From a quick Google search I can see that there are still lots of monitors that operate in that range, so I'm mystified why they're on 2.4.
Is this just "gigahertz are better than megahertz" marketing, like happened with cordless phones? I can't see any good reason to go to 2.4; it doesn't penetrate structures nearly as well as 49MHz does, and 49 has all the bandwidth you need for audio.
What the FCC (and similar organizations in other countries) ought to do is give baby monitors and similar "dumb" devices a band to work on, with defined channels (so you could adjust yours if your neighbor bought one) -- I think this may already all be done on 49 -- and tell them to stay there and stay off of the 2.4 ISM. Reserve 2.4GHz for smarter devices that operate in spread-spectrum modes and don't crap all over each other quite so badly.
It certainly could, but it doesn't seem like YouTube wants to do that. They're doing the absolute minimum required as a result of S. Korea's asinine new law -- if users say they're not from S.K., then it's not YouTube's problem anymore.
I suppose the S.K. government could try to force YouTube to do IP-based geolocation on everyone regardless of what country they specify, but that would be a pretty major escalation; they'd basically be in the position of having to threaten Chinese-style censorship in order to get compliance. I'd hope that would backfire.
Still, the whole thing is unusually ballsy given that Google usually seems to have little problem handing over user data to any government who comes knocking.
Question regarding the reliability of fanless computers: wouldn't a fanless system eventually overheat and die if it wasn't dusted periodically?
It seems like 10 or 15 years of dust in a typical office environment, even without fans moving a lot of air around, could seriously impair the effectiveness of heatsinks and cause failure.
If you went this route and really wanted zero-maintenance, I'd think you'd need to factor in dust and over-engineer the heatsinks significantly, so that you'd have the radiative capacity to stay below temperature cutoffs for the full lifetime of the machine.
I wonder if somewhere, somebody has tables showing dust buildup and its effects on electrical equipment over time in typical office environments...seems like it must be a well-thought-over issue.
> Tapes are slow, unreliable and expensive. I would not use them for any purpose.
I'll give you the slow and expensive part, but unreliable? That I'm not sure I'd agree with at all.
With the possible exception of helical-scan DAT, which was a good idea poorly implemented in many cases, tape drives and data stored on tape is extremely reliable. You can record data to a magnetic tape, put it on a shelf, and it will still be readable in 20 years. Heck, it'll probably still be readable in 50 or 100 years; the limiting factor is really the drive, not the tape. And enterprise-grade tape drives (practically all that's being manufactured anymore; they've pretty much cut it out with the cheap DATs) are built quite well.
Hard-drive based backups are very nice and I do think they're appropriate for most users, but tapes still have a place. If you need to store a lot of data either offline or nearline, the operating cost of a tape library is very low. (They don't require any electricity just sitting there, and you don't have to worry about periodically spinning them up or anything.) For archival purposes they are also excellent.
I'd perhaps even concede that tapes are a poor "backup" media, but an excellent "archival" one, if you were to split those functions out separately.
Where I would never use tape is for nightly backups that are just going to be overwritten the next day, but for saving data for the long term they are a good low-maintenance option.
I always wanted a desktop cellphone.
Cell phones designed for home use are sort of the 'next big thing,' at least to the cell companies. Each of the 3 major carriers seems to either have one out already, or in the works.
It makes sense -- right now, they've pretty much saturated the market for cell phones: I don't know a man, woman, or child in the U.S. that wants a cell phone that doesn't have one (people who truly can't afford them excepted, although the barrier to entry is getting lower by the month; there are some prepaid phones that verge on being disposable they're so cheap). Once you've put a device in everybody's pocket in the country, where can you go? The logical step is to start chipping away at the other places where they still use non-cell phones. Offices are tough (you have PBXes and complex switching requirements), so instead the carriers are going for the remaining home phones.
To me it seems a bit ironic that the "smart home phone" -- a mythical central-hub unit that does voice, video, and text communication, plus provides news and other information feeds -- which has been a broken promise from wireline phone companies for literally decades, is finally going to be delivered ... only the network behind it will be a wireless one, not POTS, and far from being the local telcos' salvation, it may be the final nail in their coffin. (That is, unless they really get over their reluctance and embrace a future of being bit-pushing broadband ISPs.)
You can buy unlocked phones in the U.S., too. On AT&T's and T-Mobile's networks, there's nothing preventing you from doing it. Verizon and the other CDMA carriers are a bit tougher, and you do admittedly get mostly older phones on the secondary market there, but that's what you get for going with a proprietary, non-standard technology.
I use T-Mobile and have bought my own GSM phones for years; sometimes I've chosen to buy phones that are a few years behind the bleeding edge because I'm a cheap bastard, but I certainly haven't been forced to. I think most Americans don't do this because they're addicted to the subsidy business model that the carriers promote in order to lock customers in. The subsidies have deflated their idea of what a phone ought to cost, down to a level that's far less than fair market value. Phones that are at least $100 are "free," and something like the iPhone 3G which is probably at least a $500 product (I think it goes for even more than that, sold legitimately unlocked in jurisdictions where the law requires that option), is "$200".
But if you want to buy an unlocked phone you can do that, and you can run whatever software you want to on it. On my Nokia E61, for instance, I have a WiFi tethering program (JoikuSpot -- it's awesome) and the phone has a SIP VOIP client and a VPN client built right into the operating system. And it has none of the remote-update or kill-switch "features" that seem to be de rigueur on branded smartphones. No bullshit tie-in to a proprietary application store or code-signing requirements, either -- you can download and run all the crap from the Internet you want. You can buy one right now, drop your SIM card in, and away you go.
If people buy subsidized and/or crippled phones through their cell carriers than they pretty much deserve the crippled pieces of shit that they get. Good phones without restrictions are there for the buying if you're willing to pay what they actually cost, and what people in other countries routinely pay.
Is that you, Timecube Guy? I have no idea what you're getting on about, but just to restate for clarity:
There's no reason to have the management interface exposed on the WAN side. No good reasons, anyway. The router developers leave it in there as an option so that you can do remote administration, but enabling it vastly increases the attack surface that someone has available to them. (You have to worry about a whole web+ssh server, probably thousands of lines of code that are difficult to upgrade and patch, instead of just the packet filter.)
If you really need the ability to remote administer the router, the way to do it is to forward a single port to a machine inside the LAN, one that you can easily keep patched and up to date, and then connect to it from the outside and use it to administer the router from the normal LAN-side interface. This keeps your external exposure minimized to a single system, keeps you on a nonstandard port of your choice, allows you to do much more sophisticated authentication than the router's interface generally allows (i.e. you can do publickey-only), and allows better logging.
Frankly I'd encourage developers of router firmware to remove the WAN-side management option completely, or at least bury it somewhere deep in the "Advanced Settings" type menus, and make clear that it's only something you should use when the router is being installed inside a LAN already.
Then they'd at least have to start competing on the merits of their software, rather than simply being able to shove it down the throats of all concerned, as a sort of entrance fee for getting a computer that plays well with the rest of the ecosystem.
There's nothing wrong with that; if Microsoft can produce software that people actually want to buy, versus feel that they have to buy because everyone else is using it, kudos to them. That's the sort of behavior that we should be encouraging.
A lot of smart people work for Microsoft (they do pay fairly well, after all) and they ought to be able to turn out some good stuff; that they seem to regularly turn out steaming piles of crap is a testament to what I can only imagine must be truly abysmal management. But if they were forced to really compete on a level playing field I suspect a fair amount of cool stuff could come out of there, if they put their collective minds to it. There is something to be said for being the largest software company in the world: it's not as though they don't have the capability.
(Just as a sidebar: Microsoft's Mac division actually used to produce some fairly nice products; I think they were most compelling when they weren't the dominant tools on the platform, and Mac users were more evenly split between Word/Claris/Nisus/etc. They've gotten a bit lazier in recent years, seemingly aiming just for parity with the PC version, but there were several versions in the past that had very unique features, like a synchronized audio/text notebook in Word -- I've still yet to find anything like it. And Microsoft's hardware, particularly their mice, have never been bad, probably because they've always had to compete with the rest of the market.)
Microsoft doesn't just hurt the rest of the IT industry with its dominance, it also handicaps itself -- albeit in a way it finds comfortable (and profitable). Companies are only ever as innovative as they need to be, and Microsoft's position has allowed it to be very lazy for a fairly long time.
IBM showed that it's possible for a former monopolist to re-invent itself and contribute to the same industry it once attempted to contain, so I have hope that Microsoft could do the same thing if they could kick the dependency on what's effectively a rent drawn from most of the world's desktop systems. They'll never do it willingly, but I think eventually it'll happen and they'll have no choice.
Trying to enforce policy by trying to make the clients only connect to a specific server is stupid; a much better way (and the way I've actually seen implemented successfully) is to use a standard client program, a standard server running inside the LAN, and then enforce policy at the corporate firewall to prevent a user from connecting their client to a public server.
This way you can use whatever client/server combo you want: Jabber, SILC, AIM-style, SameTime, etc.
The way I'd enforce the gateway policy is simply to block ALL traffic from machines inside to machines outside. Machines inside the network, save specifically-designated servers working on specifically designated ports, don't get to talk to machines outside. Period. If they want to communicate with the outside world, they do it through a protocol-specific proxy. That would make it fairly easy to block connections out to IM servers; you just configure the HTTP proxy to never allow connections to the known public servers for that IM client, and to any server except on well-known HTTP ports. That will keep 99% of users from doing anything.
It's not totally secure, of course -- a highly-motivated user could set up a relay or IM server of their own, running on their own server (which wouldn't be blacklisted), on a common HTTP port, and there'd be no way to detect it except via packet inspection. However most people who are likely to do that are going to be in IT already.
I've worked in a number of healthcare and financial institutions that do the total-firewall plus filtering proxy thing; it actually allows them to be a lot less restrictive with their endpoint policies than they would otherwise have to be. You don't have to obsess quite so much about locking down every possible setting of every possible local program on the client machine when there's no way for the machines to pass traffic outside the network except through a small number of closely-monitored application proxies.
The only downside to this approach is that it can be a real bitch to get working if you have any legacy (non-web) client/server apps that weren't set up to use a proxy; if you start punching whole-port holes in your firewall to accommodate stuff like that, you quickly end up with nothing but a false sense of security.
That would be nice, but it is not easy to do. The Linux distros that run on embedded routers are mostly set up to have only a single, root, user. DD-WRT is definitely this way, and I think Tomato is as well. It might be possible to rebuild it with multiple users but that is definitely not how it's designed right now.
Personally what I'd recommend is not having any of the router's management interfaces exposed to the WAN side of things, for any reason, ever. If you think you might need to administer the router remotely, set up a hardened system inside the LAN somewhere, forward a nonstandard port to sshd on it, and then log into that machine and do SOCKS port-forwarding to connect to the router. This is how I run my home network and it takes literally only a second or two longer to connect to the router this way, versus if I had it directly accessible.
That's a pretty terrible idea; I'm pretty pleased that the guy distributed the software as Python source and not as skeezy .exe files -- distributing the latter is just asking for virus propagation, since these files are by their nature going to get passed around by somewhat unconventional means, and normal safeguards against tampering, like posting an MD5 hash, aren't practical (since the original site may and probably will disappear).
Plus, distributing it this way ensures that everyone with a copy of the decryptor has a copy of the source; if most people had binaries and only a very few had source, it would make it much easier for Adobe to go after the few source-code copies, change the DRM system slightly, and basically seal the breach. When most users only have compiled binaries and not source code, you're as vulnerable as closed-source software to being taken out by a targeted series of lawsuits or some other campaign of intimidation. (And in doing so you make those lawsuits or intimidation much more likely, since any fool can see that it might actually work. It's to the developer's benefit to disseminate the code and the ideas it contains as widely as possible; in doing so they make themselves less of a big, fat target.)
Interpreted-only scripts are an ideal choice for this sort of thing. They're safe, they're basically self-documenting, they ensure source code dissemination, and frankly if push ever comes to shove, they give the developer a tiny bit more plausible deniability than he might otherwise have if he distributed binaries that were obviously meant to be a moron-friendly piracy tool.
I disagree completely with the quality assessment.
I have never viewed anything on a computer (and have no desire to), but I own a Roku hooked up to a 720p projector and the quality out of it is fantastic in HD mode. I have a standard 3Mbit cable modem connection from Comcast and it has never dropped out of HD mode on any show that has it as an option.
I can't compare the service to Blu-Ray (or HD-DVD) because I don't have a player, but it's an obvious step up from DVD. The SO and I watched the first season of Heroes on DVD, and recently started watching the second season in HD on the Roku, and have been very impressed at the difference. If you look closely and know what to look for, you can sometimes see compression artifacts, but it's better than most "HD" programming on digital cable.
The SD programming is inferior to a DVD but not by much; it's the sort of thing I'll notice but most non-geeks don't. It's better than NTSC (analog) cable, at least in my opinion. It's not bad for watching TV shows and 'popcorn flicks' that aren't all about the photography or visual spectacle.
If your only experience of Netflix's streaming service has been on a computer or through their browser-based service, I would give the Roku a fair shot and view it practically as a separate deal altogether.
I didn't give two squirts to the idea of streaming video until we got the Roku; now I'm open to the possibility that it may be the future if they can knock down or subsidize the initial investment. I wouldn't be surprised if within the next few years, we start to see Netflix do some sort of cellphone-esque contracting program, giving you a free Roku (or other streaming box) in return for a 1 or 2-year commitment.
That's great, for people who live in those states. Until we have a national system though, we will continue to need toll booths and continue to have drivers using them.
Not really -- that's just what the article is about. Once a critical mass of users have transponders, you can just eliminate the human toll-takers, and go to a fully-automated system. If a car goes through without a transponder (or with a broken one, or one wrapped in tinfoil, or whatever), the car, license plate, and driver are all photographed and the registered owner of the car (really, the registered owner of that plate number) gets a bill in the mail. (A bad system just would just photograph the plate, but better systems have additional cameras for context, which is helpful in detecting fraud.)
It's not a perfect system -- it's possible to swap or forge plates, or make plates unreadable with lighting systems or other tricks -- but it's probably cheaper than paying somebody to sit in a booth and collect tolls.
Plus, if you make the toll that you pay without a transponder significantly higher (or just less convenient, or both) than the toll you pay with one, then you don't even need to make transponders mandatory. People will buy and install them voluntarily to save the money and time. This is the case on a lot of automated toll roads right now. The 'Dulles Toll Road' and its extension, the 'Dulles Greenway,' outside DC is almost entirely automatic; many exits never have a human operator. If you don't have an EZ-Pass transponder, you have to use an ATM-like machine to pay with a credit card. You are basically not supposed to use these exits without a credit card or an EZ-Pass transponder (and there are quite a few warning signs to this effect), but if you do, you just get a bill in the mail. I assume this bill involves a fine or surcharge to discourage doing it repeatedly, but I'm not quite sure.
Personally I don't have much of a problem with this, but I grew up in the Northeast where toll roads were just a fact of life. If you want to go somewhere, you should be prepared to pay the tolls; it's a good way of making sure people who use infrastructure pay the bulk of its associated maintenance expenses. (The only problem is when tolls become a general revenue source instead of just a way of funding the upkeep of a particular road/bridge/etc.) I think a lot of people are fairly sick of paying for highways and commuter roads that they don't use, and which just contribute to massive sprawl anyway; toll roads not only decrease the tax burden of infrastructure maintenance, but they also decrease pollution, encourage carpooling, and encourage living closer to work rather than in exurbs. They also help build transportation costs into the price paid by consumers for goods, rather than hiding it in taxes where it can be much more distortive.
The issue of whether something is or isn't infringement depends on whether it would be confusing, and cause consumers to assume that one product is produced by another company -- essentially free-riding on the other's reputation.
My understanding is that the Apple Records vs. Apple Computer suit never got to the point of determining whether that was the case. If the suit had gone forward, a judge would have needed to rule on it one way or the other. But before that happened they arrived at some sort of deal, in which Apple Computer agreed to stay out of the music business and Apple Records out of computers. That deal persisted until 1997, when Apple Computer basically bought Apple Records out and acquired sole ownership of the "Apple" marque.
As for TCP/IP, that would be nice to allow diskless boots. PXE anyone?
Not only that, but a minimal TCP/IP stack in the BIOS would remove much of the reason for purchasing expensive remote-management add-in cards (and sacrificing PCI slots as a result) in order to perform hard reboots and view the boot console over a network. (Those cards are in themselves an alternative to even more expensive out-of-band management systems, using either the serial port or proprietary hardware interfaces.)
Although there would be some obvious security concerns with such a system -- you wouldn't want to enable it by default on non-headless systems, clearly -- it would be a pretty neat feature and would go a long way towards making commodity servers (built up from semi-generic components, like Rackspace's) feature competitive with the big names. And it'd be nice, just in general, to get a standardized approach to true headless operation that was vendor-agnostic and didn't require the purchase of additional addon parts.
It would be better not to put them all in one place.
If you are going to get 200 CDs pressed, you'd do well to keep a few dozen of them in your capsule, and distribute the rest.
If it's a project at a school, insert a copy of the CD in the back of every copy of that year's yearbook. Make sure to send several copies of the yearbook with the CD insert to all the local libraries in the area. Chances are that will ensure that at least one of them will survive for 50 years. At least in my area, the libraries have yearbooks from all the local schools going back to the 40s, which I presume is when they started producing them. (They have class photos going back a lot further than that, too.)
In general, if you can make information interesting (or at least package it with something interesting), you can practically let other people do all the archival work for you.
I propose starting a new anti-virus company that will focus on dates for crackers rather than OS security.
I think you'll find it's cheaper just to deal with the malware.
I suspect most recent community-college grads would be more familiar with portable electronics and the marketplace in general than this guy comes off being.
Only someone well-insulated from the outside world, in a position where their incompetence is somehow mistaken for an asset, could produce a product while knowing so little about the people they're trying to sell it to.
I vote "Executive MBA Program" grad. :)
You're making something of a ridiculous comparison.
Nobody is planning on attacking an F-22 with Predator. That's not the purpose of the Predator, or of any other current UAV. It's not what they're designed for, and it makes no sense. Criticizing them on that basis is like arguing that you can't shoot and disable a tank with a handgun; very true, but only an idiot would try. It doesn't really say anything about the fundamental design of the handgun, or whether bigger guns operating on the same principles might not be useful against the tank.
The F-22 is the pinnacle of more than 100 years of manned flight experience, and it represents an investment of trillions of dollars over the course of decades by the U.S. alone (for it and its antecedents, which it builds off of). It's a stunning machine.
Current UAVs are the very bleeding edge of an emerging technology that wasn't realistically possible until perhaps a decade ago. Someday they'll probably be regarded as the Sopwith Camels of unmanned aviation (and perhaps only then if someone is speaking kindly).
Given that manned aviation is starting to run into some fundamental limitations (amount of force the human body can bear, minimum size of an adult human, need for oxygen and sleep), plus it has political concerns (risk of dead or captured pilots and resulting changes in public support for military action), which UAVs simply do not have, it seems very likely that an increasing amount of resources will be spent on unmanned platforms rather than manned.
A great many of the advantages currently enjoyed by manned aircraft will probably be transferred to UAVs (there's no reason why you can't build a UAV with a low radar cross-section, for example), and it seems arguable at best that the one difference they will always have -- the presence of a human operator in the manned one -- will always translate into combat superiority. There seem to be many situations where that could be a serious liability rather than an advantage.
Huh? Which UAVs are piloted by AIs?
The Global Hawk has a fairly autonomous flight-control system. It is a reconnaissance, rather than a ground-attack, aircraft. (Basically its role is to do what the U-2 does, only with less chance of a Gary Powers situation.)
I think there has been some thought put to arming the Global Hawk, but it wouldn't be terribly effective for that. My suspicion is that future UAVs will take on combat roles more directly. Long range bombing, perhaps someday even replacing the B-2 fleet, seems like a good match, since those missions are typically well-scripted in advance and very tough on pilots due to their length.
Serious question: is there really any advantage to all the "lossless" formats that have popped up, versus just taking an uncompressed AIFF or WAV file (44.1kHz PCM bitstream dumped into a minimal container) and compressing it with something like Zip/GZip/BZip2 inside a Zip or TAR container?
There's been quite the proliferation of lossless formats (FLAC, Monkey's Audio, Apple Lossless, etc.), all incompatible and basically none seemingly getting a critical mass of users, outside of particular niche markets. But it seems like WAV+BZIP or something like it would be pretty trivial to implement and non-proprietary, so you'd be able to play it just about anywhere. Plus, just about anyone would be able to create them, so the chicken/egg problem would be solved, and you wouldn't have to depend on little self-bootstrapping communities of users.
You wouldn't have to give up metadata, or decompress in order to read it; you can smack whatever you want onto (the front of, I think? maybe it's the back of) a Zip container file and it will just be ignored.
It seems hard to imagine that the gains from using a special-purpose algorithm that's tuned for audio data is really significant enough to outweigh the interoperability disadvantages of creating yet another audio file format, versus just using a well-known and freely-available general-purpose file compression library.