Well, you wouldn't necessarily use 20 GPIOs on a router... but, then, this isn't a router, just a dev board based on a SoC commonly used in routers, running on a software stack also commonly used in routers.
Ahh yes, you are correct, it's only about 10 bucks cheaper; I was looking at the module price, not the price of the whole package. And much larger, but also supporting a wider range of logic levels and providing better overvoltage protection on its inputs. Also, what gives you the idea that the DPT's RF isn't calibrated?
Face it, your argument boils down to "it costs less and has more features". The only potential downside is for projects relying on "perfect" RF, assuming you are correct about the DPT-board's RF not being factory calibrated; for prototyping, or projects that will primarily make use of the ethernet ports (or not rely on networking at all), it's still a less expensive and better-featured option than the Carambola. If you're far-enough along in your design process that size has become a consideration, you're probably past the point of needing physical ports on your development board, which makes the DPT module (the blue board) about $24 cheaper and a better option; if your project outgrows that, you're far enough along that you're having custom boards fabricated and neither product is an option.
This has its place, especially given the software suite it will ship with. That place is early-stage prototyping and proof-of-concept development, where silly mistakes like overvolting an input or connecting to the wrong pin, which would kill the Carambola, are most likely.
It's not necessarily a different build setup, provided the basic architecture is the same (e.g. all ARM, all MIPS, or all X86); build once for your base architecture, then package apps and drivers per-device. Yes, Apple has a 32bit build and a 64bit build, but that doesn't necessarily mean they build for every device. What's really being asked here is whether builds are being targeted for specific devices, or whether a single build is being packaged for multiple devices.
A question worthy of being asked, rather than assuming the answer and looking down an anyone bold enough to realize the question actually deserves to be asked.
And you're the sysadmin that's missing from most tech companies. You get that crap out of my way and let me focus on development, and for that I thank you immensely.
There's this, but then there's also sysadmin, testing, QA, and a whole slew of other bits, which a good developer should be able to follow but not necessarily expected to do on a regular basis, being foisted on developers, these days. There was a time when companies had people who specialized in these tasks so the developers could, you know... develop.
P.S. Try scaling up a 100 servers on the cloud using Chef, then try doing that with tools/platforms from 10 years ago... No don't. It'd be irritating as shitting on an ant hill.
That's ops. If that's what you want to do, more power to you, but someone who wants to code wants to code; and those of us who just want to code are EXTREMELY happy to have ops and dev-ops people around. Personally, I'm happy on either side of the fence; less so if on both.
You'd be surprised (most of us already understand, since these things don't fascinate the average human) how many people don't want to spend any more time on their finances than actually necessary. Those people typically just look at the name and total to write on the check, the address to write on the envelope, and the due date to make sure they get it in the mail in time. Those are the people that get caught my this.
And I'll admit to being in that group for bills, and things that look like bills, in the name (and letterhead) of a company I know I owe money to, beyond the first couple of invoices. The net result, for me, has been positive; much less information to remember and associate; just a name and total; so I can quickly and easily catch discrepancies and know which invoices actually require further investigation. The billing address from the first invoice goes in my address book (or I pay online, via a bookmark), so the worst case scenario is I overpay one of my accounts one month because someone sent a fake invoice. Just recently, I did receive a legitimate invoice from my ISP that included a billing error; I have autopay through them, so the payment was automatic, but the refund was also issued within minutes of calling them about it when I saw the abnormally large charge on my credit card. This event prompted an investigation on my end, wherein I verified the amounts billed by my utility and service providers over the preceding years, and matched up each payment sent (or appearing to be sent) to any of them with the payment information on file for each; my findings were positive, one billing error (easily corrected) in one year, across all of them. And I'm sure if I went back farther, that's all I'd find.
If you know who you do and don't owe money to, the "just write the check" method actually works quite well.
I've seen apps sell an additional app to unlock features like this, rather than a simple in-app purchase. AutoGuard is an example of this (and worth the $5 if you have a dash mount for your phone), and the way they implemented it works quite well; the features literally don't exist in the main app, which attempts to launch the upgrade app in the background and lets you know you can upgrade if the app is not found.
Game DLC could be handled the same way, with the DLC app unpacking content onto the filesystem when called on by the main app, which would remove the content when it was done with it (thereby freeing up space on your device by allowing the DLC to remain packed in, say, a gzipped tarball when not in use). And it wouldn't, technically, ne an in-app purchase, so it would skirt this new initiative.
You've got it right, but I'll go into a bit more detail for you, as well. In the connectivity market, there are basically two products you have to be familiar with: peering and transit.
When talking about peering, two networks agree to connect to each other and pass each others' traffic, assuming the flow of traffic is more or less balanced. If there is an imbalance, the network sending the additional traffic agrees to pay those costs, because they derive benefit from the other network passing their traffic along. In short, peering arrangements work because two providers would otherwise waste time billing each other roughly equal amounts, spending more in the process of generating invoices, processing invoices for payment, writing checks, sending checks, accepting and processing checks, and closing out the paid invoices, than any small imbalance that might occur. And there are other providers available through which these networks can pass their data in order to have it reach a given endpoint, but these routes are often longer; peering benefits both parties by providing both with shorter routes to some endpoints.
Transit is almost the exact opposite of this; and both Netflix and Verizon purchase transit from Level3. With transit, the customer is buying connectivity, much like you or I would buy connectivity from a last-mile ISP, agreeing to pay for all traffic across that transit link. The reason for this is that Level3 derives no benefit from passing traffic through, or accepting traffic from, Verizon's network; rather, Verizon benefits from the connectivity Level3 provides.
Peering only works when one network is passing traffic through to another network, be that other network an endpoint, or another peering provider. Verizon is an endpoint (as it Netflix, thus why both purchase transit), meaning that the traffic that enters their network terminates within their network and the traffic that exits their network originated there, as well. They are not a transit provider that can offer peering arrangements, they are an endpoint that must buy transit, but they are trying to behave as though they are a transit provider.
It seems as though you already understood the general mechanics of this; hopefully these details can help cement that understanding.
So, Verizon customers can get 100mbps to Google, but can't eek 2mbps out of Netflix because the link between their remote and CO is congested? You sure about that? Seems to me that congestion so close to the end user would constrict *all* of their traffic, but, then, what do I know? It's not like I do this for a living or anything.
Yes! Netflix should buy transit from every OTHER provider Verizon uses, route only to Verizon over those links, and stop routing to Verizon over Cogent and Level3. See if Verizon still tries to blame Netflix's choice of provider, or if the realize that such an argument would apply to them, as well, now that Netflix uses all the same providers they do.
Ahh... I thought of this as soon as I clicked the button... If Netflix *really* wants to drive the point home, they can simply start peering or buying transit (more likely) from the providers Verizon has non-congested links with and stop routing to Verizon through L3 and Cogent. When Verizon refuses to upgrade *those* links, Netflix will be able to say "Either Verizon is refusing to upgrade their links, as we've been saying, or they only use providers which, as they claimed of Level3 and Cogent, can't handle the throughput their customers are requesting. In either case, this should be a wake-up call for Verizon customers to stop giving them money for a service they aren't, for whatever reason, delivering." And they shouldn't stop there; after that statement, they should re-enable routing to Verizon over all available links and watch the congestion continue; regardless of Verizon's response (which will likely be something along the lines of "Netflix performance continues to be slow because they have disabled routing to our network over multiple providers"), Netflix can stand up and say "We are currently routing to the Verizon network through every provider Verizon also uses, and make our routing decisions based on performance metrics, including packet loss and ping time to each user, to ensure that our users get the best possible experience we can provide. Unfortunately, as every link Verizon maintains appears to be congested, packet loss and ping times are high in all cases; the only solutions that exist are for Verizon to upgrade their links or peer with us, or for Verizon customers to find an alternate provider."
I don't think Netflix *wants* to fight dirty, or they would have done this already (and with Comcast, as well).
Bingo. Well, almost; it's a little more nuanced than that. Costs should be driven by the party responsible for the traffic being on *your* network. For Verizon, that's Verizon's customer; for Level3, that's Netflix. And they both already pay their providers. Where Verizon and Level3 peer, it's a matter of recognizing that the imbalance of traffic across that link is caused by Verizon's customers requesting more traffic than they (can) return. Thus, Verizon caused the imbalance and should therefore pay for it. If Verizon primarily sold symmetrical access and allowed their users to run servers, there would likely be a balance, and if there was not, they'd have a leg to stand on here, but they don't sell symmetrical access to the end user and they don't have a leg to stand on in this debate; what they do have is a monopoly on Verizon customers, which they're attempting to abuse right now, which should warrant an anti-trust suit, if anything. No additional regulation needed.
And, in the end, when Verizon and Comcast are the content distributors and Verizon wants to target Comcast users and Comcast wants to target Verizon users, they'll agree to exchange each others' traffic for free and what's old is new, again.
Slashdot Mirror
Bingo. Or a small and low-powered testing environment... or any other number of uses.
Right. It doesn't swim in the lake like a duck.
Well, you wouldn't necessarily use 20 GPIOs on a router... but, then, this isn't a router, just a dev board based on a SoC commonly used in routers, running on a software stack also commonly used in routers.
I think my point was made for anyone who wasn't insistent on being pedantic...
Ahh yes, you are correct, it's only about 10 bucks cheaper; I was looking at the module price, not the price of the whole package. And much larger, but also supporting a wider range of logic levels and providing better overvoltage protection on its inputs. Also, what gives you the idea that the DPT's RF isn't calibrated?
Face it, your argument boils down to "it costs less and has more features". The only potential downside is for projects relying on "perfect" RF, assuming you are correct about the DPT-board's RF not being factory calibrated; for prototyping, or projects that will primarily make use of the ethernet ports (or not rely on networking at all), it's still a less expensive and better-featured option than the Carambola. If you're far-enough along in your design process that size has become a consideration, you're probably past the point of needing physical ports on your development board, which makes the DPT module (the blue board) about $24 cheaper and a better option; if your project outgrows that, you're far enough along that you're having custom boards fabricated and neither product is an option.
This has its place, especially given the software suite it will ship with. That place is early-stage prototyping and proof-of-concept development, where silly mistakes like overvolting an input or connecting to the wrong pin, which would kill the Carambola, are most likely.
Actually... less than half the price and includes a few bits the Carambola lacks.
It's not necessarily a different build setup, provided the basic architecture is the same (e.g. all ARM, all MIPS, or all X86); build once for your base architecture, then package apps and drivers per-device. Yes, Apple has a 32bit build and a 64bit build, but that doesn't necessarily mean they build for every device. What's really being asked here is whether builds are being targeted for specific devices, or whether a single build is being packaged for multiple devices.
A question worthy of being asked, rather than assuming the answer and looking down an anyone bold enough to realize the question actually deserves to be asked.
Why can a speaker company not also be a radio company?
And you're the sysadmin that's missing from most tech companies. You get that crap out of my way and let me focus on development, and for that I thank you immensely.
There's this, but then there's also sysadmin, testing, QA, and a whole slew of other bits, which a good developer should be able to follow but not necessarily expected to do on a regular basis, being foisted on developers, these days. There was a time when companies had people who specialized in these tasks so the developers could, you know... develop.
P.S. Try scaling up a 100 servers on the cloud using Chef, then try doing that with tools/platforms from 10 years ago... No don't. It'd be irritating as shitting on an ant hill.
That's ops. If that's what you want to do, more power to you, but someone who wants to code wants to code; and those of us who just want to code are EXTREMELY happy to have ops and dev-ops people around. Personally, I'm happy on either side of the fence; less so if on both.
it is if your keyboard has a .com button (like my Android phone does)
It wasn't a violation of ICANN regulations until they were updated late last year. This is the 3rd violation, first suspension, since then.
You'd be surprised (most of us already understand, since these things don't fascinate the average human) how many people don't want to spend any more time on their finances than actually necessary. Those people typically just look at the name and total to write on the check, the address to write on the envelope, and the due date to make sure they get it in the mail in time. Those are the people that get caught my this.
And I'll admit to being in that group for bills, and things that look like bills, in the name (and letterhead) of a company I know I owe money to, beyond the first couple of invoices. The net result, for me, has been positive; much less information to remember and associate; just a name and total; so I can quickly and easily catch discrepancies and know which invoices actually require further investigation. The billing address from the first invoice goes in my address book (or I pay online, via a bookmark), so the worst case scenario is I overpay one of my accounts one month because someone sent a fake invoice. Just recently, I did receive a legitimate invoice from my ISP that included a billing error; I have autopay through them, so the payment was automatic, but the refund was also issued within minutes of calling them about it when I saw the abnormally large charge on my credit card. This event prompted an investigation on my end, wherein I verified the amounts billed by my utility and service providers over the preceding years, and matched up each payment sent (or appearing to be sent) to any of them with the payment information on file for each; my findings were positive, one billing error (easily corrected) in one year, across all of them. And I'm sure if I went back farther, that's all I'd find.
If you know who you do and don't owe money to, the "just write the check" method actually works quite well.
I've seen apps sell an additional app to unlock features like this, rather than a simple in-app purchase. AutoGuard is an example of this (and worth the $5 if you have a dash mount for your phone), and the way they implemented it works quite well; the features literally don't exist in the main app, which attempts to launch the upgrade app in the background and lets you know you can upgrade if the app is not found.
Game DLC could be handled the same way, with the DLC app unpacking content onto the filesystem when called on by the main app, which would remove the content when it was done with it (thereby freeing up space on your device by allowing the DLC to remain packed in, say, a gzipped tarball when not in use). And it wouldn't, technically, ne an in-app purchase, so it would skirt this new initiative.
You've got it right, but I'll go into a bit more detail for you, as well. In the connectivity market, there are basically two products you have to be familiar with: peering and transit.
When talking about peering, two networks agree to connect to each other and pass each others' traffic, assuming the flow of traffic is more or less balanced. If there is an imbalance, the network sending the additional traffic agrees to pay those costs, because they derive benefit from the other network passing their traffic along. In short, peering arrangements work because two providers would otherwise waste time billing each other roughly equal amounts, spending more in the process of generating invoices, processing invoices for payment, writing checks, sending checks, accepting and processing checks, and closing out the paid invoices, than any small imbalance that might occur. And there are other providers available through which these networks can pass their data in order to have it reach a given endpoint, but these routes are often longer; peering benefits both parties by providing both with shorter routes to some endpoints.
Transit is almost the exact opposite of this; and both Netflix and Verizon purchase transit from Level3. With transit, the customer is buying connectivity, much like you or I would buy connectivity from a last-mile ISP, agreeing to pay for all traffic across that transit link. The reason for this is that Level3 derives no benefit from passing traffic through, or accepting traffic from, Verizon's network; rather, Verizon benefits from the connectivity Level3 provides.
Peering only works when one network is passing traffic through to another network, be that other network an endpoint, or another peering provider. Verizon is an endpoint (as it Netflix, thus why both purchase transit), meaning that the traffic that enters their network terminates within their network and the traffic that exits their network originated there, as well. They are not a transit provider that can offer peering arrangements, they are an endpoint that must buy transit, but they are trying to behave as though they are a transit provider.
It seems as though you already understood the general mechanics of this; hopefully these details can help cement that understanding.
Wait... I do!
So, Verizon customers can get 100mbps to Google, but can't eek 2mbps out of Netflix because the link between their remote and CO is congested? You sure about that? Seems to me that congestion so close to the end user would constrict *all* of their traffic, but, then, what do I know? It's not like I do this for a living or anything.
Yes! Netflix should buy transit from every OTHER provider Verizon uses, route only to Verizon over those links, and stop routing to Verizon over Cogent and Level3. See if Verizon still tries to blame Netflix's choice of provider, or if the realize that such an argument would apply to them, as well, now that Netflix uses all the same providers they do.
So, you're saying the checks Netflix writes to Cogent and Level3 every month are donations? No, Netflix pays for the bandwidth they consume,
So Netflix dropped Cogent? Funny, I get to Netflix via Cogent still...
Ahh... I thought of this as soon as I clicked the button... If Netflix *really* wants to drive the point home, they can simply start peering or buying transit (more likely) from the providers Verizon has non-congested links with and stop routing to Verizon through L3 and Cogent. When Verizon refuses to upgrade *those* links, Netflix will be able to say "Either Verizon is refusing to upgrade their links, as we've been saying, or they only use providers which, as they claimed of Level3 and Cogent, can't handle the throughput their customers are requesting. In either case, this should be a wake-up call for Verizon customers to stop giving them money for a service they aren't, for whatever reason, delivering." And they shouldn't stop there; after that statement, they should re-enable routing to Verizon over all available links and watch the congestion continue; regardless of Verizon's response (which will likely be something along the lines of "Netflix performance continues to be slow because they have disabled routing to our network over multiple providers"), Netflix can stand up and say "We are currently routing to the Verizon network through every provider Verizon also uses, and make our routing decisions based on performance metrics, including packet loss and ping time to each user, to ensure that our users get the best possible experience we can provide. Unfortunately, as every link Verizon maintains appears to be congested, packet loss and ping times are high in all cases; the only solutions that exist are for Verizon to upgrade their links or peer with us, or for Verizon customers to find an alternate provider."
I don't think Netflix *wants* to fight dirty, or they would have done this already (and with Comcast, as well).
Bingo. Well, almost; it's a little more nuanced than that. Costs should be driven by the party responsible for the traffic being on *your* network. For Verizon, that's Verizon's customer; for Level3, that's Netflix. And they both already pay their providers. Where Verizon and Level3 peer, it's a matter of recognizing that the imbalance of traffic across that link is caused by Verizon's customers requesting more traffic than they (can) return. Thus, Verizon caused the imbalance and should therefore pay for it. If Verizon primarily sold symmetrical access and allowed their users to run servers, there would likely be a balance, and if there was not, they'd have a leg to stand on here, but they don't sell symmetrical access to the end user and they don't have a leg to stand on in this debate; what they do have is a monopoly on Verizon customers, which they're attempting to abuse right now, which should warrant an anti-trust suit, if anything. No additional regulation needed.
Pingtime. While not as low-latency as the shotgun method, the ensuing packet flood caused by your method would certainly be more entertaining.
And, in the end, when Verizon and Comcast are the content distributors and Verizon wants to target Comcast users and Comcast wants to target Verizon users, they'll agree to exchange each others' traffic for free and what's old is new, again.