Ah, I see what you're getting hung up on! You missed where I qualified "just as much trust" with "unless you're fully auditing every bit of code".
Sure, if you're auditing all of the code yourself, you don't have to trust that the code is clean, you know if it is or isn't; if you aren't, though, you do have to trust. Likewise, unless you compile the binary yourself (and from code you've audited yourself), you must trust that whoever provided the binary compiled the same code you reviewed, without modification.
Whether or not you compile the binary yourself, you must trust that the compiler used did not insert its own backdoor or malicious code. Even writing your own compiler is not good enough, as the compiler you compile it with may recognize that it's compiling a compiler and backdoor that; you must write the compiler in binary format and you must do so from an environment you build completely. If you don't do this, you must trust that the firmware didn't inject malicious code into the bootloader, that the bootloader didn't inject malicious code into the kernel, that the kernel didn't inject malicious code into your hex editor, that your hex editor didn't inject malicious code into the compiler you used it to write (again, in binary format). But, I digress...
Even ignoring all of the other ways malicious code might sneak into the code you compile yourself, because those really only matter if you're actually compiling everything yourself, you still must trust whoever compiled the binaries. And no, you can not review the code those binaries were compiled from; that is something that is only possible if you compile them yourself.
I feel like I'm repeating myself, here. Probably because I am simply restating the same point in as many different ways as possible. Seriously, though, save us both a lot of argument and actually read Thompson's paper. Like I said, he explains it all better than I ever could.
And, again, something that is self-evident needs no further evidence. You simply don't want to see it for what it is because it destroys the underpinnings of your philosophy. The philosophy, however, is solid; you simply believe in it for the wrong reasons. FOSS is not about security or not needing trust, FOSS is about a community supporting itself. Believe in it for the right reasons and it becomes much easier to accept that you must trust that community.
... if you build everything yourself, starting with the toolchain. Of course, the first part of that is the firmware that starts the system, followed by the bootloader called by the firmware.
I gave an explanation of what should be a self-evident fact. Something that is self-evident it, in fact, evidence of itself and, therefore, requires no additional evidence. That being said, Ken Thompson's Reflections on Trusting Trust explains it a bit better than I could. Mind you, it's been well over a decade and a half since I've read it, but the concepts he discusses there still ring true, and wi continue to dk so for as long as we continue to use computers.
And that's all well and great if you are one of those people. If you're not, well, you're trusting whoever compiled the binary, whoever wrote the compiler they used, whoever wrote the compiler that compiled the compiler they used, and, if you didn't review the source (or can't understand the source), you're trusting that, as well.
My point is, effectively, unless you are one of the few who actually write and manually build their own compiler, review every piece of source, and compile everything themselves with that compiler, those benefits disappear and you default to trusting the vendor just like with OS X or Windows.
Now, don't take that the wrong way (as I fear you have); I'm not saying FOSS should be avoided, or that it offers no value. I'm merely pointing out that, unless you're fully auditing every bit of code and literally building everything (including the toolchain) yourself, FOSS relies just as much on trust as closed-source. I know and understand your perspective; it wasn't long ago that I was equally naive. Now? An OS is a tool and every worthy craftsman uses the tool that best suits the work they are doing. I rely heavily on FOSS for my servers and for a large portion of my development work, so I am in no way attacking that community, merely pointing out an oft-overlooked truth about it. For the vast majority of users, the only difference between FOSS and closed-source is the price tag; both require trust in the developers, vendors, and toolchain providers.
You know, there are plenty of STEM fields where Windows or OS X are mandatory. Like, developing commercial software on either of those platforms, where you have to be able to understand and test on those platforms, or front-end web development (where you may have to take a PSD, Fireworks layered PNG, or InDesign file from a designer and recreate the depicted design, pixel-perfect, in HTML; and no, free tools that exist today can not open these files and represent them (including layers so you can clip out graphical elements as needed) anywhere near pixel-perfect.
That said, you can just as well run Linux on your development machine and keep Windows and/or OS X around for testing if needed.
unless you compiled it from source (using a trusted compiler you also wrote yourself) from code you've fully reviewed, you're putting your trust in whoever provided the binaries, compiler, and/or source code
Take note? You mean, like, look at my own systems? I run more than a handful of Linux systems, personally. Also OSX and Windows for software that doesn't exist on other platforms; when working in an industry that uses standardized software, you run that software, which means you run the platform that software expects. No, WINE does not work for everything.
The complaint I keep seeing is not that the information is sent, but that we can't see what information is sent. There are two solutions to that problem:
A) Send the information in plaintext. Of course, then (as I already mentioned), people will complain that the data is being sent in plaintext.
or
B) Store a plaintext log of the telemetry data for the user to review. Of course, then, people will point out that, because it's sent over an encrypted connection, there is no way to verify what's actually being sent.
For examples of (B) in the FOSS community, look at the crash reporting used by Firefox and Ubuntu. Yes, Ubuntu, the entire distribution. Sure, they show you what they're supposedly sending, if you're interested to look, but the data is sent over an encrypted connection so, well, unless you compiled it from source (using a trusted compiler you also wrote yourself) from code you've fully reviewed, you're putting your trust in whoever provided the binaries, compiler, and/or source code.
So, you choose to trust a platform vendor serving thousands or millions of systems and collecting a much smaller amount of data (easier to sift through) rather than a vendor serving billions of systems and collecting a much larger amount of data (more difficult, to the point of impossibility, to sift through). You're still giving up telemetry data to your vendor and you're still relying on trust. The tradeoff you make is that you can't reliably deal with graphic designers (who use Adobe tools as a standard) and video production studios (who use Adobe, Apple, Sony, and Lightworks software as standards), nor can you sell well-tested software for Windows or OS X. Of course, if you don't need to work with designers or video studios and you don't sell software, yeah, Linux can be a workable desktop solution; and yes, that covers a rather large portion of the population. However, it also fails to cover the majority of high-paying professions.That's why people with money use Windows and/or OS X; not because they can afford to use them, but because they can't afford not to.
Careful you don't fall off that high horse, friend, you seem to be losing your grip.
To be fair, you're replying to an AC, so "nothing useful" should be the expected norm. That said, his point over "concerns" seems valid. I've certainly seen people complain that they can't see the contents of the telemetry because it's all sent over secure connections. Of course, if it was sent in the clear, these same people would complain about that, so...
Ah! Finally! Points! Now that you've stated them, I can break them down and show you precisely why you're wrong! Buckle up, this is gonna get rough.
1. Not all transit providers are equal. Some make better deals with peers than others.
Not all watermelons are equal, either; some are larger and/or have fewer seeds than others. In fact, outside of mathematics, it is quite rare to find two truly equal entities. Basically, inequality is a given in the real world. Hell, not all streaming video providers are equal, which is why many people subscribe to two or more. In fact, Netflix uses multiple transit providers[1-8] for similar reasons.
2. Some transit providers are less expensive because they lack the ability to make the best deals with peers.
This is just plain backwards. A transit provider who makes better peering deals has lower costs, so they don't have to charge as much! I know this seems counter-intuitive when you consider that those providers also offer a better service, as you'd think that's something they could charge a premium for, but it should make a bit more sense when you consider the corollary: a transit provider who makes worse peering deals has higher costs, which they must recoup from their customer. Sort of like how Costco charges less because they make better deals buying in bulk; or, rather, other retailers must charge more because they didn't make the same deals.
3. To cut costs, Netflix chose a less expensive transit provider.
First of all, your assertion that Netflix uses a single transit provider is just plain wrong[1-8]. It has been made public knowledge (despite being none of our damn business) that their primary transit providers are Level 3 and Cogent[1-8], and that they purchase transit services from at least 4 other providers, Tata, XO, NTT, and Telia[1,3].
As for your assertion that Netflix only buys from the lowest bidder, well, it appears that the buy from anyone who can provide transit between them and the networks their customers are on[1-8]. Not only do they buy transit from all three available providers who route directly from their POIs to Comcast's[1], they even buy transit from Comcast now[3]. And, despite that, I still see buffering issues with Netflix on a 75Mbps Comcast Business connection, which points to the issue not lying with Level 3, Cogent, or any of Comcast's other providers with names not starting with C and rhyming with "bombast".
At least you proved you weren't trolling; I guess that only leaves one other possibility.
Footnotes: [1] "Netflix attempted to address congested routes into Comcast by purchasing all available transit capacity from transit providers that did not pay access fees to Comcast—which involved agreements with Cogent, Level 3, NTT, TeliaSonera, Tata, and X0 Communications. Although all six of those providers sold transit to the ent
I'm sure each provider has their own agreement with each of their peers, but thats between the transit providers, not their customers. What's your point? In no way should Netflix, who is a customer of several transit providers, and not a transit provider themselves, be involved in any of that. Netflix already pays for their bandwidth. What agreements the companies they pay make with any other companies that aren't Netflix is as much their business as it is yours or mine; as long as the bits that get shoved in one end eventually fall out the other, they're getting what they're paying for and that's all anyone needs to know. The concepts we're discussing here are so simple you have to either be an idiot or a troll to not get them. I'll let you chew on that, but I'm done feeding you.
You're right, the ISP isn't Netflix's customer, the ISP is the transit provider's customer, just as Netflix is the transit provider's customer. Likewise, Netflix is not the ISP's customer.
Or, wait, should I be expecting Comcast to pay me for all the data they send down my coax, because they send several thousand times as much data my way as I send theirs? Because that's exactly what you're proposing.
They buy transit from whoever serves their DCs. Last time I checked, the only place you can buy transit from Comcast, for example, is at a Comcast POI. Also, consider whether Netflix is pushing traffic for Comcast's network or Comcast customers are pulling. Hint: it's the latter; Netflix isn't forcing their content onto users' systems, it's getting there as a result of the user's own request.
Netflix could have chosen to use CDNs or to buy transit directly on the large networks it wished to supply traffic to, but instead chose to use cheaper transit providers that would abuse settlement free peering links.
Netflix pushes more bandwidth than any CDN (aside from, maybe, CloudFlare, who doesn't cache video and, therefore, wouldn't benefit Netflix) can handle. While they could have chosen to work with a CDN provider who can't support them they, instead, chose to use transit providers who can actually provide the bandwidth Netflix needs (and pays for) and let them sort out the details. And before you say (or imply) that Netflix should sort the details out themselves, that's what they're trying to do in offering their own CDN boxes; and it's what any other CDN wold do on their behalf, just like the transit providers. The difference is that the transit providers don't host their content, so they're able to keep it relatively secure (as their licenses likely require). That is, they're likely prohibited from using an external CDN as you suggest.
If I missed your point, it's because your point was wrong.
Which is funny because the 4U of rack space costs them less (even considering opportunity cost) than the bandwidth it would save. The ISPs who don't want to do it are all also content providers with competing services; the majority of ISPs who don't offer a competing service do host Netflix's boxes.
17" MBP with anodizing options (space grey FTW), 5k display, a full suite of ports (including CardBus and Ethernet), new version of OS X as trim, fit, stable, and performant as Snow Leopard, and go back to the case thickness of the previous 17" model, incorporating the bottom/side vents from the Retina design, maintaining the super-compact electronics design of the current models (save for, perhaps, keeping the RAM slots from the old 17" models) and using all the now-empty space to allow airflow for proper cooling (something I've simply not seen on any Intel-based Mac laptop) and additional battery capacity. Fill the space the HDD used to occupy in the old models with battery, optionally offering a breakout board for 2 m.2 drives (with hardware RAID support) or a SATA connector for a spinning disk or SSD; do the same with the space formerly occupied by the optical drive, offering options for a breakout board for 3 m.2 drives (with hardware RAID support), a SATA connector for a spinning disk or SSD, or an optical drive.
The optical and SATA options would be rarely used by most, but a great option for those who need them, a (very spendy) market Apple is missing out on right now. Assuming 1 m.2 drive on-board, that would give us the option to trade some battery capacity for a total of up to 6 m.2 drives, with the ability to configure (if they implement hardware RAID on the breakout boards directly) up to 2 RAID arrays, one with 2 m.2 drives and the other with 2 or 3.
With all the extra battery and proper cooling, Apple could offer a desktop-class CPU (or, at least, a mobile-class CPU that won't throttle itself to death) and high-end GPU options (both for gaming and workstation use). They'd once again have a lineup that was hard to beat, like they did half a decade ago.
You're either trying to run a fully scaled out production configuration that forces memory consumption
Precisely. I'm not just running a test suite against the code (which should have been obvious as I could run tests against code for any platform from any platform, thus negating the need to run the actual OSes) but automated functionality testing against individual builds. I need a production environment (e.g. one that closely matches what the end user will be using) in order to do that; so, yes, I'm running a fully scaled out production configuration. Out of necessity.
you're still running a MBP in the first generation SSDs, which were only 300MB/s or so
Whatever was the highest-end model they sold in January 2015. I peak over 500MB/sec for both reads and writes so I'm guessing no. Looking farther up in the discussion, I do see that i said i bought it in 2014; I'm not so 100% with timelines, I was still working for someone else in 2014 and didn't buy the rMBP until the 2011 (17") died in January 2015 when I was relying on it for my work, as I was working for myself at the time. Sorry for the confusion.
To be sure, I just checked. System Information lists it as a MacBook Pro 11,3 and About This Mac states Mid 2014.
The latest rumors have the next generation of SSDs running at 10 times that speed. More memory may not be the smartest bang for your dollar at that point.
At that point, I'm sure we'll be considering whether we should have RAM at all, beyond a small amount to store status flags to allow us to reset a deadlocked machine. That or, well, you know, RAM is getting faster, too; and if I need to use more than 16GB of it and that's all I happen to have, well, I'm still gonna be swapping to a slower medium.
Just to bring home how fast these SSDs are
I have two of them, each capable of 1100MB/sec writes, in a RAID0. I'm acutely aware of how fast they are. DDR3-1866 (which my PC laptop uses) has 14933.33MB/sec of bandwidth, about 7.5x as fast as my SSD RAID stripe in raw throughput; faster when you consider seek times. DDR3-2133 has 17066.67MB/sec of bandwidth, further widening the gap. Of course, the DDR3-1600 soldered into my rMBP has only 12800MS/sec of bandwidth, which might account for the performance variance between the two systems (until the rMBP throttles, then that accounts for most of it).
And now we have DDR4, which goes up to 19200MB/sec bandwidth in currently available modules. Faster speeds will be developed, so... wake me when I can buy an M.2 SSD that tops 20GB/sec with seek times measured in clock cycles rather than microseconds. I'll write a fat check for a couple of them.
If you're not running high-end games or video, the built-in Intel graphics should suffice just fine.
Unless you're RAM-constrained, in which case sharing some system RAM with the Intel GPU might just be the thing that gets you swapping.
Yes, indeed it is, as part of another word. UltraFire, on the other hand... well, "Fire" stands on its own there. Further, my products (rather, the ones I'm using, I don't product, market, or sell them) are intended to heat up, it's what they're supposed to do, so "fire" is appropriate. A lithium battery? Not so much.
go to that link, click on the MBP picture. You'll note that when you do, it will come up with an enlarged picture with "Macbook Pro with Retina". AFAIK, they no longer sell non retina MBPs, and haven't for at least the last couple of years. To go non-retina, you have to buy a Macbook.
You, sir, are mistaken. They do appear to have an error on their site, not surprising given that they've let this model stagnate; however, if you head back to the Buy page and look at their offerings, you'll see that, at the bottom, below the "with Retina" listings, there is a lonely little listing for the 13" MacBook Pro. That is what I linked to. Now, if you click on Tech Specs, you'll see a side-by-side of the two Retina models; scroll down again. See it there, under the Other Models heading, just above Accessories? "13-Inch MacBook Pro Tech Specs" is the label and it's 1280x800, certainly not Retina.
I do the same, and my MBP and 1 external 2TB disk carries everything I "need"
Uh... I don't see how an external disk has any bearing on the amount of RAM available for running additional operating systems in a virtualized environment, but okay... I find, quite often, that my Mac is using upward of around 12GB of RAM (minus buffers, caches, and the like) while my PC sits comfortably at just over 8GB running the same applications. That's just running my IDE, a couple browsers, Skype, and a few terminal sessions.When I get to testing my application on various platforms, well, that puppy eats up another 4GB once it gets going (I should clarify, the test suite uses most of that, not necessarily the application itself). So let's do some quick back-of-napkin math (and we'll even ignore the RAM used by guest OSes, a concession I'm openly making in order to illustrate my point): RAM used by Mac running typical software and dev tools [12GB] + RAM used by test suite on OS X [4GB] + RAM used by test suite on Windows [4GB] + RAM used by test suite on Linux [4GB] = 24GB. You're right, I can't see any way 32GB of RAM in a MacBook Pro could be useful. None. At. All.
You know, if I could do it legally, I'd just throw the 32GB in my PC and run OS X in a VM and call it a day. But I can't, and I also can't buy a MacBook Pro with 32GB of RAM and the models that come with RAM slots only support up to 16GB (again, only 8GB officially); so, I carry 3 laptops when I know I'm going to have to work remotely.
I mean, I could shut down my IDE, close my browsers, kill Skype, and run the tests on OS X first, then boot the Windows VM and run the test suite there, then kill that and boot the Linux VM and run the test suite there... you know... that might work. In fact, it does work, it's what I do when an over-night trip turns into a full week (e.g. I wasn't planning on having to work, so I only brought the Mac); yeah, it works, except that it literally takes 3x as long, requiring manual intervention (e.g. I have to switch VMs manually and actively monitor progress, lest it take longer because I left it sitting idle when the test suite on one OS completed), and I still wish I'd brought a 2nd laptop so I could still have a usable computer while all of that was going on. Yeah... nah... if I have to carry 2 laptops anyway, carrying a 3rd is less hassle than cycling through VMs, adding another manual procedure to the testing process, and making the already lengthy test suite take 3x longer to run. I absolutely abhor taking a 2hr process and turning it into a 6hr process, as it adds 4hr to my workday.
I'm good with not doing that; I just won't buy another Apple computer until they sell something that fits my needs. If the one I'm using currently (well, there are two but one won't boot OS X anymore for reasons discussed earlier in the thread) happens to break before Apple starts selling somethi
Interesting, I'm certain the T&C state that "by using, or continuing to use, this software, you agree to these terms and conditions", or something similar.
I suppose one could argue that, since they don't agree with the T&C, they don't agree with the stipulation set forth in said T&C that use of the software or service constitutes agreement with the T&C. It'd be interesting to see how that'd play out in court.
And that's if the T&C never change! If they change, you should be reading over the old, then the new, and noting what changed. For all 33 apps, that's 30hr to read the old, 30hr to read the new, and 10-30hr to identify differences; so, 70-90hr every time they change. Of course, they won't all change at the same time, but you get the point.
The current crop is finally using the slot M drives my 2013 model PC is using? I could swear my 2013 rMBP uses one as well, though I didn't look that closely and it might simply be PCIe.
And I question your knowledge of Apple's product lines given the following:
For references, as a software developer who tests on all common platforms, gaming is not my focus either (I have consoles for that). 32GB in one machine capable of legally running OS X without a bunch of hackery would mean I no longer need to maintain 3 separate systems for testing purposes, which is why I'm seeking precisely that. No, a Mac Pro is not the solution, as it lacks the portability I often need. One of the perks of working for myself is that I can work from wherever (this means traveling with the wife when she goes to visit family), which basically requires that all of my equipment be portable.
+1 for holding off on the 10.11 upgrade, though; if I can't have Snow Leopard, Yosemite is the next best release IMO.
core clock speed is no longer increasing
Ah, but instruction efficiency is. Don't underestimate how important that is; you'll note that the performance of each subsequent release from Intel exceeds that of the previous generation at the same clock speed. Well, given your workload you might not, but a lot of others do, myself included.
Slashdot Mirror
Ah, I see what you're getting hung up on! You missed where I qualified "just as much trust" with "unless you're fully auditing every bit of code".
Sure, if you're auditing all of the code yourself, you don't have to trust that the code is clean, you know if it is or isn't; if you aren't, though, you do have to trust. Likewise, unless you compile the binary yourself (and from code you've audited yourself), you must trust that whoever provided the binary compiled the same code you reviewed, without modification.
Whether or not you compile the binary yourself, you must trust that the compiler used did not insert its own backdoor or malicious code. Even writing your own compiler is not good enough, as the compiler you compile it with may recognize that it's compiling a compiler and backdoor that; you must write the compiler in binary format and you must do so from an environment you build completely. If you don't do this, you must trust that the firmware didn't inject malicious code into the bootloader, that the bootloader didn't inject malicious code into the kernel, that the kernel didn't inject malicious code into your hex editor, that your hex editor didn't inject malicious code into the compiler you used it to write (again, in binary format). But, I digress...
Even ignoring all of the other ways malicious code might sneak into the code you compile yourself, because those really only matter if you're actually compiling everything yourself, you still must trust whoever compiled the binaries. And no, you can not review the code those binaries were compiled from; that is something that is only possible if you compile them yourself.
I feel like I'm repeating myself, here. Probably because I am simply restating the same point in as many different ways as possible. Seriously, though, save us both a lot of argument and actually read Thompson's paper. Like I said, he explains it all better than I ever could.
And, again, something that is self-evident needs no further evidence. You simply don't want to see it for what it is because it destroys the underpinnings of your philosophy. The philosophy, however, is solid; you simply believe in it for the wrong reasons. FOSS is not about security or not needing trust, FOSS is about a community supporting itself. Believe in it for the right reasons and it becomes much easier to accept that you must trust that community.
... if you build everything yourself, starting with the toolchain. Of course, the first part of that is the firmware that starts the system, followed by the bootloader called by the firmware.
I gave an explanation of what should be a self-evident fact. Something that is self-evident it, in fact, evidence of itself and, therefore, requires no additional evidence. That being said, Ken Thompson's Reflections on Trusting Trust explains it a bit better than I could. Mind you, it's been well over a decade and a half since I've read it, but the concepts he discusses there still ring true, and wi continue to dk so for as long as we continue to use computers.
And that's all well and great if you are one of those people. If you're not, well, you're trusting whoever compiled the binary, whoever wrote the compiler they used, whoever wrote the compiler that compiled the compiler they used, and, if you didn't review the source (or can't understand the source), you're trusting that, as well.
My point is, effectively, unless you are one of the few who actually write and manually build their own compiler, review every piece of source, and compile everything themselves with that compiler, those benefits disappear and you default to trusting the vendor just like with OS X or Windows.
Now, don't take that the wrong way (as I fear you have); I'm not saying FOSS should be avoided, or that it offers no value. I'm merely pointing out that, unless you're fully auditing every bit of code and literally building everything (including the toolchain) yourself, FOSS relies just as much on trust as closed-source. I know and understand your perspective; it wasn't long ago that I was equally naive. Now? An OS is a tool and every worthy craftsman uses the tool that best suits the work they are doing. I rely heavily on FOSS for my servers and for a large portion of my development work, so I am in no way attacking that community, merely pointing out an oft-overlooked truth about it. For the vast majority of users, the only difference between FOSS and closed-source is the price tag; both require trust in the developers, vendors, and toolchain providers.
You know, there are plenty of STEM fields where Windows or OS X are mandatory. Like, developing commercial software on either of those platforms, where you have to be able to understand and test on those platforms, or front-end web development (where you may have to take a PSD, Fireworks layered PNG, or InDesign file from a designer and recreate the depicted design, pixel-perfect, in HTML; and no, free tools that exist today can not open these files and represent them (including layers so you can clip out graphical elements as needed) anywhere near pixel-perfect.
That said, you can just as well run Linux on your development machine and keep Windows and/or OS X around for testing if needed.
you can at least turn off
I refer you to the following:
unless you compiled it from source (using a trusted compiler you also wrote yourself) from code you've fully reviewed, you're putting your trust in whoever provided the binaries, compiler, and/or source code
Take note? You mean, like, look at my own systems? I run more than a handful of Linux systems, personally. Also OSX and Windows for software that doesn't exist on other platforms; when working in an industry that uses standardized software, you run that software, which means you run the platform that software expects. No, WINE does not work for everything.
The complaint I keep seeing is not that the information is sent, but that we can't see what information is sent. There are two solutions to that problem:
A) Send the information in plaintext. Of course, then (as I already mentioned), people will complain that the data is being sent in plaintext.
or
B) Store a plaintext log of the telemetry data for the user to review. Of course, then, people will point out that, because it's sent over an encrypted connection, there is no way to verify what's actually being sent.
For examples of (B) in the FOSS community, look at the crash reporting used by Firefox and Ubuntu. Yes, Ubuntu, the entire distribution. Sure, they show you what they're supposedly sending, if you're interested to look, but the data is sent over an encrypted connection so, well, unless you compiled it from source (using a trusted compiler you also wrote yourself) from code you've fully reviewed, you're putting your trust in whoever provided the binaries, compiler, and/or source code.
So, you choose to trust a platform vendor serving thousands or millions of systems and collecting a much smaller amount of data (easier to sift through) rather than a vendor serving billions of systems and collecting a much larger amount of data (more difficult, to the point of impossibility, to sift through). You're still giving up telemetry data to your vendor and you're still relying on trust. The tradeoff you make is that you can't reliably deal with graphic designers (who use Adobe tools as a standard) and video production studios (who use Adobe, Apple, Sony, and Lightworks software as standards), nor can you sell well-tested software for Windows or OS X. Of course, if you don't need to work with designers or video studios and you don't sell software, yeah, Linux can be a workable desktop solution; and yes, that covers a rather large portion of the population. However, it also fails to cover the majority of high-paying professions.That's why people with money use Windows and/or OS X; not because they can afford to use them, but because they can't afford not to.
Careful you don't fall off that high horse, friend, you seem to be losing your grip.
To be fair, you're replying to an AC, so "nothing useful" should be the expected norm. That said, his point over "concerns" seems valid. I've certainly seen people complain that they can't see the contents of the telemetry because it's all sent over secure connections. Of course, if it was sent in the clear, these same people would complain about that, so...
1. Not all transit providers are equal. Some make better deals with peers than others.
Not all watermelons are equal, either; some are larger and/or have fewer seeds than others. In fact, outside of mathematics, it is quite rare to find two truly equal entities. Basically, inequality is a given in the real world. Hell, not all streaming video providers are equal, which is why many people subscribe to two or more. In fact, Netflix uses multiple transit providers[1-8] for similar reasons.
2. Some transit providers are less expensive because they lack the ability to make the best deals with peers.
This is just plain backwards. A transit provider who makes better peering deals has lower costs, so they don't have to charge as much! I know this seems counter-intuitive when you consider that those providers also offer a better service, as you'd think that's something they could charge a premium for, but it should make a bit more sense when you consider the corollary: a transit provider who makes worse peering deals has higher costs, which they must recoup from their customer. Sort of like how Costco charges less because they make better deals buying in bulk; or, rather, other retailers must charge more because they didn't make the same deals.
3. To cut costs, Netflix chose a less expensive transit provider.
First of all, your assertion that Netflix uses a single transit provider is just plain wrong[1-8]. It has been made public knowledge (despite being none of our damn business) that their primary transit providers are Level 3 and Cogent[1-8], and that they purchase transit services from at least 4 other providers, Tata, XO, NTT, and Telia[1,3].
As for your assertion that Netflix only buys from the lowest bidder, well, it appears that the buy from anyone who can provide transit between them and the networks their customers are on[1-8]. Not only do they buy transit from all three available providers who route directly from their POIs to Comcast's[1], they even buy transit from Comcast now[3]. And, despite that, I still see buffering issues with Netflix on a 75Mbps Comcast Business connection, which points to the issue not lying with Level 3, Cogent, or any of Comcast's other providers with names not starting with C and rhyming with "bombast".
In case you want sources, here[1] are[2] a[3] few[4] you[5] can[6] check[7]. out[8].
At least you proved you weren't trolling; I guess that only leaves one other possibility.
Footnotes:
[1] "Netflix attempted to address congested routes into Comcast by purchasing all available transit capacity from transit providers that did not pay access fees to Comcast—which involved agreements with Cogent, Level 3, NTT, TeliaSonera, Tata, and X0 Communications. Although all six of those providers sold transit to the ent
I'm sure each provider has their own agreement with each of their peers, but thats between the transit providers, not their customers. What's your point? In no way should Netflix, who is a customer of several transit providers, and not a transit provider themselves, be involved in any of that. Netflix already pays for their bandwidth. What agreements the companies they pay make with any other companies that aren't Netflix is as much their business as it is yours or mine; as long as the bits that get shoved in one end eventually fall out the other, they're getting what they're paying for and that's all anyone needs to know. The concepts we're discussing here are so simple you have to either be an idiot or a troll to not get them. I'll let you chew on that, but I'm done feeding you.
You're right, the ISP isn't Netflix's customer, the ISP is the transit provider's customer, just as Netflix is the transit provider's customer. Likewise, Netflix is not the ISP's customer.
Or, wait, should I be expecting Comcast to pay me for all the data they send down my coax, because they send several thousand times as much data my way as I send theirs? Because that's exactly what you're proposing.
Of course they refuse to pay the ISPs, the ISPs are their customers.
So the fact that Netflix pays for transit isn't relevant? Sad troll is sad.
They buy transit from whoever serves their DCs. Last time I checked, the only place you can buy transit from Comcast, for example, is at a Comcast POI. Also, consider whether Netflix is pushing traffic for Comcast's network or Comcast customers are pulling. Hint: it's the latter; Netflix isn't forcing their content onto users' systems, it's getting there as a result of the user's own request.
Netflix could have chosen to use CDNs or to buy transit directly on the large networks it wished to supply traffic to, but instead chose to use cheaper transit providers that would abuse settlement free peering links.
Netflix pushes more bandwidth than any CDN (aside from, maybe, CloudFlare, who doesn't cache video and, therefore, wouldn't benefit Netflix) can handle. While they could have chosen to work with a CDN provider who can't support them they, instead, chose to use transit providers who can actually provide the bandwidth Netflix needs (and pays for) and let them sort out the details. And before you say (or imply) that Netflix should sort the details out themselves, that's what they're trying to do in offering their own CDN boxes; and it's what any other CDN wold do on their behalf, just like the transit providers. The difference is that the transit providers don't host their content, so they're able to keep it relatively secure (as their licenses likely require). That is, they're likely prohibited from using an external CDN as you suggest.
If I missed your point, it's because your point was wrong.
Which is funny because the 4U of rack space costs them less (even considering opportunity cost) than the bandwidth it would save. The ISPs who don't want to do it are all also content providers with competing services; the majority of ISPs who don't offer a competing service do host Netflix's boxes.
17" MBP with anodizing options (space grey FTW), 5k display, a full suite of ports (including CardBus and Ethernet), new version of OS X as trim, fit, stable, and performant as Snow Leopard, and go back to the case thickness of the previous 17" model, incorporating the bottom/side vents from the Retina design, maintaining the super-compact electronics design of the current models (save for, perhaps, keeping the RAM slots from the old 17" models) and using all the now-empty space to allow airflow for proper cooling (something I've simply not seen on any Intel-based Mac laptop) and additional battery capacity. Fill the space the HDD used to occupy in the old models with battery, optionally offering a breakout board for 2 m.2 drives (with hardware RAID support) or a SATA connector for a spinning disk or SSD; do the same with the space formerly occupied by the optical drive, offering options for a breakout board for 3 m.2 drives (with hardware RAID support), a SATA connector for a spinning disk or SSD, or an optical drive.
The optical and SATA options would be rarely used by most, but a great option for those who need them, a (very spendy) market Apple is missing out on right now. Assuming 1 m.2 drive on-board, that would give us the option to trade some battery capacity for a total of up to 6 m.2 drives, with the ability to configure (if they implement hardware RAID on the breakout boards directly) up to 2 RAID arrays, one with 2 m.2 drives and the other with 2 or 3.
With all the extra battery and proper cooling, Apple could offer a desktop-class CPU (or, at least, a mobile-class CPU that won't throttle itself to death) and high-end GPU options (both for gaming and workstation use). They'd once again have a lineup that was hard to beat, like they did half a decade ago.
But you've listed none of those insults such that he may grow and learn.
Since you knew it was wrong before you posted it, and speaking of growing and learning. Also, as an example the rpresser.
You're either trying to run a fully scaled out production configuration that forces memory consumption
Precisely. I'm not just running a test suite against the code (which should have been obvious as I could run tests against code for any platform from any platform, thus negating the need to run the actual OSes) but automated functionality testing against individual builds. I need a production environment (e.g. one that closely matches what the end user will be using) in order to do that; so, yes, I'm running a fully scaled out production configuration. Out of necessity.
you're still running a MBP in the first generation SSDs, which were only 300MB/s or so
Whatever was the highest-end model they sold in January 2015. I peak over 500MB/sec for both reads and writes so I'm guessing no. Looking farther up in the discussion, I do see that i said i bought it in 2014; I'm not so 100% with timelines, I was still working for someone else in 2014 and didn't buy the rMBP until the 2011 (17") died in January 2015 when I was relying on it for my work, as I was working for myself at the time. Sorry for the confusion.
To be sure, I just checked. System Information lists it as a MacBook Pro 11,3 and About This Mac states Mid 2014.
The latest rumors have the next generation of SSDs running at 10 times that speed. More memory may not be the smartest bang for your dollar at that point.
At that point, I'm sure we'll be considering whether we should have RAM at all, beyond a small amount to store status flags to allow us to reset a deadlocked machine. That or, well, you know, RAM is getting faster, too; and if I need to use more than 16GB of it and that's all I happen to have, well, I'm still gonna be swapping to a slower medium.
Just to bring home how fast these SSDs are
I have two of them, each capable of 1100MB/sec writes, in a RAID0. I'm acutely aware of how fast they are. DDR3-1866 (which my PC laptop uses) has 14933.33MB/sec of bandwidth, about 7.5x as fast as my SSD RAID stripe in raw throughput; faster when you consider seek times. DDR3-2133 has 17066.67MB/sec of bandwidth, further widening the gap. Of course, the DDR3-1600 soldered into my rMBP has only 12800MS/sec of bandwidth, which might account for the performance variance between the two systems (until the rMBP throttles, then that accounts for most of it).
And now we have DDR4, which goes up to 19200MB/sec bandwidth in currently available modules. Faster speeds will be developed, so... wake me when I can buy an M.2 SSD that tops 20GB/sec with seek times measured in clock cycles rather than microseconds. I'll write a fat check for a couple of them.
If you're not running high-end games or video, the built-in Intel graphics should suffice just fine.
Unless you're RAM-constrained, in which case sharing some system RAM with the Intel GPU might just be the thing that gets you swapping.
gah... proofreading... "I don't produce, market, or sell them".
Yes, indeed it is, as part of another word. UltraFire, on the other hand... well, "Fire" stands on its own there. Further, my products (rather, the ones I'm using, I don't product, market, or sell them) are intended to heat up, it's what they're supposed to do, so "fire" is appropriate. A lithium battery? Not so much.
go to that link, click on the MBP picture. You'll note that when you do, it will come up with an enlarged picture with "Macbook Pro with Retina". AFAIK, they no longer sell non retina MBPs, and haven't for at least the last couple of years. To go non-retina, you have to buy a Macbook.
You, sir, are mistaken. They do appear to have an error on their site, not surprising given that they've let this model stagnate; however, if you head back to the Buy page and look at their offerings, you'll see that, at the bottom, below the "with Retina" listings, there is a lonely little listing for the 13" MacBook Pro. That is what I linked to. Now, if you click on Tech Specs, you'll see a side-by-side of the two Retina models; scroll down again. See it there, under the Other Models heading, just above Accessories? "13-Inch MacBook Pro Tech Specs" is the label and it's 1280x800, certainly not Retina.
I do the same, and my MBP and 1 external 2TB disk carries everything I "need"
Uh... I don't see how an external disk has any bearing on the amount of RAM available for running additional operating systems in a virtualized environment, but okay... I find, quite often, that my Mac is using upward of around 12GB of RAM (minus buffers, caches, and the like) while my PC sits comfortably at just over 8GB running the same applications. That's just running my IDE, a couple browsers, Skype, and a few terminal sessions.When I get to testing my application on various platforms, well, that puppy eats up another 4GB once it gets going (I should clarify, the test suite uses most of that, not necessarily the application itself). So let's do some quick back-of-napkin math (and we'll even ignore the RAM used by guest OSes, a concession I'm openly making in order to illustrate my point): RAM used by Mac running typical software and dev tools [12GB] + RAM used by test suite on OS X [4GB] + RAM used by test suite on Windows [4GB] + RAM used by test suite on Linux [4GB] = 24GB. You're right, I can't see any way 32GB of RAM in a MacBook Pro could be useful. None. At. All.
You know, if I could do it legally, I'd just throw the 32GB in my PC and run OS X in a VM and call it a day. But I can't, and I also can't buy a MacBook Pro with 32GB of RAM and the models that come with RAM slots only support up to 16GB (again, only 8GB officially); so, I carry 3 laptops when I know I'm going to have to work remotely.
I mean, I could shut down my IDE, close my browsers, kill Skype, and run the tests on OS X first, then boot the Windows VM and run the test suite there, then kill that and boot the Linux VM and run the test suite there... you know... that might work. In fact, it does work, it's what I do when an over-night trip turns into a full week (e.g. I wasn't planning on having to work, so I only brought the Mac); yeah, it works, except that it literally takes 3x as long, requiring manual intervention (e.g. I have to switch VMs manually and actively monitor progress, lest it take longer because I left it sitting idle when the test suite on one OS completed), and I still wish I'd brought a 2nd laptop so I could still have a usable computer while all of that was going on. Yeah... nah... if I have to carry 2 laptops anyway, carrying a 3rd is less hassle than cycling through VMs, adding another manual procedure to the testing process, and making the already lengthy test suite take 3x longer to run. I absolutely abhor taking a 2hr process and turning it into a 6hr process, as it adds 4hr to my workday.
I'm good with not doing that; I just won't buy another Apple computer until they sell something that fits my needs. If the one I'm using currently (well, there are two but one won't boot OS X anymore for reasons discussed earlier in the thread) happens to break before Apple starts selling somethi
Interesting, I'm certain the T&C state that "by using, or continuing to use, this software, you agree to these terms and conditions", or something similar.
I suppose one could argue that, since they don't agree with the T&C, they don't agree with the stipulation set forth in said T&C that use of the software or service constitutes agreement with the T&C. It'd be interesting to see how that'd play out in court.
And that's if the T&C never change! If they change, you should be reading over the old, then the new, and noting what changed. For all 33 apps, that's 30hr to read the old, 30hr to read the new, and 10-30hr to identify differences; so, 70-90hr every time they change. Of course, they won't all change at the same time, but you get the point.
Hey now, just because someone has agreed to let you do something doesn't mean you're bound to actually do it.
And I question your knowledge of Apple's product lines given the following:
when they stopped selling non retina MBPs
Because, well, it seems they still sell the 13" MBP which, really, should have been obvious since I linked to it earlier in the thread.
For references, as a software developer who tests on all common platforms, gaming is not my focus either (I have consoles for that). 32GB in one machine capable of legally running OS X without a bunch of hackery would mean I no longer need to maintain 3 separate systems for testing purposes, which is why I'm seeking precisely that. No, a Mac Pro is not the solution, as it lacks the portability I often need. One of the perks of working for myself is that I can work from wherever (this means traveling with the wife when she goes to visit family), which basically requires that all of my equipment be portable.
+1 for holding off on the 10.11 upgrade, though; if I can't have Snow Leopard, Yosemite is the next best release IMO.
core clock speed is no longer increasing
Ah, but instruction efficiency is. Don't underestimate how important that is; you'll note that the performance of each subsequent release from Intel exceeds that of the previous generation at the same clock speed. Well, given your workload you might not, but a lot of others do, myself included.