Re:I don't think, they worry about non-US users
on
Hulu Blocks VPN Users
·
· Score: 1
If 3 out 4 Hulu subscribers were foreign, you'd think Hulu would have opened up in foreign markets by now.:)
On the other hand if it's in the 30-70% range then I'd say they're absolutely justified in cracking down on it.
I'd be VERY surprised if its much more than the 0.3% to 0.7% range.
Your statement assumes that there's no value to the content producer or the advertiser to market segmentation, which is blatantly false. It also assumes that non-U.S. viewers would be interested enough in U.S. content that the international licensing and the infrastructure for international hosting, as well as fighting with the music and motion picture groups in other locations (Germany is a particularly asshattish place to try to offer streaming services - note the GEMA shutdown of GrooveShark and YouTube for not paying duplicate license fees to those already paid to the content creators).
So yeah, there are countries where the users are opposed to their government and industry driven restrictions on their ability to access content, but who are not willing to fight those governmental and industry bodies for the right to access the content, when it's pretty easy to just route around the damage. Routing around the damage is, in fact, a *lot* easier than making the laws and industry groups more sanely based in economic reality.
Hopefully this shutdown will spread to other services, and the people being denied content will beat up the people who are *in the way* of Hulu opening a Hulu.de, and similar streaming companies opening corresponding sites.
Until then, get a VPN from a company that's willing to burn a large IP address space and move around a lot to try and make the restrictions ineffective. Or, you know, lobby the industry organizations to change their policies (good luck with that!), and then get your government involved.
Or go outside and play frisbee, instead of watching Honey Boo Boo.
Re:I don't think, they worry about non-US users
on
Hulu Blocks VPN Users
·
· Score: 3, Interesting
"Also, Hulu is ad-supported. If I was one of their 'sponsors', I might be a bit annoyed that Hulu was billing me for ads delivered to countries where I don't even do business."
People who use VPNs usually also use adblockers, they are the same crowd.
Ad blockers are pretty poor at doing their named job when the next 1800 frames inserted into the video stream are going to be 60 seconds worth of commercials, and you can go pee or not go pee, talk to your family, or whatever, but those are the 1800 frames @ 30FPS you are going to be getting over the next 60 seconds. Hulu has a fairly captive audience, due to their implementation of streaming.
The big argument with Aereo streaming content legally received on antennas within a given region where the information is broadcast is that the Aereo subscribers are unlikely to be customers of the local ads which paid (in theory) for the broadcast service to those devices. In other words, it's about regionality for the ads for ad-sponsorred content.
In practice, it's no different than taking your DVR with you on vacation, and using DVR time shifting, but the ad conversion rate is closer to 0 than if the ads were being viewed by someone local, instead of someone on vacation in a hotel room in Rome. Advertisers care about conversion rate, so media providers also care about conversion rate, and anything that lowers their conversion rate lowers the advertising rate they are able to charge.
yeah so linksys developed the chips and stuff? yeah right(1).
(2) other manufacturers buy from the same chip manufacturers and get the same cookie cutter drivers under the same cookie cutter nda.
3,4,5 doesn't stop others from doing so.
Making the driver proprietary and licensed only for use with the OpenWRT hardware most certainly does prevent 3,4,5 from being leveraged by another vendor. If all I have to do is copy your commodity chip choices and a lot of your interconnect design, you have R&D costs to recover, and I don't = I put you out of business, unless you have brand loyalty above and beyond the price point.
Can you say, with a straight face, that another product that could run the exact same software load and work the exact same way wouldn't render the OpenWRT router fungible, and therefore the only thing that would matter to consumers was the price point? I can pretty much guarantee you can't do that, even if every person who was in the market for an OpenWRT-style device pledged to buy theirs instead of a cheaper one.
You also have failed to address the SDR issue of FCC/CCITT licensing the combination of hardware and firmware as a unit, and revoking licensing for hardware that can be used with a different firmware and/or firmware that can be used with different hardware, because they don't want to have to deal with malicious radio loads screaming over top of military radio bands because the hardware is capable, but it's only the firmware which limits the ability of someone to do the nasty.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
Did you try OpenEmbedded / the Yocto Project? It takes away pretty much all of the pain of cross-compilation. Most of our users seem pretty happy with it.
Yocto has a different goal than cross-building a standard Linux distribution, along with some components. I was specifically involved in ChromeOS, and the cross-build wasn't there fore something as large as a complete Debian distribution.
I think the big problem with Yocto and OpenEmbedded (or ChromeOS) is that it assumes a Linux host environment, and acess through the host environment to package management tools.
I admit that there was a lot of intrinsic bias because of the team's history towards a Debian-based system, but our desktops were a Debian-style environment as well (Ubuntu), and the common implementation was to chroot into a more or less "pure" Debian build environment on the desktop, and then from that, chroot into a cross-build environment basically identical to the first chroot environment, and from that do the cross-build, including installing build products from the second chroot into the build environment for the target, and using them.
Neither Yocto nor OpenEmbedded addresses this issue adequately -- while Yocto did something to eliminate about half the hassle when Richard Purdie did his patch set last October, I don't think it was enough to get to the point where you could base a ChromeOS on it; you could use it for a single embedded device, and, with a lot of work, a number of packages on the device, but clearly nothing like all the software (which I freely admit - it's too much code) needed to do the full product, or do it in a way that was convincing enough that the additional work warranted abandoning a working (non-cross) environment.
How about you bother to learn something instead of coasting on the work of others for a decade then complaining things don't fulfil your every need after you've contributed exactly bugger all.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
IMO, you should be able to download and install OpenFriggingSolaris on a SPARC system, and cross-compile Linux for ARM, Alpha, and Intel on the damn thing, without having to have some dumb-ass chroot environment because someone is too stupid to deal with include paths, library paths, and source paths correctly, and because the build process somehow thinks it's an OK thing to use build products created during the build process as part of subsequent build steps. I mean, how incredibly, obviously stupid is it to use intermediate build products as part of your build process, unless they are targeted solely at your host environment, and never mirrored into your target build product area (oh yea, a working "DESTDIR=" would be kinda helpful here, too...).
The whole idea that you can have dependencies that reference files in the host environment other than those on a mounted read-only source partition, and that "retry" package builds each time because the build system is too stupid to figure out missing dependencies is terrifically annoying.
Yeah, not seeing this one as a problem; Open Source projects have no problem supporting hardware that the manufacturer would rather they didn't support, often over the manufacturers objections, but when it comes to hardware specifically built on behalf of the Open Source project, all of the sudden it's now the companies job, rather than the Open Source project's job, to pee on the patches until they smell like the projects leaders peed on them, so that there are no changes required to be able to use them.
This seems really similar to Samsung releasing code with "board" support for some hardware, and then some maintainer getting all pissy that they didn't write the code the same the maintainer would have, had the maintainer had the time, but the maintainer doesn't have the time, but won't integrate the patches anyway because they aren't done the same way they would have been done, had the maintainer done them, but the maintainer won't do them.
Either bitch when they don't obey the GPL and provide their code, or take their code when it's provided and say "thank you", but don't bitch when they hand you code, and you don't want to do the work to integrate it into your moving target of a project. Thanks.
don't compile cleanly and the wireless driver is missing. Rendering it an expensive paperweight.
It's not entirely a paperweight, but they've acknowledged that the code, as supplied, lacks wireless driver support, and that they need to sanitize the code and break it along interface boundaries so that it can be a binary driver module.
Again, I think the "problem" isn't so much that the module wasn't supplied immediately, instead of just being promised, but that it means they aren't going to get the source code for the module itself. A lot of Open Source projects like to try to force hardware vendors to give up what the hardware vendors consider their "keys to the kingdom", and will go so far as to design system interfaces which aren't usable unless you have GPL'ed code in your driver, making your driver GPL'ed, meaning that they can demand source code.
As far as SDR - Software Defined Radio - such as that used in WiFi and cellular radio parts firmware is concerned, those guys can piss up a rope. Specifically, if the source were made available in a way that could be utilized the way the Open Source people want it to be able to be utilized, which would mean:
(1) Other vendors could just copy the register interfaces and use the same driver, without having to do hardware design work (2) Other vendors could thus undercut the prices by the amortized R&D costs (i.e. the hardware would be commoditized) (3) The driver work would effectively not be a recoverable cost at the commodity price point (4) They lose their FCC certification for the part (5) They can't sell in the U.S., France, the U.K., Japan, and other countries that license hardware/firmware as a single lump
So... piss up a rope; be happy with the forthcoming binary-only driver blob, and be happy it's been promised at all so that you can dick around with the way the rest of the system works to your hearts content. That's all you're going to get for economic reasons, unless you get together as a group and buy out their R&D costs, and buy out their first mover advantage.
Otherwise, if you can live with the limitations, hold your damn horses, and wait to buy the router, which is generally not hardware available anyway.
It'd certainly be a good border security method against Mexicans. In fact, they could start by just targetting drug runners and practically solve the drug problem overnight. Drug dealers cost America more money and kill more americans than terrorism by about 100000x
When did drug smuggling become a capital crime?
I'm pretty sure it happened about the time interdicting drug smuggling involved risk of death.
And I'm pretty sure *that* happened about the time that being a successfully interdicted drug smuggler carried huge penalties, including life in prison.
And I'm pretty sure *that* happened when people starting smuggling huge rather than trivial amounts of drugs.
And I'm pretty sure *that* happened about the time the economic incentives for smuggling became so large.
And I'm pretty sure *that* happened about the time we announced a "war on drugs".
And I'm pretty sure *that* happened about the time the CIA started using Heroin from Southeast Asia to fund the covert "War on Communism".
And I'm pretty sure *that* happened as soon as we cut off their legitimate sources of funding, but kept their goals, tasks, and targets the same.
The site doesn't have any medical information at all. That's one of the advantages of outlawing the "pre-existing condition" scam - you no longer have to tell insurers your medical history to buy insurance.
No, you still have to tell them; that provision of ACA doesn't occur until the end of this year, after you are already enrolled (by which time, it's too late). Until then, they have to let you enroll, they don't, however, have to charge you a reasonable monthly rate if you have a pre-existing condition. They said they had to let you buy it, not that it wouldn't be expensive. That one of the reasons the first 'A' in 'ACA' is a bit misleading.
If only it could have been prevented via a cheap, preventive program, instead of costing so much later! I know! We should lobby them to create a new agency, one tasked with the security of the nation, and when they knew about risks like this, why, they could step in and ensure that no one would unwittingly deploy vulnerable systems in the first place!
Perhaps we could call them the Responsible Agency for Intelligently Securing the Interests of the Nation... R.A.I.S.I.N., for short... or National Organization Securing You... N.O.S.Y. for short... I'm still working on the name.
We could even nominate someone to put in charge of making sure they are doing the job they are supposed to be doing, a kind of Special National Operations Watch Director Executive Nominee... Haven't decided what to call that one yet, either...
What possible motive would a hacker have for targeting a site containing social security, tax, medical, personal, and financial information?
I'm sure it's all perfectly secure.
Just in case, though, you should probably change your one-factor authentication token so that the next time your "keep me logged in" cookie expires, it's hard to remember.
Well there's an authority to base your response upon! I especially like the links to payday loans and making sure your H1B sponsor treats you properly. I missed the part where it actually backs up a single thing you assert since the press release it references is not linked.
And who exactly is the H1-B police who come arrest the violators?
That would be:
= U.S. Immigration and Customs Enforcement (ICE) = U.S. Citizenship and Immigration Services - Fraud Detection and National Security Division (FDNS) = U.S. Department of Labor - Office of Inspector General = U.S. Postal Inspection Service (USPIS) = U.S. Department of State = U.S. Attorney’s Office for the Southern District of Iowa
So perhaps you are an idiot for implying that these laws are unenforced and unpoliced, and it's a scaremongering tactic which actually has very little to do with the offshoring indicated by the original article, which in turn has very little to do with H1-B's at all, since off shore workers are in other countries, and don't require H1-B visas to be employed by a U.S. company, if they never leave their home country.
Given that Ford earned $7.2 Billion in net income in 2013 and GM made a $3.8 billion profit over the same period I think GM and Ford will be very surprised to hear that they cannot make cars in the US profitably since most of their profit comes from US operations.
They'd only be surprised if you told them they'd be doing it in Detroit, instead of non-union plants in other U.S. states: http://www.nytimes.com/ref/us/...
You don't need to expand factories to make the efficient.
Correct. You just need to reduce the number of employees to increase the profit per employee, which is something you can do with automation, and.or lower wages, which is not something you can do in Michigan.
If you're interested in high tech manufacturing with a skilled workforce, it would be hard to find a better place than the automation alley counties. What you'll spend in wages will be more than made up in productivity. And you won't be spending a fortune in recruiting costs. If you build a factory your staffing problem won't be finding qualified workers, engineers or tradesmen, but getting a big enough HR department to hire them.
The reason all but one automotive assembly line has pulled out of Detroit is that the unions wouldn't allow that much automation, or you were "allowed" to have it, but you had to still hire the same number and type of workers to satisfy the contracts, so it didn't do crap to change your value to unit labor cost ratio.
You are an absolute idiot if you locate a manufacturing facility in a state where the unions are in charge of whether or not you get labor, and you can't push costs down by automation.
Most blue collar jobs have migrated outside the U.S. due to inflated labor costs relative to value produced. It has dick all to do with what a living wage is or isn't, and *absolutely everything* to do with value produced per unit labor cost. Most U.S. auto manufacturing that still exists in the U.S. at all is in non-union states, in non-union shops.
As Steve Jobs said, "Those jobs are gone, and they're not coming back". Near the end, before they sold it to Canon, the NeXT factory producing laser printers required exactly two (2) full time workers to operate the entire factory.
OK, as someone who has been trying different methods of QoS over the past years, with varying levels of success, mainly to have my VoIP phone rock solid over DSL, I'm very interested in what you're saying.
Is there a reason this approach hasn't been implemented yet? Does it break something? If my router is lying to one my upstream router about its TCP window size, wouldn't that impact both the FTP and video stream?
You lie about the window size on a per connection basis, so no, since it's not a global policy, it's a resource policy by application, and potentially by port/IP tuple, so it's not a problem. The point is to keep the upstream router packet buffers relatively empty so that the packets you want don't have to be RED-queued. Nothing breaks because of it.
It generally won't work, unless everyone "plays fair", and the port overcommit ratio for upstream vs. downstream bandwidth is relatively low. As the downstream data rate increases to approach the upstream data rate, the technique loses value, unless you get rid of overcommit, or do it on a per-customer "flow" basis (as opposed to a per virtual circuit "flow" basis) within the upstream router itself, or move to a "resource container" or similar approach for buffer ratio allocation in the upstream router.
So in theory, Comcast (as an example) could do it if they made everyone use the router they supplied, and their routers all participates in limiting upstream buffer impact.
Maybe the next time they replace everyone's cable modems, they'll bother to do it?
Without the deployed infrastructure, it's easier to RED-queue and just intentionally drop packets, forcing a client to request a retransmit as a means of source-quenching traffic. This wastes a lot of buffers, but they probabilistically get through, and for streaming video, that's good enough if there's a lot of client overbuffering going on before playback starts (JWZPlayer, for example, is a common player used for pirated content that will habitually under-buffer so intentional drops tend to make it choppy).
For VOIP, unfortunately, forced retransmit causes things to just typically suck, unless you use a sideband protocol instead, where the router at the one hop upstream peer agrees to reserve buffers for specifically that traffic. This is why Skype is terrible, but your phone calls over your wall jacks which are actually wired to the same packet interface instead of a POTS line are practically as good as a land line or cell phone.
Google hangouts tend to get away with it because they are predominantly broadcast, and are either "gossip"-based CSMA/CD (ALOHA style) networks between participants (i.e. people talk over each other, or wait until the other end is done before talking themselves). It means they tolerate large latencies in which 1:1 VOIP/Skype connections won't. They can be a bit of a PITA for conference calls because of that (Google uses it internally, and gets away with it, but mostly because Google has its own, parallel Internet, including transoceanic fibers), but if Google employees never see the problem, they never fix the problem. Same way any company that assumes local-equivalent bandwidth works as well for their customers as it does for them (free hint to Microsoft inre: Office 386 there).
Bandwidth management schemes currently used by everything you mention are all base on rate limiting packet delivery based on some mythical QoS value, and they ignore the actual problem that the people who are using these things are attempting (and failing) to address.
The problem is that the point of a border routers is to hook a slower border uplink to a faster interior connection; on the other end of the slower uplink, you have a faster ISP data rate. In other words, you have a gigabit network in your house, and the ISP has a gigabit network at their DSLAM, but your DSL line sure as hell is *NOT* a gigabit link.
What that means is that software that attempts to "shape" packets ignores an upstream-downloads or a downstream-uploads ability to overwhelm the available packet buffers on the high speed side of the link when communicating to the low speed side of the link.
So you can start streaming a video down, and then start an FTP transfer, and your upstream router at the ISP is going to have its buffers full of untransmitted FTP download packets worth of data, instead of your streaming video data, and it doesn't matter how bitchy you are about letting those upstream FTP packets through your router on your downstream side of the link, it's not going to matter to the video stream, since all of the upstream router buffers that you want used for your video are already full of FTP data that you don't want to receive yet.
The correct thing to do is to have your border router lie about available TCP window size to the router on the other end, so that all intermediate routers between that router and the system transmitting the FTP packets in the first place also lie about how full the window is, and the intermediate routers don't end up with full input packet buffers with nowhere to send them in the first place.
Does your border router do this? No? Then your QoS software and AltQ and other "packet shaping" software is shit. Your upstream routers high speed input buffers are going to end up packed full of packets you want less, and you will be receiver live-locked and the packets that you *do* want won't get through to you because of that.
You can either believe this, or you can get a shitty router and not get the performance you expect as the QoS software fails to work.
Then you can read the Jeffrey Mogul paper from DEC Western Research Labs from 1997 here: http://citeseerx.ist.psu.edu/v......after which, you should probably ask yourselves why CS students don't read research papers, and are still trying to solve problems which were understood 27 years ago, and more or less solved 17 years ago, but still have yet to make their way into a commercial operating system.
BTW: I also highly recommend the Peter Druschel/Guarav Banga paper from Rice University in 1996 on Lazy Receiver Processing, since most servers are still screwed by data buss bandwidth when it comes to getting more packets than they can deal with, either as a DOS technique against the server, or because they are simply overloaded. Most ethernet firmware is also shit unless it's been written to not transfer data unless you tell it it's OK, separately from the actual interrupt acknowledgement. If you're interested, that paper's here: http://citeseerx.ist.psu.edu/v... and I expect that we will be discussing that problem in 2024 when someone decides it's actually a problem for them.
Nothing you say says that Mr Saverin has gotten away from his US tax liability. Only by renouncing citizenship can one end the tax liability, and even that continues for some years (10 I think) after the renouncement.
He did renounce it. And he renounced it before the IPO. So his liability is for what he owed before he renounced it, which is... not the $1.1B.
How many homeless volunteers took off with the camera and sold it to buy booze?
I think there's a more important question... how many mountain lions, gazelles, and other animals took off with the Harmless Radio Collars(tm) that Marlon Perkins had Jim Fowler attach to them while filming Mutual of Omaha's "Wild Kingdom"?
Yes, it is quite large, in relative terms. The city of Pittsburgh is only about 30,000 people, meaning the % of the population in those 2 centers alone accounts for roughly 1% of the population.
Off by a factor of over 10; as of 2012: population of 306,211. That's 0.08%, not 1%.
If those San Francisco residents who are "entrenched" had to pay for their taxes like new residents do, they would be paying 1.25% per year property taxes on the current value rather than the basis of when they bought the property.
That's a great reason to do what rental property owners do, and own a company that owns the property, instead of owning it themselves. Then if they ever want to sell it, they can sell if for a heck of a lot more money by selling the company, rather than selling the property, so the taxes don't go up any more than if you'd bought under prop 13 and never sold.
That's the McDonald's model (McDonald's happily admits to being a real estate company that happens to sell burgers and rents out properties their franchisees). It's also the same model that the Kaiser Family Trust uses.
The only way to fix the Bay Area housing crisis is to build more fucking housing.
One of the things that isn't talked about is the amount of empty office and residential apartments in the Bay Area. It's actually worth more money to price them out of the range that people are willing to pay, and then take the "market rent you are not getting", and use it as a tax write-off. It's a common practice in China (Google "ghost cities"), and it's becoming more common in the Bay Area.
If you want to take a little trip on 101 between SF and SJ, it's easy to see a lot of empty buildings, and it's easy to see some of the mega-complexes that are going in in Redwood City and elsewhere, which are probably going to remain mostly empty as a tax write-off to balance out other income.
Slashdot Mirror
If 3 out 4 Hulu subscribers were foreign, you'd think Hulu would have opened up in foreign markets by now. :)
On the other hand if it's in the 30-70% range then I'd say they're absolutely justified in cracking down on it.
I'd be VERY surprised if its much more than the 0.3% to 0.7% range.
Your statement assumes that there's no value to the content producer or the advertiser to market segmentation, which is blatantly false. It also assumes that non-U.S. viewers would be interested enough in U.S. content that the international licensing and the infrastructure for international hosting, as well as fighting with the music and motion picture groups in other locations (Germany is a particularly asshattish place to try to offer streaming services - note the GEMA shutdown of GrooveShark and YouTube for not paying duplicate license fees to those already paid to the content creators).
So yeah, there are countries where the users are opposed to their government and industry driven restrictions on their ability to access content, but who are not willing to fight those governmental and industry bodies for the right to access the content, when it's pretty easy to just route around the damage. Routing around the damage is, in fact, a *lot* easier than making the laws and industry groups more sanely based in economic reality.
Hopefully this shutdown will spread to other services, and the people being denied content will beat up the people who are *in the way* of Hulu opening a Hulu.de, and similar streaming companies opening corresponding sites.
Until then, get a VPN from a company that's willing to burn a large IP address space and move around a lot to try and make the restrictions ineffective. Or, you know, lobby the industry organizations to change their policies (good luck with that!), and then get your government involved.
Or go outside and play frisbee, instead of watching Honey Boo Boo.
"Also, Hulu is ad-supported. If I was one of their 'sponsors', I might be a bit annoyed that Hulu was billing me for ads delivered to countries where I don't even do business."
People who use VPNs usually also use adblockers, they are the same crowd.
Ad blockers are pretty poor at doing their named job when the next 1800 frames inserted into the video stream are going to be 60 seconds worth of commercials, and you can go pee or not go pee, talk to your family, or whatever, but those are the 1800 frames @ 30FPS you are going to be getting over the next 60 seconds. Hulu has a fairly captive audience, due to their implementation of streaming.
The big argument with Aereo streaming content legally received on antennas within a given region where the information is broadcast is that the Aereo subscribers are unlikely to be customers of the local ads which paid (in theory) for the broadcast service to those devices. In other words, it's about regionality for the ads for ad-sponsorred content.
In practice, it's no different than taking your DVR with you on vacation, and using DVR time shifting, but the ad conversion rate is closer to 0 than if the ads were being viewed by someone local, instead of someone on vacation in a hotel room in Rome. Advertisers care about conversion rate, so media providers also care about conversion rate, and anything that lowers their conversion rate lowers the advertising rate they are able to charge.
yeah so linksys developed the chips and stuff? yeah right(1).
(2) other manufacturers buy from the same chip manufacturers and get the same cookie cutter drivers under the same cookie cutter nda.
3,4,5 doesn't stop others from doing so.
Making the driver proprietary and licensed only for use with the OpenWRT hardware most certainly does prevent 3,4,5 from being leveraged by another vendor. If all I have to do is copy your commodity chip choices and a lot of your interconnect design, you have R&D costs to recover, and I don't = I put you out of business, unless you have brand loyalty above and beyond the price point.
Can you say, with a straight face, that another product that could run the exact same software load and work the exact same way wouldn't render the OpenWRT router fungible, and therefore the only thing that would matter to consumers was the price point? I can pretty much guarantee you can't do that, even if every person who was in the market for an OpenWRT-style device pledged to buy theirs instead of a cheaper one.
You also have failed to address the SDR issue of FCC/CCITT licensing the combination of hardware and firmware as a unit, and revoking licensing for hardware that can be used with a different firmware and/or firmware that can be used with different hardware, because they don't want to have to deal with malicious radio loads screaming over top of military radio bands because the hardware is capable, but it's only the firmware which limits the ability of someone to do the nasty.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
Did you try OpenEmbedded / the Yocto Project? It takes away pretty much all of the pain of cross-compilation. Most of our users seem pretty happy with it.
Yocto has a different goal than cross-building a standard Linux distribution, along with some components. I was specifically involved in ChromeOS, and the cross-build wasn't there fore something as large as a complete Debian distribution.
I think the big problem with Yocto and OpenEmbedded (or ChromeOS) is that it assumes a Linux host environment, and acess through the host environment to package management tools.
I admit that there was a lot of intrinsic bias because of the team's history towards a Debian-based system, but our desktops were a Debian-style environment as well (Ubuntu), and the common implementation was to chroot into a more or less "pure" Debian build environment on the desktop, and then from that, chroot into a cross-build environment basically identical to the first chroot environment, and from that do the cross-build, including installing build products from the second chroot into the build environment for the target, and using them.
Neither Yocto nor OpenEmbedded addresses this issue adequately -- while Yocto did something to eliminate about half the hassle when Richard Purdie did his patch set last October, I don't think it was enough to get to the point where you could base a ChromeOS on it; you could use it for a single embedded device, and, with a lot of work, a number of packages on the device, but clearly nothing like all the software (which I freely admit - it's too much code) needed to do the full product, or do it in a way that was convincing enough that the additional work warranted abandoning a working (non-cross) environment.
You know the man pages are the manual right?
How about you bother to learn something instead of coasting on the work of others for a decade then complaining things don't fulfil your every need after you've contributed exactly bugger all.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
IMO, you should be able to download and install OpenFriggingSolaris on a SPARC system, and cross-compile Linux for ARM, Alpha, and Intel on the damn thing, without having to have some dumb-ass chroot environment because someone is too stupid to deal with include paths, library paths, and source paths correctly, and because the build process somehow thinks it's an OK thing to use build products created during the build process as part of subsequent build steps. I mean, how incredibly, obviously stupid is it to use intermediate build products as part of your build process, unless they are targeted solely at your host environment, and never mirrored into your target build product area (oh yea, a working "DESTDIR=" would be kinda helpful here, too...).
The whole idea that you can have dependencies that reference files in the host environment other than those on a mounted read-only source partition, and that "retry" package builds each time because the build system is too stupid to figure out missing dependencies is terrifically annoying.
RTFA. The patches are a mess,
Yeah, not seeing this one as a problem; Open Source projects have no problem supporting hardware that the manufacturer would rather they didn't support, often over the manufacturers objections, but when it comes to hardware specifically built on behalf of the Open Source project, all of the sudden it's now the companies job, rather than the Open Source project's job, to pee on the patches until they smell like the projects leaders peed on them, so that there are no changes required to be able to use them.
This seems really similar to Samsung releasing code with "board" support for some hardware, and then some maintainer getting all pissy that they didn't write the code the same the maintainer would have, had the maintainer had the time, but the maintainer doesn't have the time, but won't integrate the patches anyway because they aren't done the same way they would have been done, had the maintainer done them, but the maintainer won't do them.
Either bitch when they don't obey the GPL and provide their code, or take their code when it's provided and say "thank you", but don't bitch when they hand you code, and you don't want to do the work to integrate it into your moving target of a project. Thanks.
don't compile cleanly and the wireless driver is missing. Rendering it an expensive paperweight.
It's not entirely a paperweight, but they've acknowledged that the code, as supplied, lacks wireless driver support, and that they need to sanitize the code and break it along interface boundaries so that it can be a binary driver module.
Again, I think the "problem" isn't so much that the module wasn't supplied immediately, instead of just being promised, but that it means they aren't going to get the source code for the module itself. A lot of Open Source projects like to try to force hardware vendors to give up what the hardware vendors consider their "keys to the kingdom", and will go so far as to design system interfaces which aren't usable unless you have GPL'ed code in your driver, making your driver GPL'ed, meaning that they can demand source code.
As far as SDR - Software Defined Radio - such as that used in WiFi and cellular radio parts firmware is concerned, those guys can piss up a rope. Specifically, if the source were made available in a way that could be utilized the way the Open Source people want it to be able to be utilized, which would mean:
(1) Other vendors could just copy the register interfaces and use the same driver, without having to do hardware design work
(2) Other vendors could thus undercut the prices by the amortized R&D costs (i.e. the hardware would be commoditized)
(3) The driver work would effectively not be a recoverable cost at the commodity price point
(4) They lose their FCC certification for the part
(5) They can't sell in the U.S., France, the U.K., Japan, and other countries that license hardware/firmware as a single lump
So... piss up a rope; be happy with the forthcoming binary-only driver blob, and be happy it's been promised at all so that you can dick around with the way the rest of the system works to your hearts content. That's all you're going to get for economic reasons, unless you get together as a group and buy out their R&D costs, and buy out their first mover advantage.
Otherwise, if you can live with the limitations, hold your damn horses, and wait to buy the router, which is generally not hardware available anyway.
It'd certainly be a good border security method against Mexicans. In fact, they could start by just targetting drug runners and practically solve the drug problem overnight. Drug dealers cost America more money and kill more americans than terrorism by about 100000x
When did drug smuggling become a capital crime?
I'm pretty sure it happened about the time interdicting drug smuggling involved risk of death.
And I'm pretty sure *that* happened about the time that being a successfully interdicted drug smuggler carried huge penalties, including life in prison.
And I'm pretty sure *that* happened when people starting smuggling huge rather than trivial amounts of drugs.
And I'm pretty sure *that* happened about the time the economic incentives for smuggling became so large.
And I'm pretty sure *that* happened about the time we announced a "war on drugs".
And I'm pretty sure *that* happened about the time the CIA started using Heroin from Southeast Asia to fund the covert "War on Communism".
And I'm pretty sure *that* happened as soon as we cut off their legitimate sources of funding, but kept their goals, tasks, and targets the same.
The site doesn't have any medical information at all. That's one of the advantages of outlawing the "pre-existing condition" scam - you no longer have to tell insurers your medical history to buy insurance.
No, you still have to tell them; that provision of ACA doesn't occur until the end of this year, after you are already enrolled (by which time, it's too late). Until then, they have to let you enroll, they don't, however, have to charge you a reasonable monthly rate if you have a pre-existing condition. They said they had to let you buy it, not that it wouldn't be expensive. That one of the reasons the first 'A' in 'ACA' is a bit misleading.
If only it could have been prevented via a cheap, preventive program, instead of costing so much later! I know! We should lobby them to create a new agency, one tasked with the security of the nation, and when they knew about risks like this, why, they could step in and ensure that no one would unwittingly deploy vulnerable systems in the first place!
Perhaps we could call them the Responsible Agency for Intelligently Securing the Interests of the Nation... R.A.I.S.I.N., for short... or National Organization Securing You... N.O.S.Y. for short... I'm still working on the name.
We could even nominate someone to put in charge of making sure they are doing the job they are supposed to be doing, a kind of Special National Operations Watch Director Executive Nominee... Haven't decided what to call that one yet, either...
"no indication ... site has been compromised"
I believe them.
What possible motive would a hacker have for targeting a site containing social security, tax, medical, personal, and financial information?
I'm sure it's all perfectly secure.
Just in case, though, you should probably change your one-factor authentication token so that the next time your "keep me logged in" cookie expires, it's hard to remember.
Well there's an authority to base your response upon! I especially like the links to payday loans and making sure your H1B sponsor treats you properly. I missed the part where it actually backs up a single thing you assert since the press release it references is not linked.
http://www.uscis.gov/archive/a...
Government press release you could have googled yourself. Feel free to continue whining that nothing is ever enforced in this area of law.
But what about Detroit?!?!
There was an article earlier about it on Slashdot and everything?!?
http://tech.slashdot.org/story...
And who exactly is the H1-B police who come arrest the violators?
That would be:
= U.S. Immigration and Customs Enforcement (ICE)
= U.S. Citizenship and Immigration Services - Fraud Detection and National Security Division (FDNS)
= U.S. Department of Labor - Office of Inspector General
= U.S. Postal Inspection Service (USPIS)
= U.S. Department of State
= U.S. Attorney’s Office for the Southern District of Iowa
At least that's who it was for this case: http://exbay.blogspot.com/2009...
So perhaps you are an idiot for implying that these laws are unenforced and unpoliced, and it's a scaremongering tactic which actually has very little to do with the offshoring indicated by the original article, which in turn has very little to do with H1-B's at all, since off shore workers are in other countries, and don't require H1-B visas to be employed by a U.S. company, if they never leave their home country.
Given that Ford earned $7.2 Billion in net income in 2013 and GM made a $3.8 billion profit over the same period I think GM and Ford will be very surprised to hear that they cannot make cars in the US profitably since most of their profit comes from US operations.
They'd only be surprised if you told them they'd be doing it in Detroit, instead of non-union plants in other U.S. states:
http://www.nytimes.com/ref/us/...
You don't need to expand factories to make the efficient.
Correct. You just need to reduce the number of employees to increase the profit per employee, which is something you can do with automation, and.or lower wages, which is not something you can do in Michigan.
If you're interested in high tech manufacturing with a skilled workforce, it would be hard to find a better place than the automation alley counties. What you'll spend in wages will be more than made up in productivity. And you won't be spending a fortune in recruiting costs. If you build a factory your staffing problem won't be finding qualified workers, engineers or tradesmen, but getting a big enough HR department to hire them.
The reason all but one automotive assembly line has pulled out of Detroit is that the unions wouldn't allow that much automation, or you were "allowed" to have it, but you had to still hire the same number and type of workers to satisfy the contracts, so it didn't do crap to change your value to unit labor cost ratio.
You are an absolute idiot if you locate a manufacturing facility in a state where the unions are in charge of whether or not you get labor, and you can't push costs down by automation.
Most blue collar jobs have migrated outside the U.S. due to inflated labor costs relative to value produced. It has dick all to do with what a living wage is or isn't, and *absolutely everything* to do with value produced per unit labor cost. Most U.S. auto manufacturing that still exists in the U.S. at all is in non-union states, in non-union shops.
As Steve Jobs said, "Those jobs are gone, and they're not coming back". Near the end, before they sold it to Canon, the NeXT factory producing laser printers required exactly two (2) full time workers to operate the entire factory.
OK, as someone who has been trying different methods of QoS over the past years, with varying levels of success, mainly to have my VoIP phone rock solid over DSL, I'm very interested in what you're saying.
Is there a reason this approach hasn't been implemented yet? Does it break something? If my router is lying to one my upstream router about its TCP window size, wouldn't that impact both the FTP and video stream?
You lie about the window size on a per connection basis, so no, since it's not a global policy, it's a resource policy by application, and potentially by port/IP tuple, so it's not a problem. The point is to keep the upstream router packet buffers relatively empty so that the packets you want don't have to be RED-queued. Nothing breaks because of it.
It generally won't work, unless everyone "plays fair", and the port overcommit ratio for upstream vs. downstream bandwidth is relatively low. As the downstream data rate increases to approach the upstream data rate, the technique loses value, unless you get rid of overcommit, or do it on a per-customer "flow" basis (as opposed to a per virtual circuit "flow" basis) within the upstream router itself, or move to a "resource container" or similar approach for buffer ratio allocation in the upstream router.
So in theory, Comcast (as an example) could do it if they made everyone use the router they supplied, and their routers all participates in limiting upstream buffer impact.
Maybe the next time they replace everyone's cable modems, they'll bother to do it?
Without the deployed infrastructure, it's easier to RED-queue and just intentionally drop packets, forcing a client to request a retransmit as a means of source-quenching traffic. This wastes a lot of buffers, but they probabilistically get through, and for streaming video, that's good enough if there's a lot of client overbuffering going on before playback starts (JWZPlayer, for example, is a common player used for pirated content that will habitually under-buffer so intentional drops tend to make it choppy).
For VOIP, unfortunately, forced retransmit causes things to just typically suck, unless you use a sideband protocol instead, where the router at the one hop upstream peer agrees to reserve buffers for specifically that traffic. This is why Skype is terrible, but your phone calls over your wall jacks which are actually wired to the same packet interface instead of a POTS line are practically as good as a land line or cell phone.
Google hangouts tend to get away with it because they are predominantly broadcast, and are either "gossip"-based CSMA/CD (ALOHA style) networks between participants (i.e. people talk over each other, or wait until the other end is done before talking themselves). It means they tolerate large latencies in which 1:1 VOIP/Skype connections won't. They can be a bit of a PITA for conference calls because of that (Google uses it internally, and gets away with it, but mostly because Google has its own, parallel Internet, including transoceanic fibers), but if Google employees never see the problem, they never fix the problem. Same way any company that assumes local-equivalent bandwidth works as well for their customers as it does for them (free hint to Microsoft inre: Office 386 there).
Never bring politics... to an electronic documentation of timeline fight with a database company.
Almost all router bandwidth management is shit.
Bandwidth management schemes currently used by everything you mention are all base on rate limiting packet delivery based on some mythical QoS value, and they ignore the actual problem that the people who are using these things are attempting (and failing) to address.
The problem is that the point of a border routers is to hook a slower border uplink to a faster interior connection; on the other end of the slower uplink, you have a faster ISP data rate. In other words, you have a gigabit network in your house, and the ISP has a gigabit network at their DSLAM, but your DSL line sure as hell is *NOT* a gigabit link.
What that means is that software that attempts to "shape" packets ignores an upstream-downloads or a downstream-uploads ability to overwhelm the available packet buffers on the high speed side of the link when communicating to the low speed side of the link.
So you can start streaming a video down, and then start an FTP transfer, and your upstream router at the ISP is going to have its buffers full of untransmitted FTP download packets worth of data, instead of your streaming video data, and it doesn't matter how bitchy you are about letting those upstream FTP packets through your router on your downstream side of the link, it's not going to matter to the video stream, since all of the upstream router buffers that you want used for your video are already full of FTP data that you don't want to receive yet.
The correct thing to do is to have your border router lie about available TCP window size to the router on the other end, so that all intermediate routers between that router and the system transmitting the FTP packets in the first place also lie about how full the window is, and the intermediate routers don't end up with full input packet buffers with nowhere to send them in the first place.
Does your border router do this? No? Then your QoS software and AltQ and other "packet shaping" software is shit. Your upstream routers high speed input buffers are going to end up packed full of packets you want less, and you will be receiver live-locked and the packets that you *do* want won't get through to you because of that.
You can either believe this, or you can get a shitty router and not get the performance you expect as the QoS software fails to work.
Then you can read the Jeffrey Mogul paper from DEC Western Research Labs from 1997 here: http://citeseerx.ist.psu.edu/v... ...after which, you should probably ask yourselves why CS students don't read research papers, and are still trying to solve problems which were understood 27 years ago, and more or less solved 17 years ago, but still have yet to make their way into a commercial operating system.
BTW: I also highly recommend the Peter Druschel/Guarav Banga paper from Rice University in 1996 on Lazy Receiver Processing, since most servers are still screwed by data buss bandwidth when it comes to getting more packets than they can deal with, either as a DOS technique against the server, or because they are simply overloaded. Most ethernet firmware is also shit unless it's been written to not transfer data unless you tell it it's OK, separately from the actual interrupt acknowledgement. If you're interested, that paper's here: http://citeseerx.ist.psu.edu/v... and I expect that we will be discussing that problem in 2024 when someone decides it's actually a problem for them.
Nothing you say says that Mr Saverin has gotten away from his US tax liability. Only by renouncing citizenship can one end the tax liability, and even that continues for some years (10 I think) after the renouncement.
He did renounce it. And he renounced it before the IPO. So his liability is for what he owed before he renounced it, which is ... not the $1.1B.
How many homeless volunteers took off with the camera and sold it to buy booze?
I think there's a more important question... how many mountain lions, gazelles, and other animals took off with the Harmless Radio Collars(tm) that Marlon Perkins had Jim Fowler attach to them while filming Mutual of Omaha's "Wild Kingdom"?
"My name is Linux Torvalds... and I pronounce him 'Linus'...".
Once thing they should look at is a city within a single mega-structure.
Why should they build an Arcology, when there are already two in progress:
Masdar City in Abu Dhabi: http://en.wikipedia.org/wiki/M...
Arcosanti North of Phoenix Arizona: http://en.wikipedia.org/wiki/A...
Yes, it is quite large, in relative terms. The city of Pittsburgh is only about 30,000 people, meaning the % of the population in those 2 centers alone accounts for roughly 1% of the population.
Off by a factor of over 10; as of 2012: population of 306,211. That's 0.08%, not 1%.
If those San Francisco residents who are "entrenched" had to pay for their taxes like new residents do, they would be paying 1.25% per year property taxes on the current value rather than the basis of when they bought the property.
That's a great reason to do what rental property owners do, and own a company that owns the property, instead of owning it themselves. Then if they ever want to sell it, they can sell if for a heck of a lot more money by selling the company, rather than selling the property, so the taxes don't go up any more than if you'd bought under prop 13 and never sold.
That's the McDonald's model (McDonald's happily admits to being a real estate company that happens to sell burgers and rents out properties their franchisees). It's also the same model that the Kaiser Family Trust uses.
The only way to fix the Bay Area housing crisis is to build more fucking housing.
One of the things that isn't talked about is the amount of empty office and residential apartments in the Bay Area. It's actually worth more money to price them out of the range that people are willing to pay, and then take the "market rent you are not getting", and use it as a tax write-off. It's a common practice in China (Google "ghost cities"), and it's becoming more common in the Bay Area.
If you want to take a little trip on 101 between SF and SJ, it's easy to see a lot of empty buildings, and it's easy to see some of the mega-complexes that are going in in Redwood City and elsewhere, which are probably going to remain mostly empty as a tax write-off to balance out other income.