I don't see how this would make it any easier for that. If you're doing the lookup using a DNS resolver that's under the jurisdiction of the government that wants the site blocked, then all they have to do is order whoever runs that DNS resolver (typically this would be "every ISP in the country") to block the domain at the DNS level. The ISPs can fight it out in court or whatever, but if the ruling is upheld either they block it as instructed, or go to jail. You don't need to be forwarding the client's IP address for this to work.
If the client is using a DNS resolver out of the jurisdiction of the country, then you're back to standard network filtering practices. Either you order the ISPs/carriers to prevent users within the country from using DNS servers outside of it, or you have them transparently intercept and modify certain responses. But again, the presence or absence of the client's IP address in the forwarded request doesn't matter.
The only one who would potentially receive extra information with this proposal is whoever operates the origin DNS servers. And if they're under the jurisdiction of the country that wants their site banned, well; just go in there and seize the equipment used to run the site and arrest the people responsible for it.
DNS-based backlists. You look up the address or hostname of the sender in a different domain, and the "address" in the response indicates if the thing you're looking up is listed (and potentially, why it's listed). But it's not a real address and you never connect to it.
SPF and anything else implemented in a TXT record can be used in similar ways. I think DNS signing attaches the keys to DNS records, as well.
Not really sure if having the true client IP address exposed matters in either case, but there are applications for DNS that don't result in the client connecting to the resolved address.
From a technical point of view, I dislike anything that implicitly disallows caching of responses. The only way having the client IP forwarded in the recursive lookup makes sense is if you assume that every single lookup will make its way to the origin servers (i.e. ridiculously low TTLs). A lot of things we seem to be doing these days (dynamic sites with different content based on your IP address etc.) seems to be working towards making it much harder to build resilient and performant sites.
The problem is you need to invest a lot of time, money and expertise into setting something like that. For a big shop like yours, that's no problem - the cost of initial setup is easily justified by the fact you have to manage 60k+ desktops and over 2,000 apps, and doing that manually would cost a fortune.
Most of us aren't that large though. We've got maybe 150 desktops/laptops, which is enough to make managing them manually impractical, but not enough to justify purchasing and learning systems management and package management software and the ins and outs of crafting your own package for each application and so on.
You say that "Firefox is just another app to us", but I'm sure you (or someone) spent a long time figuring out how to pull apart the installer and repackage it for your environment and to have everything working for the users but without giving them too much control over bits you want/need to manage centrally, and so on. Again, if you're already set up and have the knowledge of doing that for thousands of other apps, it's not too big a deal. But for us, nobody has that knowledge, and even if they did, nobody has the time to sit around working out how to repackage the application of the month; especially when it's only going to be required by a handful of people.
So either you need to buy some fantastic systems management software ($$$) and hope the vendor supplies packages/scripts/instructions for packaging the apps you use; or you buy packaging tools and learn to do it yourself ($$ + time), or you just use the stuff the more-or-less works out of the box ($). It's no surprise then that most smaller shops use Microsoft's software across the board, and then manually manage installs of additional software in the few cases where they're really needed.
SMTP doesn't support resuming incomplete transfers, so if they want to send/receive a large message they have to hope to get an uninterrupted link long enough to transfer the whole thing in one go. Whether or not their current copying method does resume is another question, but there's no reason it couldn't.
Additionally, SMTP set-up is a transactional process, which adds a time cost to each and every message you want to transfer. Since you've got low bandwidth, you probably don't want to have many simultaneous transfers either, which would be the normal way of mitigating that cost. A bulk copy means you only incur that delay during the initial setup, and the copy itself can make use of wide windows and the usual methods for dealing with high latency.
I'm assuming of course that they don't have a more-or-less continuous connection, and have limited windows within which you can send/receive emails - like the good ol' dialup days. Also, people didn't send HTML mail with funny pictures embedded when we had 1200bps modems. Sure, the astronauts could get by with text-only emails which would make the bandwidth requirements tiny, but that'd take half the fun out of having email in space, wouldn't it?
You're thinking about it from a tech geek perspective: wouldn't it be cool to have a NASAmail system in space?! OMG!
Think of it from a "managing the space mission" perspective: why do they even need email in space? What value does it add to the mission? The answer is, very little. So if a simple, cheap, off-the-shelf type of solution that fits within the parameters (low bandwidth, doesn't interfere with other operations, etc.) can't be found -- the answer would be, no email. Most likely, they don't get the latest hi-def movies, either.
They're astronauts. They're in space to do experiments we can't do on the ground, and things like that. Email isn't part of the mission.
I think the reason they'd do it this is way is latency. It's probably much more efficient to copy the OST file each way once, than it is to let Outlook or Exchange manage the synchronisation itself. More to the point, it's probably a bit more reliable, in that either it's synchronised (copied) or it's not. Outlook is pretty terrible to use on a flakey connection, and I don't think Exchange - Exchange communication would be much better. Additionally, you can use compression and/or differential copying along with the knowledge that it's a one-way, high-latency process to make the most effective use of your limited bandwidth. e.g. they can probably resume an incomplete transfer from where it left off, rather than restarting.
their hack is entirely tied to their vendors
I don't think their solution particularly times them to Microsoft. I mean yes they're using proprietary features specific to Outlook, but presumably they're doing it because they're already running Exchange and/or Outlook was the preferred mail client, anyway. Conceptually, there's no difference between moving an offline cache (the.ost) back and forth and moving a maildir or mbox or whatever. Pretty much every email client will support having two "locations", one which is local and one which is transferred back and forth, and allow the astronauts to drag-and-drop between the two. So if they wanted to switch, there's no reason they couldn't - they just go from copying an.ost to copying whatever format the new mail client prefers its mail to be in.
Finally - reading and writing email isn't the reason they're in space, so a system that's simple and easily understood and doesn't require too much in the way of cleverness is exactly what you'd want. The only thing that I think is a bit crappy about their solution is that they have distinct "send mail" and "receive mail" cycles, when it wouldn't have been that much harder to have a single "sync mail" cycle instead.
Personally, I would've gone with something much more complex - I never thought of using the Outlook cache in this manner, even though I have sometimes done similar things so I "knew" it was possible. I'm actually a bit impressed by the simple elegance of it.
First: why should new technology aspire to be no better than old technology? What's wrong with having or wanting a faster/instant refresh?
Second: the delay on an e-reader is probably more noticeable because you're waiting for it. If you're turning the page of a book, you have something to do to keep you busy until it's done, so it doesn't matter if it takes a while. If your only interaction with the device is to press a "next page" button, you have nothing to do except wait for the display to refresh. Time seems to go much slower if you have nothing to do...
Third: e-readers are purporting to provide the advantages of electronic displays combined with the advantages of real ink on paper. One of the advantages of (other) electronic displays is that they update "instantly", so people may have a preconceived notion that that will be one of the benefits they receive with their shiny new e-reader. That would lead to disappointment when they find it's not.
Fourth: many people are probably conditioned to view a slow refresh as indicative of an underpowered system; e.g. when their word processor takes ages to seek in a file, or their browser struggles to smoothly scroll on a busy website, etc. So a noticeable refresh may trigger a subconscious feeling of unease.
Faster refreshes also provides additional opportunities, for example when reading on my phone I sometimes use the auto-scroll feature so I don't have to keep pressing a button to get the next page. Presumably, an auto-scroll wouldn't really be viable with current e-ink type readers. Which goes to point #1: making things better can make for more opportunities that you wouldn't otherwise consider if your only goal was to make it "as good as" the older technology.
Aren't the "typical" terrorists/extremists, particularly the ones who get into a position to be able to launch an attack on foreign soil, highly educated, and reasonably well off? I don't think the stereotype of "they only do it because they're so ignorant they believe in sky faeries" really holds water. While I agree somewhat that the West should be doing more to make the less fortunate parts of the world hate us left, I don't think this is a problem that can be solved simply by changing conditions.
There will always be people who are willing to use violence to benefit themselves, and there will probably always be ways to profit from violence; whether that's materially or simply the joy of being surrounded by sycophants. And there will probably always be people who simply cannot tolerate the existence of certain other people. I mean, most Western nations are well educated and have national policies of inclusion and anti-xenophobia -- but still there's rampant racism and classism, and no shortage of people who fall for scams and join cults and so on.
Well, perhaps games could be workable IF the browser provides the code with full access to all of the device's features, including graphics acceleration, audio mixing, proper responsive input, and so on.
But: what's the real-world likelihood of there being a standard method for accessing all these device-specific functions? It's still pretty hit-and-miss as to whether browser X will support Canvas or lay out your CSS the same way as other browsers or support SVG or embedded fonts... etc etc. And that's on a full-fledged PC. So, the iPhone and Symbian and Android and the other things are all going to somehow get together and offer a standardised way to determine the device's capabilities, and access those capabilities?
Possibly Firefox Mobile will be brilliant and nobody will prefer another browser, and app developers will be able to take for granted that it's installed (and up to date?), and the Firefox Mobile developers will rigorously test it on every smartphone capable of running it to make sure it behaves perfectly. But then... is a world full of Firefox Mobile-only apps any better than a world full of Internet Explorer 6-only apps? Hasn't the internet community been fighting an uphill struggle for years and years to try to get away from a browser monopoly? Is the answer to replace it with another one?
But, what's the likelihood of other browser vendors creating something that's actually compatible and actually gives you "write once, install anywhere"? We don't even have that on PCs, with a considerably more mature market and faster internet access than smartphones. Even if they try, it'll still be like writing web apps today: gotta use a library with a whole bunch of tricks and workarounds for the different browsers that have been encountered. Good luck abstracting away slight peculiarities in input methods, graphics acceleration, screen sizes, processing power...
Ultimately there's two logical reasons why I generally dislike web apps, and one practical reason. The logical reasons are that: a) you have to be online to use it; and b) you're running an app within an app.
a) shouldn't matter on a smartphone right, because you always have internet access through the cellular network? However: maintaining a 3G connection chews up battery life, so playing a game which chews up battery life while also maintaining an internet connection is just going to make things even worse. Secondly, people aren't always in range of a tower when they'd like to use their apps; and thirdly, sometimes it just doesn't work. This is just the standard argument against being dependent on hosted services. Plus little things like payment models: they might sell you a product, but if they take their servers down you suddenly can't use it anymore. So I guess we'll have to lease all our apps instead.
b) comes back to my comment about the phone's physical buttons. "Expose them as keystrokes" you say. So how do I exit the browser app, then? This is similar to having shortcuts in web apps for PCs. Alt+F traditionally accesses the file menu, and for consistency it'd be nice to have Alt+F access your web app's file menu. But... what if you actually wanted to access your browser's File menu? There are workarounds but they're just that: workarounds.
The only real solution I see to b) is to make the "web app" act and behave as if it's a standalone app, so that you, as a user, don't have to be conscious of the fact that you're running an app-within-an-app. This could perhaps be solved with an app launcher; you could even potentially get around problem a) by caching the files locally so you can run it offline, with an automatic check for updates if you do happen to be connected. In other words, create a little package management system around the web apps. Of course, there's no reason you can't build a similar system around native apps, so it's no more an advantage of web apps than it is of native apps.
Theoretically, web apps could work. You'll probably have answers for all the drawbacks I've mentioned. But
What, exactly, isn't quite as good as a native app, at least in the realm of things you'd even consider making a web app for?
If they expect to de-throne the App Store, then they're not just talking about "things you'd even consider making a web app", they're talking about everything. Either that, or they think the games aren't important... even though they seem to be some of the most popular things in the apps store. Plus some of the other popular stuff seems to be things like "turn your iPhone into a remote control for X", which is hard/stupid to do via a web-app.
But the main thing is that you lose access to many of the user-interface elements that make using the device efficient. It might not be such a problem for devices like the iPhone which are primarily touchscreen-driven, but for other phones which use physical buttons, not having access to them makes for a significant decrease in usability. Even on the iPhone: can a web app make proper use of multi-touch?
A possible additional factor is that, to take advantage of the supposedly easier development of web-based apps, you want the server to be doing most of the work. For the end-user, that means latency between their selection an option and something happening. This will vary depending on the app, but again, if you're saying "everything will be a web app", you're increasing the likelihood of this happening. The alternative is to write the entire app in client-side scripting, but that doesn't sound like it'd be much, if any, better than writing a native app in the first place.
Well, that assumes that it actually works properly. Perhaps they'll overcomplicate things and you'll never be able to be sure about which browser you're actually going to end up with.
I just had a great idea for the EU regulators: force Microsoft to install a randomly-chosen browser as the default on every new install of Windows. That way you'll get a nice even distribution of browser usage and everyone will be happy.
I think you're missing the point of pedantic argumentation. Basically: if you're going to make an analogy, make sure it actually fits. Having people point out mismatches between your analogy and the actual thing you're discussing may be annoying, but can also be constructive in helping to refine your own thinking.
Really? All it takes to make something immoral is that it makes someone unhappy?
The point was that it's not monetary loss that was the issue. The harm done is of an entirely different nature, so comparing it to breaking into someone else's house and taking whatever you want is illogical and irrelevant. Analogies are supposed to help us to understand things more clearly, but using an analogy that doesn't actually fit only muddies things. Is sexconker pissed off only at the potential financial damages that could result from having his code "stolen", or is it something else?
You actually didn't address his argument, which was that scarcity isn't necessary for theft.
This one I'm interested in, because I'm not able to think of a scenario where someone still has their "stuff" that I would be willing to call "theft". This is probably just semantics though; "theft" is often used as a shortcut for "copyright violation" or whatever would be more technically correct. Still, some people do get hung up on it, so if you're going to have these kinds of discussions it's probably good to have a response that doesn't rely on people agreeing with your casual usage of the term. Using terms like "theft" and "stealing" in cases like this is essentially slang: it's fine if the people you're talking to happen to share your understanding of what a "jive ho" is, for example; but if you don't know they do, you might be better off using less ambiguous terms.
Actually, if any money went into the code being written, then there IS a monetary loss.
No, there's not, not if the code is being copied. If they delete your copy and you no longer have it, then yes, you've lost the money that was invested in it; in the same way if you buy a new stereo and someone steals it, the money you spent on the stereo is gone, along with the stereo.
Arguably, what you've lost is your code's uniqueness. Suppose the stereo is a one-of-a-kind custom model, the only one in the world. A large part of its value to you, as its owner, is the fact that it is unique. This could be converted into a monetary gain in the future by selling it: presumably its uniqueness is attractive to other people as well. But even if someone comes from the future with a matter duplicator and makes an identical copy of your "unique" stereo, you haven't suffered an actual monetary loss, any more than you suffer a monetary loss if you buy a stereo at full price a week before the store has it on special for 50% off.
Plagiarism should be legal! Why? Well, you're not "stealing" something, since the person from whom you plagiarized still has it after you plagiarize it. And there's no loss, there's only not a profit!
This approaches the crux of the matter. What you say is true, and yet we still "feel" it's unacceptable behaviour. But why? sexconker was previously arguing that closed-source programs should be protected because people like him making a living from it. But obviously just the fact you can make money from something doesn't mean that it's something society should protect. After all, people make money from robbery, selling dangerous drugs, acts of violence, and all sorts of other things we'd prefer not to have people doing. This isn't to say that writing closed-source code is "the same as" beating people up for money; it's merely pointing out that "this is how I make a living" isn't a suitable litmus test for determining whether something should be legally protected.
It's probably even ruder to point this out, but by the time these 48-core processors are commercially available and affordable by institutions with lesser budgets, those with large budgets will be on to bigger and better things. At the very least, if these procs are the best way to do things, then the larger institutions will simply have a dozen racks full of blades with these processors, so the rack or two others can afford will still be way behind the curve.
It doesn't quite work like that. Most browsers don't look at magic bytes to try to guess the content of a file, nor do they look at the file extension (since there's no need for anything on the web to actually have a file extension at all); the content-type header is sent by the server for that purpose. (Internet Explorer is one exception to the "most browsers" rule.).
If you click on a link to a.zip file with SWF at the start, the server will (probably) say it's content-type is application/zip or similar, and the browser will do whatever it's configured to do for that kind of content. If the server says its content-type is image/jpeg, the browser will try to interpret it as a JPEG image (and probably fail, resulting in an error being displayed). The browser doesn't try to guess what the content is (unless it's MSIE).
However, you don't normally run a Flash object by clicking on a link to it. When you link to/embed an external resource within HTML, you can specify the content-type within the HTML. Think <link rel="stylesheet" href="..." type="text/css"> for including a stylesheet. This tells the browser not just where it is, but also what it is. This effectively overrides whatever content-type the server sends. It's very often used with <object> or <embed> tags to give the browser an idea of what the object is so it knows whether or not it can handle it before it requests it. It also enables you to put content on servers which don't have a mime-type configured for that file extension and still have them work.
As such, you can embed in a Flash object into a page, referencing an object with a.zip extension, and the browser will ignore the content-type as supplied by the server because it's already been told that it's a Flash object. Therefore, it'll be executed by the Flash plugin. If you also had a normal direct link to the file on the same page and a user clicked on it, it'd be opened in their archive manager, because the browser would be relying on the content-type header sent by the server.
I don't think there's any particular reason the HTML would need to be injected on the same site as the flash was uploaded; but I don't know how Flash's security model works so I could be wrong.
My assumption is that if you're on stupidsite.com and it tells your browser to load a flash object located at uploadafile.com, then that flash object will be running with the domain context of "uploadafile.com". So if you're a user of that site, it may be able to utilise your logon information if you have an active session, etc.
It's still the same coloured dot/pill for me as it always was. Maybe it's implemented in some funky web 2.0 way that your browser doesn't like or you've configured it to reject?
It's actually written as text inside a <span> with class "zooicon fof" (for Friend of a Friend) so perhaps your browser isn't parsing the CSS properly, or isn't handling the space in the classname?
They'd use an <object> or <embed> embed tag on a page you visit, referencing the SWF/ZIP object. Since it has the content-type specified in the HTML, it doesn't matter what content-type the server responds with: it'll still be executed by the Flash plugin.
So they need to be able to write HTML into a site you visit, which probably requires some kind of XSS attack. Unless the attacker happens to operate a site you visit willingly or can be tricked into visiting willingly.
You don't put the SWF inside the ZIP, you put it before the ZIP. The Flash player will see the SWF bit and ignore the stuff that follows it, while things looking for ZIP data will skip through the SWF and start their processing from the actual ZIP content.
From comments on some random website: There is no case, therefore no reason to reveal ID. Trib said after her son asked Hipcheck16 to debate in person, Hipcheck16 asked her son if he frequently invites guys fron the internet over. A perfectly valid question. It could have been meant to make son more cautious in general. Good advice in the form of a rhetorical question.
But I have no verification if that's correct, and if it is, whether it's the whole story.
Yes, because the pay wall itself is a barrier. For many people it's not about the cost of it, but the hassle of having to register for an account and then go through their payment system and so on. If you're a regular reader of a site then it might not be so bad, for example I'm a/. subscriber because it's very cheap and I had an account anyway since registering brings its own benefits.
Have any of the news sites tried/.'s model, of having the free content infested with ads but if you pay a small amount for each page (i.e. fractions of a cent per view) you get a cleaner one?
A lot of sites have taken to spreading a half page article over 5+ pages in order to increase ad views. Maybe those sites could experiment with a low cost no-ads version where the article text is all on a single page without ads, or at least without intrusive ads. That way you remove the barrier -- people can still read the articles without having to register and pay -- but you also potentially get to benefit from subscriptions.
From the summary (which was copied from the article): with a moderate increase to the size of the chassis. Of course they don't say how much larger it actually is.
Fortunately, a Google for "DSi LL dimensions" yields some useful results. Product-Reviews.com has this:
According to a recent Cnet article it seems as if the handheld has had to be almost completely re-designed around the display, the physical dimensions of the device are (when closed), 161mm wide, 91.4mm height and a 21.2mm depth.
It also suggests checking out the image on CNET's article, which appears to be the same image as in the story/. linked to, except it shows the dimensions.
Agreed, and his "physics rebel" credentials are irrelevant to the story in any case.
I read this article because the headline made it sound like they were doing something really new and different in the world of video game physics. I mean, what else would you assume from the title?
Then I see it's just an advertisement for yet another thing that thumps you when there's a loud noise in a game. As several others have already said in this slightly-commented-on-article, it's not exactly new and revolutionary. And even if it was, it would only be of marginal interest to most gamers.
Which article said that? So far as I can tell, the compromised phone systems belong to random businesses. Calls are then made from the compromised system, meaning the attacker doesn't have to pay for the calls they're making, and also makes it harder to trace the scam back to them.
It's just like spammers using compromised/"zombie" machines to send their spam. They're offloading the cost and risk to others, while still providing the benefit to themselves.
The ABC's Hungry Beast put out a fake press release for their first episode which a lot of news outlets fell for, although I did read a comment someone made on their site (link) about the realities of the newsroom and how fluff pieces don't receive thorough investigation, and don't merit it.
Media Watch also covered Hungry Beast's fictional Levitt Institute. The funniest part was that their press released actually included a paragraph stating that the results of the survey were made up ("These results were completely made up to be fictitious material through a process of modified truth and credibility nodes.").
A more recent episode of Media Watch talked about a fake art piece called The Rape Tunnel. This was run by Gawker, and then the next day they published an admission that it was a hoax, and the original creator of the hoax (Artlurker) also admitted it. Five days later, News Limited picked it up and run the story as if it was factual.
In both cases, they're not all that interesting pieces and arguably don't deserve much scrutiny - they're basically just fluff pieces. But on the other hand, neither of these was particularly well-disguised. The fake Levitt Institute report could've been outed simply by reading the entire report. If someone at News Ltd had done even the simplest of searches or checked the originating websites they would've seen the article was a fake, seeing how it had been announced as such nearly a week prior.
It seems for these kind of thing, the news outlets are no better than that acquaintance with your email address that forwards you everything they receive in the email without checking if it's real, or even applying some basic common sense before forwarding it. I bet that if they receive something from someone they believe to be a government worker, they wouldn't do any kind of verification whatsoever.
In a way I don't really care; at the same time, I often see Big Media execs mouthing off about how bloggers are useless and publish unverified stories and can't be trusted, so it does irk me a bit to see that even "real" news agencies don't do basic fact-checking before publishing.
Slashdot Mirror
I don't see how this would make it any easier for that. If you're doing the lookup using a DNS resolver that's under the jurisdiction of the government that wants the site blocked, then all they have to do is order whoever runs that DNS resolver (typically this would be "every ISP in the country") to block the domain at the DNS level. The ISPs can fight it out in court or whatever, but if the ruling is upheld either they block it as instructed, or go to jail. You don't need to be forwarding the client's IP address for this to work.
If the client is using a DNS resolver out of the jurisdiction of the country, then you're back to standard network filtering practices. Either you order the ISPs/carriers to prevent users within the country from using DNS servers outside of it, or you have them transparently intercept and modify certain responses. But again, the presence or absence of the client's IP address in the forwarded request doesn't matter.
The only one who would potentially receive extra information with this proposal is whoever operates the origin DNS servers. And if they're under the jurisdiction of the country that wants their site banned, well; just go in there and seize the equipment used to run the site and arrest the people responsible for it.
DNS-based backlists. You look up the address or hostname of the sender in a different domain, and the "address" in the response indicates if the thing you're looking up is listed (and potentially, why it's listed). But it's not a real address and you never connect to it.
SPF and anything else implemented in a TXT record can be used in similar ways. I think DNS signing attaches the keys to DNS records, as well.
Not really sure if having the true client IP address exposed matters in either case, but there are applications for DNS that don't result in the client connecting to the resolved address.
From a technical point of view, I dislike anything that implicitly disallows caching of responses. The only way having the client IP forwarded in the recursive lookup makes sense is if you assume that every single lookup will make its way to the origin servers (i.e. ridiculously low TTLs). A lot of things we seem to be doing these days (dynamic sites with different content based on your IP address etc.) seems to be working towards making it much harder to build resilient and performant sites.
The problem is you need to invest a lot of time, money and expertise into setting something like that. For a big shop like yours, that's no problem - the cost of initial setup is easily justified by the fact you have to manage 60k+ desktops and over 2,000 apps, and doing that manually would cost a fortune.
Most of us aren't that large though. We've got maybe 150 desktops/laptops, which is enough to make managing them manually impractical, but not enough to justify purchasing and learning systems management and package management software and the ins and outs of crafting your own package for each application and so on.
You say that "Firefox is just another app to us", but I'm sure you (or someone) spent a long time figuring out how to pull apart the installer and repackage it for your environment and to have everything working for the users but without giving them too much control over bits you want/need to manage centrally, and so on. Again, if you're already set up and have the knowledge of doing that for thousands of other apps, it's not too big a deal. But for us, nobody has that knowledge, and even if they did, nobody has the time to sit around working out how to repackage the application of the month; especially when it's only going to be required by a handful of people.
So either you need to buy some fantastic systems management software ($$$) and hope the vendor supplies packages/scripts/instructions for packaging the apps you use; or you buy packaging tools and learn to do it yourself ($$ + time), or you just use the stuff the more-or-less works out of the box ($). It's no surprise then that most smaller shops use Microsoft's software across the board, and then manually manage installs of additional software in the few cases where they're really needed.
SMTP doesn't support resuming incomplete transfers, so if they want to send/receive a large message they have to hope to get an uninterrupted link long enough to transfer the whole thing in one go. Whether or not their current copying method does resume is another question, but there's no reason it couldn't.
Additionally, SMTP set-up is a transactional process, which adds a time cost to each and every message you want to transfer. Since you've got low bandwidth, you probably don't want to have many simultaneous transfers either, which would be the normal way of mitigating that cost. A bulk copy means you only incur that delay during the initial setup, and the copy itself can make use of wide windows and the usual methods for dealing with high latency.
I'm assuming of course that they don't have a more-or-less continuous connection, and have limited windows within which you can send/receive emails - like the good ol' dialup days. Also, people didn't send HTML mail with funny pictures embedded when we had 1200bps modems. Sure, the astronauts could get by with text-only emails which would make the bandwidth requirements tiny, but that'd take half the fun out of having email in space, wouldn't it?
You're thinking about it from a tech geek perspective: wouldn't it be cool to have a NASAmail system in space?! OMG!
Think of it from a "managing the space mission" perspective: why do they even need email in space? What value does it add to the mission? The answer is, very little. So if a simple, cheap, off-the-shelf type of solution that fits within the parameters (low bandwidth, doesn't interfere with other operations, etc.) can't be found -- the answer would be, no email. Most likely, they don't get the latest hi-def movies, either.
They're astronauts. They're in space to do experiments we can't do on the ground, and things like that. Email isn't part of the mission.
I think the reason they'd do it this is way is latency. It's probably much more efficient to copy the OST file each way once, than it is to let Outlook or Exchange manage the synchronisation itself. More to the point, it's probably a bit more reliable, in that either it's synchronised (copied) or it's not. Outlook is pretty terrible to use on a flakey connection, and I don't think Exchange - Exchange communication would be much better. Additionally, you can use compression and/or differential copying along with the knowledge that it's a one-way, high-latency process to make the most effective use of your limited bandwidth. e.g. they can probably resume an incomplete transfer from where it left off, rather than restarting.
their hack is entirely tied to their vendors
I don't think their solution particularly times them to Microsoft. I mean yes they're using proprietary features specific to Outlook, but presumably they're doing it because they're already running Exchange and/or Outlook was the preferred mail client, anyway. Conceptually, there's no difference between moving an offline cache (the .ost) back and forth and moving a maildir or mbox or whatever. Pretty much every email client will support having two "locations", one which is local and one which is transferred back and forth, and allow the astronauts to drag-and-drop between the two. So if they wanted to switch, there's no reason they couldn't - they just go from copying an .ost to copying whatever format the new mail client prefers its mail to be in.
Finally - reading and writing email isn't the reason they're in space, so a system that's simple and easily understood and doesn't require too much in the way of cleverness is exactly what you'd want. The only thing that I think is a bit crappy about their solution is that they have distinct "send mail" and "receive mail" cycles, when it wouldn't have been that much harder to have a single "sync mail" cycle instead.
Personally, I would've gone with something much more complex - I never thought of using the Outlook cache in this manner, even though I have sometimes done similar things so I "knew" it was possible. I'm actually a bit impressed by the simple elegance of it.
First: why should new technology aspire to be no better than old technology? What's wrong with having or wanting a faster/instant refresh?
Second: the delay on an e-reader is probably more noticeable because you're waiting for it. If you're turning the page of a book, you have something to do to keep you busy until it's done, so it doesn't matter if it takes a while. If your only interaction with the device is to press a "next page" button, you have nothing to do except wait for the display to refresh. Time seems to go much slower if you have nothing to do...
Third: e-readers are purporting to provide the advantages of electronic displays combined with the advantages of real ink on paper. One of the advantages of (other) electronic displays is that they update "instantly", so people may have a preconceived notion that that will be one of the benefits they receive with their shiny new e-reader. That would lead to disappointment when they find it's not.
Fourth: many people are probably conditioned to view a slow refresh as indicative of an underpowered system; e.g. when their word processor takes ages to seek in a file, or their browser struggles to smoothly scroll on a busy website, etc. So a noticeable refresh may trigger a subconscious feeling of unease.
Faster refreshes also provides additional opportunities, for example when reading on my phone I sometimes use the auto-scroll feature so I don't have to keep pressing a button to get the next page. Presumably, an auto-scroll wouldn't really be viable with current e-ink type readers. Which goes to point #1: making things better can make for more opportunities that you wouldn't otherwise consider if your only goal was to make it "as good as" the older technology.
Aren't the "typical" terrorists/extremists, particularly the ones who get into a position to be able to launch an attack on foreign soil, highly educated, and reasonably well off? I don't think the stereotype of "they only do it because they're so ignorant they believe in sky faeries" really holds water. While I agree somewhat that the West should be doing more to make the less fortunate parts of the world hate us left, I don't think this is a problem that can be solved simply by changing conditions.
There will always be people who are willing to use violence to benefit themselves, and there will probably always be ways to profit from violence; whether that's materially or simply the joy of being surrounded by sycophants. And there will probably always be people who simply cannot tolerate the existence of certain other people. I mean, most Western nations are well educated and have national policies of inclusion and anti-xenophobia -- but still there's rampant racism and classism, and no shortage of people who fall for scams and join cults and so on.
Well, perhaps games could be workable IF the browser provides the code with full access to all of the device's features, including graphics acceleration, audio mixing, proper responsive input, and so on.
But: what's the real-world likelihood of there being a standard method for accessing all these device-specific functions? It's still pretty hit-and-miss as to whether browser X will support Canvas or lay out your CSS the same way as other browsers or support SVG or embedded fonts... etc etc. And that's on a full-fledged PC. So, the iPhone and Symbian and Android and the other things are all going to somehow get together and offer a standardised way to determine the device's capabilities, and access those capabilities?
Possibly Firefox Mobile will be brilliant and nobody will prefer another browser, and app developers will be able to take for granted that it's installed (and up to date?), and the Firefox Mobile developers will rigorously test it on every smartphone capable of running it to make sure it behaves perfectly. But then... is a world full of Firefox Mobile-only apps any better than a world full of Internet Explorer 6-only apps? Hasn't the internet community been fighting an uphill struggle for years and years to try to get away from a browser monopoly? Is the answer to replace it with another one?
But, what's the likelihood of other browser vendors creating something that's actually compatible and actually gives you "write once, install anywhere"? We don't even have that on PCs, with a considerably more mature market and faster internet access than smartphones. Even if they try, it'll still be like writing web apps today: gotta use a library with a whole bunch of tricks and workarounds for the different browsers that have been encountered. Good luck abstracting away slight peculiarities in input methods, graphics acceleration, screen sizes, processing power...
Ultimately there's two logical reasons why I generally dislike web apps, and one practical reason. The logical reasons are that: a) you have to be online to use it; and b) you're running an app within an app.
a) shouldn't matter on a smartphone right, because you always have internet access through the cellular network? However: maintaining a 3G connection chews up battery life, so playing a game which chews up battery life while also maintaining an internet connection is just going to make things even worse. Secondly, people aren't always in range of a tower when they'd like to use their apps; and thirdly, sometimes it just doesn't work. This is just the standard argument against being dependent on hosted services. Plus little things like payment models: they might sell you a product, but if they take their servers down you suddenly can't use it anymore. So I guess we'll have to lease all our apps instead.
b) comes back to my comment about the phone's physical buttons. "Expose them as keystrokes" you say. So how do I exit the browser app, then? This is similar to having shortcuts in web apps for PCs. Alt+F traditionally accesses the file menu, and for consistency it'd be nice to have Alt+F access your web app's file menu. But... what if you actually wanted to access your browser's File menu? There are workarounds but they're just that: workarounds.
The only real solution I see to b) is to make the "web app" act and behave as if it's a standalone app, so that you, as a user, don't have to be conscious of the fact that you're running an app-within-an-app. This could perhaps be solved with an app launcher; you could even potentially get around problem a) by caching the files locally so you can run it offline, with an automatic check for updates if you do happen to be connected. In other words, create a little package management system around the web apps. Of course, there's no reason you can't build a similar system around native apps, so it's no more an advantage of web apps than it is of native apps.
Theoretically, web apps could work. You'll probably have answers for all the drawbacks I've mentioned. But
What, exactly, isn't quite as good as a native app, at least in the realm of things you'd even consider making a web app for?
If they expect to de-throne the App Store, then they're not just talking about "things you'd even consider making a web app", they're talking about everything. Either that, or they think the games aren't important... even though they seem to be some of the most popular things in the apps store. Plus some of the other popular stuff seems to be things like "turn your iPhone into a remote control for X", which is hard/stupid to do via a web-app.
But the main thing is that you lose access to many of the user-interface elements that make using the device efficient. It might not be such a problem for devices like the iPhone which are primarily touchscreen-driven, but for other phones which use physical buttons, not having access to them makes for a significant decrease in usability. Even on the iPhone: can a web app make proper use of multi-touch?
A possible additional factor is that, to take advantage of the supposedly easier development of web-based apps, you want the server to be doing most of the work. For the end-user, that means latency between their selection an option and something happening. This will vary depending on the app, but again, if you're saying "everything will be a web app", you're increasing the likelihood of this happening. The alternative is to write the entire app in client-side scripting, but that doesn't sound like it'd be much, if any, better than writing a native app in the first place.
Well, that assumes that it actually works properly. Perhaps they'll overcomplicate things and you'll never be able to be sure about which browser you're actually going to end up with.
I just had a great idea for the EU regulators: force Microsoft to install a randomly-chosen browser as the default on every new install of Windows. That way you'll get a nice even distribution of browser usage and everyone will be happy.
I think you're missing the point of pedantic argumentation. Basically: if you're going to make an analogy, make sure it actually fits. Having people point out mismatches between your analogy and the actual thing you're discussing may be annoying, but can also be constructive in helping to refine your own thinking.
Really? All it takes to make something immoral is that it makes someone unhappy?
The point was that it's not monetary loss that was the issue. The harm done is of an entirely different nature, so comparing it to breaking into someone else's house and taking whatever you want is illogical and irrelevant. Analogies are supposed to help us to understand things more clearly, but using an analogy that doesn't actually fit only muddies things. Is sexconker pissed off only at the potential financial damages that could result from having his code "stolen", or is it something else?
You actually didn't address his argument, which was that scarcity isn't necessary for theft.
This one I'm interested in, because I'm not able to think of a scenario where someone still has their "stuff" that I would be willing to call "theft". This is probably just semantics though; "theft" is often used as a shortcut for "copyright violation" or whatever would be more technically correct. Still, some people do get hung up on it, so if you're going to have these kinds of discussions it's probably good to have a response that doesn't rely on people agreeing with your casual usage of the term. Using terms like "theft" and "stealing" in cases like this is essentially slang: it's fine if the people you're talking to happen to share your understanding of what a "jive ho" is, for example; but if you don't know they do, you might be better off using less ambiguous terms.
Actually, if any money went into the code being written, then there IS a monetary loss.
No, there's not, not if the code is being copied. If they delete your copy and you no longer have it, then yes, you've lost the money that was invested in it; in the same way if you buy a new stereo and someone steals it, the money you spent on the stereo is gone, along with the stereo.
Arguably, what you've lost is your code's uniqueness. Suppose the stereo is a one-of-a-kind custom model, the only one in the world. A large part of its value to you, as its owner, is the fact that it is unique. This could be converted into a monetary gain in the future by selling it: presumably its uniqueness is attractive to other people as well. But even if someone comes from the future with a matter duplicator and makes an identical copy of your "unique" stereo, you haven't suffered an actual monetary loss, any more than you suffer a monetary loss if you buy a stereo at full price a week before the store has it on special for 50% off.
Plagiarism should be legal! Why? Well, you're not "stealing" something, since the person from whom you plagiarized still has it after you plagiarize it. And there's no loss, there's only not a profit!
This approaches the crux of the matter. What you say is true, and yet we still "feel" it's unacceptable behaviour. But why? sexconker was previously arguing that closed-source programs should be protected because people like him making a living from it. But obviously just the fact you can make money from something doesn't mean that it's something society should protect. After all, people make money from robbery, selling dangerous drugs, acts of violence, and all sorts of other things we'd prefer not to have people doing. This isn't to say that writing closed-source code is "the same as" beating people up for money; it's merely pointing out that "this is how I make a living" isn't a suitable litmus test for determining whether something should be legally protected.
It's probably even ruder to point this out, but by the time these 48-core processors are commercially available and affordable by institutions with lesser budgets, those with large budgets will be on to bigger and better things. At the very least, if these procs are the best way to do things, then the larger institutions will simply have a dozen racks full of blades with these processors, so the rack or two others can afford will still be way behind the curve.
It doesn't quite work like that. Most browsers don't look at magic bytes to try to guess the content of a file, nor do they look at the file extension (since there's no need for anything on the web to actually have a file extension at all); the content-type header is sent by the server for that purpose. (Internet Explorer is one exception to the "most browsers" rule.).
If you click on a link to a .zip file with SWF at the start, the server will (probably) say it's content-type is application/zip or similar, and the browser will do whatever it's configured to do for that kind of content. If the server says its content-type is image/jpeg, the browser will try to interpret it as a JPEG image (and probably fail, resulting in an error being displayed). The browser doesn't try to guess what the content is (unless it's MSIE).
However, you don't normally run a Flash object by clicking on a link to it. When you link to/embed an external resource within HTML, you can specify the content-type within the HTML. Think <link rel="stylesheet" href="..." type="text/css"> for including a stylesheet. This tells the browser not just where it is, but also what it is. This effectively overrides whatever content-type the server sends. It's very often used with <object> or <embed> tags to give the browser an idea of what the object is so it knows whether or not it can handle it before it requests it. It also enables you to put content on servers which don't have a mime-type configured for that file extension and still have them work.
As such, you can embed in a Flash object into a page, referencing an object with a .zip extension, and the browser will ignore the content-type as supplied by the server because it's already been told that it's a Flash object. Therefore, it'll be executed by the Flash plugin. If you also had a normal direct link to the file on the same page and a user clicked on it, it'd be opened in their archive manager, because the browser would be relying on the content-type header sent by the server.
I don't think there's any particular reason the HTML would need to be injected on the same site as the flash was uploaded; but I don't know how Flash's security model works so I could be wrong.
My assumption is that if you're on stupidsite.com and it tells your browser to load a flash object located at uploadafile.com, then that flash object will be running with the domain context of "uploadafile.com". So if you're a user of that site, it may be able to utilise your logon information if you have an active session, etc.
It's still the same coloured dot/pill for me as it always was. Maybe it's implemented in some funky web 2.0 way that your browser doesn't like or you've configured it to reject?
It's actually written as text inside a <span> with class "zooicon fof" (for Friend of a Friend) so perhaps your browser isn't parsing the CSS properly, or isn't handling the space in the classname?
They'd use an <object> or <embed> embed tag on a page you visit, referencing the SWF/ZIP object. Since it has the content-type specified in the HTML, it doesn't matter what content-type the server responds with: it'll still be executed by the Flash plugin.
So they need to be able to write HTML into a site you visit, which probably requires some kind of XSS attack. Unless the attacker happens to operate a site you visit willingly or can be tricked into visiting willingly.
You don't put the SWF inside the ZIP, you put it before the ZIP. The Flash player will see the SWF bit and ignore the stuff that follows it, while things looking for ZIP data will skip through the SWF and start their processing from the actual ZIP content.
From comments on some random website: There is no case, therefore no reason to reveal ID. Trib said after her son asked Hipcheck16 to debate in person, Hipcheck16 asked her son if he frequently invites guys fron the internet over. A perfectly valid question. It could have been meant to make son more cautious in general. Good advice in the form of a rhetorical question.
But I have no verification if that's correct, and if it is, whether it's the whole story.
Yes, because the pay wall itself is a barrier. For many people it's not about the cost of it, but the hassle of having to register for an account and then go through their payment system and so on. If you're a regular reader of a site then it might not be so bad, for example I'm a /. subscriber because it's very cheap and I had an account anyway since registering brings its own benefits.
Have any of the news sites tried /.'s model, of having the free content infested with ads but if you pay a small amount for each page (i.e. fractions of a cent per view) you get a cleaner one?
A lot of sites have taken to spreading a half page article over 5+ pages in order to increase ad views. Maybe those sites could experiment with a low cost no-ads version where the article text is all on a single page without ads, or at least without intrusive ads. That way you remove the barrier -- people can still read the articles without having to register and pay -- but you also potentially get to benefit from subscriptions.
From the summary (which was copied from the article): with a moderate increase to the size of the chassis. Of course they don't say how much larger it actually is.
Fortunately, a Google for "DSi LL dimensions" yields some useful results. Product-Reviews.com has this:
According to a recent Cnet article it seems as if the handheld has had to be almost completely re-designed around the display, the physical dimensions of the device are (when closed), 161mm wide, 91.4mm height and a 21.2mm depth.
It also suggests checking out the image on CNET's article, which appears to be the same image as in the story /. linked to, except it shows the dimensions.
Also, someone has made a comparison chart on Sizeasy.com.
Agreed, and his "physics rebel" credentials are irrelevant to the story in any case.
I read this article because the headline made it sound like they were doing something really new and different in the world of video game physics. I mean, what else would you assume from the title?
Then I see it's just an advertisement for yet another thing that thumps you when there's a loud noise in a game. As several others have already said in this slightly-commented-on-article, it's not exactly new and revolutionary. And even if it was, it would only be of marginal interest to most gamers.
Which article said that? So far as I can tell, the compromised phone systems belong to random businesses. Calls are then made from the compromised system, meaning the attacker doesn't have to pay for the calls they're making, and also makes it harder to trace the scam back to them.
It's just like spammers using compromised/"zombie" machines to send their spam. They're offloading the cost and risk to others, while still providing the benefit to themselves.
But now it's on a computer and on the internet (!!!). They should be able to get at least two patents on it, maybe three.
The ABC's Hungry Beast put out a fake press release for their first episode which a lot of news outlets fell for, although I did read a comment someone made on their site (link) about the realities of the newsroom and how fluff pieces don't receive thorough investigation, and don't merit it.
Media Watch also covered Hungry Beast's fictional Levitt Institute. The funniest part was that their press released actually included a paragraph stating that the results of the survey were made up ("These results were completely made up to be fictitious material through a process of modified truth and credibility nodes.").
A more recent episode of Media Watch talked about a fake art piece called The Rape Tunnel. This was run by Gawker, and then the next day they published an admission that it was a hoax, and the original creator of the hoax (Artlurker) also admitted it. Five days later, News Limited picked it up and run the story as if it was factual.
In both cases, they're not all that interesting pieces and arguably don't deserve much scrutiny - they're basically just fluff pieces. But on the other hand, neither of these was particularly well-disguised. The fake Levitt Institute report could've been outed simply by reading the entire report. If someone at News Ltd had done even the simplest of searches or checked the originating websites they would've seen the article was a fake, seeing how it had been announced as such nearly a week prior.
It seems for these kind of thing, the news outlets are no better than that acquaintance with your email address that forwards you everything they receive in the email without checking if it's real, or even applying some basic common sense before forwarding it. I bet that if they receive something from someone they believe to be a government worker, they wouldn't do any kind of verification whatsoever.
In a way I don't really care; at the same time, I often see Big Media execs mouthing off about how bloggers are useless and publish unverified stories and can't be trusted, so it does irk me a bit to see that even "real" news agencies don't do basic fact-checking before publishing.