The report states that there were over 25 instances in a two-month period in which journalists in the US were beaten and/or arrested while on the job, with charges such as "public nuisance." That seems pretty clear to me, and consistent with their reasoning for ranking other countries.
"How many were arrested versus beaten? And how long were the arrests?"
The answer to either of those would not change the importance of the figure.
Suppression of the press with police force is suppression of the press with police force; the only case in which individual details are relevant are in the lawsuits the reporters have hopefully filed.
Are you referring to bona-fide journalists, or the advocates with cameraphones?
I got stuck in the middle of our local occupy grop as they broke up and did a spontaneous march through rush hour traffic when I was walking to the bus. The newspaper and other reporters were clearly distinguishable from the mob, but there were plenty of wannabe "journalists" broadcasting from cameraphones. Those folks were more like PR flacks than journalists. I saw similar stuff in NYC as well.
I'm speaking from the perspective of my experience. If cops somewhere else are cracking the heads of reporters (vs. participants), I'm not aware of it.
I don't know who they were referring to in the report, although you could probably contact them to inquire about the specifics.
But just by quickly searching Google I found quite a few instances in which real reporters were harmed or arrested: A WNYW Fox photographer (Roy Isen) was maced/attacked with a baton, a Milwaukee Journal Sentinel photographer (Kristyna Wentz-Graff) was arrested despite her credentials hanging from her neck, an RT television reporter (Lucy Kafanov) was struck with a baton, a journalist in TN (Jonathan Meador) was arrested. John Farley (a reporter for WNET in NY) was arrested. That's just from 5 minutes of searching, so it wouldn't surprise me if the 25 figure only represented professionals.
Law enforcement in this country has become increasingly uncomfortable with the spread of information concerning it - whether that information is propagated by twitter, "bona-fide" journalists, or folks testing out their new camera[phone]. Every group of people has the right to do PR, without interference from the government - period. The gov't doesn't get to say "oh, but they were /really/ crazy". Don't care. They were within their rights, and you beat them.
Worse still, we have a promulgation of non-police "law enforcement" agencies acting more like a branch of the military operating within the borders as a national police force. I do not want to see the DHS's logo on a copyright take-down notice. I do not want the TSA searching people. The FBI is properly regulated - that's /why/ they're less efficient. It's not a flaw, it's by design. Creating the DHS and the TSA because the FBI has its hands tied by Congress was just despicable.
(My apologies if this is something of a rant - I'm getting frustrated with people piking at technicalities and ignoring the basic fact that civil liberties are being rapidly destroyed.)
Nope. I'm saying that when you become part of a mob, you aren't reporting a story -- you are part of it.
I got stuck in the middle of a performance of my local "occupy" movement's protest theater when walking home from work. The local police force in my city had orders to avoid provocation and violence with the protestors, and they followed those orders.
But the protestors with assistance with professional agitators from labor groups like the CWA weren't happy about that. They tried to pull a policeman off of his horse. They ran into the street during rush hour with tents. (i was nearly run down by a swerving bus.)
The first amendment doesn't give you the right to riot. It doesn't give you a right to seize public parks for your private use. Creating mayhem to attract TV cameras isn't free speech -- it's anarchy.
My complaint about the bio is that Isaacson had exclusive access to Jobs for at least a dozen multi-hour sessions, and yet there's actually very little content in the bio that hasn't already been retold through other sources. What I hadn't already heard could have probably filled one chapter. It doesn't matter that Isaacson isn't tech-minded; any competent reader can deduce the correct meanings from his mistakes. Nor is it being too positive or negative toward Jobs, as the reader can make their own conclusions from other sources anyway. It's that he seems to have squandered the only opportunity anyone had to obtain more information about Jobs' life.
The problem is that you sent e-mail instead of calling.
I had the same experience in a nearby city, sending 30-40 emails for every 1 response. I finally decided to get a prepaid SIM and start calling people, and suddenly things became much easier.
The person who I eventually rented an apartment from explained that she placed the ad in the morning, went to work, and received my call (and a few others) before she returned home to read her e-mail, which contained over 100 replies. The people who called already had appointments to see the apartment, so she wasn't even going to look at the mails unless those people were uninterested. She also remarked that she could tell from our brief initial conversation that I seemed like a nice person, which helped my chances; she doesn't get that benefit from an email conversation.
Looking at it from a potential landlord's point of view, it makes sense that calling an ad that has just been placed is going to have the highest success rate; not everyone checks their mail as often as tech-minded people.
Sage advice, I'll probably try it. Still, this may fix my immediate problem but it doesn't do anything for the elephant in the room that, judging from the comments here, was hardly addressed:
she returned home to read her e-mail, which contained over 100 replies.
THIS is the real problem. At the end of the day (or the week) it doesn't matter how one out of the 100 candidates is selected; what matters is that 99 fools will have to keep looking. Finding housing shouldn't be like applying to
Google.
What are you claiming is the "real problem?" I'd argue that the housing market in CPH is no more scarce than any major city, and the only reason it seems so to you is because you were seriously handicapping yourself by not optimizing your approach.
The fact that my landlord's ad received over 100 replies just indicates that there's a pool of "bottom performers" who are repeatedly trying to find housing by responding to ads despite the fact that they're doing some things wrong. Every new ad is going to receive a large number of responses from this same group of hopeless people. If they want to find a place, they're going to have to find out what's wrong with their approach and make some changes, just as I had to do.
1) You don't have to sync offline tracks with the Spotify desktop software; you can mark playlists as "available offline" directly within the mobile app and it will start syncing them immediately. I've never synced my phone via the desktop app.
The mobile app is also intelligent enough to sync songs that you're listening to that happen to be part of an offline playlist, saving bandwidth (for example, in the case where your settings only permit you to sync over wifi, but you listen to a song over 2G/3G).
2) The Spotify app used to show song/artist info, but at some point it seems that all the audio apps I used stopped doing this at the same time. Are you sure this wasn't an iOS change?
3) The unavailable song issue is related to the fact that the available songs are completely different depending on the country where you live. I've found that the USA is the worst for what I like to listen to. You could probably change your region by connecting to the website via proxy.
4) Regarding your question about supporting the bands: from what I've read, artists receive almost nothing from Spotify licensing fees. If you want to support the artists, the safest bet is still attending concerts/buying merchandise directly.
Re 4) Spotify pay virtually nothing to artists. Our royalty statements show that we make an order of magnitude more money from a single CD sale or iTunes sale, than many thousands of Spotify streams. ie £1.80 vs £0.18
#1) You're absolutely right! I guess I was confused between local file sync (which does need to come from your desktop) and "Available offline" (which doesn't). Help text like this doesn't help things at all: http://www.spotify.com/us/help/faq/mobile/#sync-your-device
#2) You're right again! Pandora doesn't show artist/name either. Apple's fault, I guess.
#3) I know what you're saying, (and I know this is the fault of the music labels), but this is a big strike against Spotify for now.
I often travel internationally (with no data roaming) and I've noticed that the iPhone's A-GPS is incapable of determining my location when I arrive in a new place, even if I've pre-loaded my route/maps in the maps application prior to arrival. But once I've connected to the internet - even for a few seconds - my phone is permanently able to track itself in that city, even after I've left and returned months later.
It's going to be unfortunate when I can't do this anymore because of people blowing this issue out of proportion. I hope Apple will at least provide the option of caching this data for longer than 7 days.
Well. If you are near an access point apple knows about or just by geolocating your IP address, the iPhone can still download datapoints from that central database that allow it to quickly locate you.
That file on the iphone is just a local copy of the relevant parts of the central database.
Sure. It might be 10 seconds instead of one second now, but that's a reasonable tradeoff compared to the huge log it currently makes. IMHO.
Point is that he's turning roaming off, and probably doesn't have access to WiFi in the foreign city. By having the database, you don't need a data connection at all, thus saving money.
Do you need to use AGPS? It only takes 12 minutes to download the ephemeris and almanac via the GPS satellite itself. So even without Internet connectivity, you'll eventually know where you are.
As far as I can tell, the iPhone cannot determine one's location solely from the GPS antenna. If you travel to a place where you haven't been before, location services simply won't work until you obtain internet connectivity for a few seconds.
I don't know if this is because the iPhone's GPS functionality is crippled, or if it's a software limitation. I'd imagine that if you wanted to overcome this limitation, you'd need to jailbreak your phone and use 3rd party mapping software at a minimum.
*Note: once it has located you, it will generally track you correctly while you're moving, even if you leave the area where you had internet connectivity.
Are you sure you've had 12 minutes with a clear view of the sky? Each GPS satellite carries the entire constellation's almanac. After downloading that (which is a 12.5 minute process), then you can download the ephemeris from each satellite, which takes 30 seconds. You need 4 satellites to get a location fix.
The almanac is valid for 180 days, so you only need to wait 12 minutes once. From then on, you only need the ephemeris from 4 visible satellites, which takes less than a minute to download.
It confuses me that the iPhone wouldn't be able to do this, because I can buy a $10 microchip that's the size of a dime that can do it. Give it electricity, wait 15 minutes, the location comes out the other side. I would be shocked if the iPhone were incapable of doing this.
> I can buy a $10 microchip that's the size of a dime that can do it. Give it electricity, wait 15 minutes, the location comes out the other side.
How do you know when the 15 minutes starts, though? Dedicated GPSs tell you things like how many satellites they have in view and how accurate their fix is, but dumbed-down devices like to pretend location is magic. I'd hope they'd at least provide the gritty details through CoreLocation so a user can buy an app if she wants to know which bench outside the train station to sit at sipping coffee while the phone orients itself.
You don't need to know "when it starts", it transmits in a loop, you need to collect ~12.5 minutes of that loop to get the entire almanac. (lousy software _might_ not understand unless it finds some particular preset mark in the loop, but it's not a GPS system architecture problem)
The user needs to know when the almanac is being received and when the whole thing is in when looking for a clear-view-of-sky spot to sit a while.
The best you can do with CoreLocation is set desiredAccuracy to kCLLocationAccuracyBest and wait for it to fall below 100 feet with no way to find out if it ever will.
It's a common scenario in Europe. It's not "exotic" to take a €39 train ride from Paris to Brussels to visit for the weekend.
I don't think it's a privacy concern to store such data locally on the phone. In any case, it should be resolved by letting the user decide how long to cache the data; that would make everyone happy.
How does data roaming work on European carriers? For someone traveling from the US, there could be a significant cost to using data in another country. If Europe's prices are more sane, it might not be an issue.
At the moment data roaming in Europe is still a nightmare, most providers make you pay ridiculous fees when crossing a border. The EU commissioner for IT & Telco (Nellie Kroes) recently threatened with legislation if things didn't improve and now several providers started offering some kind or "Euro roaming" subscription.
Even so, the data should not be stored in a plain text file. Doing so gives any iPhone application access to that location data. Apple claims that it manages location preferences by application, but that's not true as long as this file exists in a plain text format.
That is incorrect. The iPhone employs sandboxing, so most areas of the filesystem are not accessible to iOS applications, and this cache is in one of those restricted locations. An app on the phone cannot read this information.
However, it is included in the iTunes backups. Those can be read -- but only on your computer, not on the iPhone itself.
(An exception to the above would be a jailbroken phone: the packages installed via Cydia would not have the same restrictions, although the recent jailbreaks do not remove the restrictions on apps from the App Store.)
The location/timestamp concerns are only relevant when my phone has been stolen or somebody has unrestricted access to my computer. At that point, location tracking is only one of many many terrible things that can happen to me, and frankly it's nowhere near the most terrible. And if I'm concerned about somebody tracking me, I'm going to be most concerned about the last 7 days, not the past year. If you're concerned about the government tracking you for longer than a year, they easily have access to that data without your ever knowing they looked.
The solution is to properly protect your data on your phone and your computer.
Your solution is asinine, as I have little way to protect my "cache" of goods... it's unencrypted both on the device and in the backups (though you can encrypt backups now, there might be previous computer backups of mine that have unencrypted location data, now I have to go find and excise those).
Any malicious desktop tool can easily find the location cache in unencrypted backups. Modern Police Forensics tools (http://www.cellebrite.com/) can easily extract non-encrypted data from phones in minutes (see Michigan Police).
That Apple stored this growing set of user-data in cleartext on the device was as stupid as Sony storing their customer's personal information in cleartext (or weakly hashed) on their servers.
Either bit-recycle the information that's not immediately relevant, or strongly encrypt/sanitize it. This shit isn't rocket-science, folks. Otherwise it's a liability and potential PR nightmare in the making.
We're now still in the "wild west" of personal data records. Once these issues start to snowball and real-life consequences happen, people will clamor for litigation, which given politicians will be over-reaching and ham-fisted.
Corporations with hundreds of millions of users' personal data should stay in front of these issues unless they want to wade in a regulatory mess (see Google's mis-steps with wifi packet data).
As of right now, anyone with an iPhone can have their localization data ripped from their device in less than 5 minutes via cellebrite. It could be a coworker, police office, or immigration official.
Data export is not that easy. I've looked into it for my own project. You have to determine which database fields you need to include in the export, what format those fields should be in, and then format of the export.
After you do all that, you need to code and test the export process. I estimated several days if not a week or two to get a workable system in place.
Edit: This is for a Rails project. If it was PHP, I wouldn't even bother thinking about it.
Not to mention the need to set up the actual page layout, markup, and related code... this is a PHP app so it's not that easy. Since I'm the only developer/everything else guy, my time has to be split between customer support, development of cashflow-generating features, and everything else needed to run a business. Maybe you're the "check out the Turing-test-passing AI I developed in a weekend" kind of programmer, but I'm not that good :)
I don't know about you, but if the requirement is simply "give me my data if I ask," I'm going to do as little as possible to get them that data, and then let them do what they wish with it from there—if it's not in a format they understand, then let them hire a third-party to write a converter; that's not my job. In this case, I think I'd just expose a single API endpoint that just spat out SQL dump statements.
Are you still going to support http://mobile.nytimes.com ? I'd be happy to pay for a subscription, but I don't like the smartphone apps and strongly prefer reading the mobile site on my phone's browser instead.
Nowadays, a significant portion of those "bandwidth abusers" are people who are just watching movies and TV shows on Netflix. The use of Netflix instant streaming has grown tremendously over the past year, and for many people, it's become the exclusive source for non-live video content.
You're also leaving out what the household might be doing with its Internet besides Netflix, and you are conveniently ignoring the 150GB cap on DSL service.
Why are you defending AT&T for lowering its level of service by an order of magnitude and imposing gigantic overage fees?
I did some quick math. I could go over this cap on my DSL line simply by using my connection at full speed for LESS than a tenth of a month; i.e., less than 2.4 hrs per day. Sorry, that's not acceptable on an "unlimited" link.
Thanks, I wasn't aware that their HD bandwidth requirements were as modest as 2.6-3.8 Mb/s, from both a more effective codec and limiting fidelity to 720p30 stereo.
Is anyone else having the same issue with these services as I am - namely that Rackspace Cloud (and Amazon Cloudfront) do not support gzip compression? That means that any advantage in latency that you gain from serving a file locally is offset by the fact that it must be served uncompressed. It seems like it should be an absolute requirement for any CDN provider (and the smaller ones like SimpleCDN and MaxCDN do support gzip). I've repeatedly asked Rackspace if they plan to support gzip and they haven't given any indication that it's coming; this e-mail confirms it's not even on their roadmap.
This is something that we are getting with Akamai. Content will be able to be served compressed or uncompressed based on the Accept-Encoding header. So you will be able to store your uncompressed content in Cloud Files and serve it compressed to users whose clients send the Accept-Encoding: gzip header.
I'll check with the team at Rackspace working on CloudFiles + CDN with Akamai to see if gzip compression will be supported. (You also can request it here: http://feedback.rackspacecloud.com where it can be voted upon by others). I do see Akamai itself supports "Content-Encoding: gzip" if used with the "Vary: Accept-Encoding" header. I'll post what I learn here, or you can email me directly at robot AT rackspace DOT com to follow up.
More details on the relationship between Rackspace and Akamai will be posted at this link: http://www.rackspace.com/akamai . The partnership is just beginning; your feedback and requests are and will be appreciated!
There is a hack to get around this. You can manually gzip your files before uploading them (or have a process that does this automatically). You can have 2 folders in your bucket (e.g. bucket/gzip/ and bucket/nongzip/). You include one Javascript file that is gzipped at the top of your web pages and in this file set a variable (e.g. var gzipEnabled = true). If the browser supports gzip, this variable will be set on your page. If not, the file will be gibberish, and the variable will not be set. You can then check for the value of this variable when including other assets on the page, and request them from the appropriate folder. Of course you have to weigh whether this approach has other performance drawbacks and whether the additional dev time is worth it.
That's exactly how MaxCDN and SimpleCDN work, but Cloudfront and Rackspace Cloud don't pass through requests from your own server; rather, they require you to manually upload the files you want to serve via CDN in advance.
But Cloudfront now supports custom origins which I believe allows gzip by forwarding the Accept-Encoding header and caching different versions of the file depending on the value of that header.
This is great to know, but it seems like a lot of unnecessary work on our part to make it work. That means for each file we have to manually create and upload a compressed version, ensure that the compressed and uncompressed versions are always in sync, and properly set up custom origins for the files.
Instead, Amazon's front end should just check the incoming accept-encoding header and automatically compress as needed.
He wants the transfer to be compressed, which is based on the capabilities of the browser, not the content. Admittedly, the names of the headers that control all this kind of make it confusing.
That's pretty ingenious. Though if I were a company offering affiliate links I am not sure I would put up with this process. I imagine the majority of customers are already committed to buying from a specific company and just want to check if any coupons exist.
There are many many times that I choose not to buy something from a new vendor after going to retailmenot.com and finding no relevant coupons available. There is definitely a value-add there.
I agree, definitely customers who do that, but it is a numbers game. Is enough "new" traffic generated from RetailMeNot to sustain the affiliate links? I am not sure there is any way to know for sure at the scale affiliate programs are typically used.
You could raise similar doubts about most affiliate links that aren't precisely equivalent to a banner ad. For example, a blog with a review that uses affiliate links for monetization? Well, I usually look for reviews when I'm thinking of buying a product anyway.
At any rate, the heavy coupon shoppers I know tend to be more malleable than average based on what deals they find, so I doubt this is a low-quality referral source.
Most companies know that there will always be inefficiencies and even seriously dubious stuff wrapped up in affiliate programs, but accept them anyway.
I think there are is a counter-argument to be made because price discrimination is almost always sloppy, yet better than none at all. But your point is basically right -- most companies wouldn't want to do this. And yet the craziest stuff happens in affiliate programs...
Actually, I would love to hear more from folks out there (spez?) who have a perspective on affiliate programs. I ran experimental campaigns with Commission Junction and Expedia a few years back and found insight on the affiliate marketing business hard to come by. Any readings on this topic are appreciated.
