Apple has reinvented themselves before and when whatever train they're currently on runs out of steam they'll likely do it again. Back at the introduction of the Macintosh they were about saving users from conformity. Eventually they ended up getting so far in the hole their saving grace came from Microsoft and now it's the complete opposite, conformity and lack of choice is their game.
So I guess you still live in your basement? There is a world out there. And Macs have very low adoption (single digit) within corporations.
But he has anecdotal evidence!
LOL - you realize the the original iPhone allowed *only* HTML/JS apps?
you realize they they ditched that favor of the "app" model?
Remember: Sometimes allowing more people to play has benefits, even if they do take their bat and ball and go home at the end.
And this is what we see with Apple's OSX, sure they haven't released all the source code for the operating system but since many of its parts are built on permissive open source licenses rather than restrictive ones those parts can be used in the closed source operating system but also released as source for other people to use.
For example Safari is not open source but we sure get a lot of contributions to WebKit which is used in lots of places.
It must be GPL-compatible, it must not be GPL.
Why not? Based on the listed licenses GPL should still be fine.
You can release _your_ code under whatever license you choose, as long as the license doesn't conflict with the GPL as applied to the derivative work as a whole.
Right, what he should have said was "GPL-compatible" license.
There's nothing "viral" about the GPL which distinguishes it from any other form of licensing. The BSD license is "viral" in that any derived works still have to obey the copyright notice requirements. Closed source licenses are "viral" in the sense that if your work uses closed-source software, your derivative work is subject to the restrictions and limitations of the closed-source license.
There is a degree of difference there though. Yes the BSD license is equally "viral" but the implications and restrictions imposed are significantly less of an imposition than those of the GPL. The same applies to closed source software which is why closed source and BSD software can be sold in the Apple App Store but GPL software cannot.
The only real issue here is the GPLv3's patent license requirements.
Well that depends on if he wants to distribute this iOS program in the App Store.
An upstart breaking that system means going back to the bad days when taxis were unregulated.
Then that alone should already be enough incentive for people to use regulated taxis rather than Uber. If I end up with taxis refusing a fare for being too short or telling me they're going to take 30-45mins for pickup then of course I'm going to use Uber instead. The problem is taxis have a protected monopoly so there is no competition to worry about, you can say the regulations mean they can't discriminate on fares and that this will mean there are always enough taxis but the fact is that shit does happen and when you're on the street the ability to have an alternative is a good thing!
Wow, what's happened to this place? Someone says Linux is better than Windows and gets marked flamebait.
Probably because the "operating system X is better than operating system Y" kind of argument either with no context or on subjective grounds is flamebait.
Seriously though, why all the flat colored squares? Somebody needs taking out the back for a good talking to.
Clue: It's not "clean", it's dull and uninspiring.
And 10 years ago people said "why all the semi-transparent nonsense"? It's just gimmicky and pointless, like wobbly windows.
I'd like to be able to use Linux. Unfortunately I need hardware support and a software library that has professional grade software, which are things that Linux will never be able to provide.
I wouldn't say that, there's no reason they couldn't be provided on Linux but really there is no reason for the hardware and software vendors to expend the effort to support it.
AMD has great notebooks chips (look at Carrizo) too, but nobody offers them, as in old "@HP we will give you our processors for free! No, thanks" times.
That's true but you have to remember the OEMs then suffer on volume discounts so it's a case of switching everything to AMD. Now of course they could just have a small subset of systems with AMD chips but it's not a matter of just switching CPUs, you also have to redesign and manufacture the tooling since you need to design a whole new motherboard (usually one of each different chassis too) which is often not economically viable if it is for a small run of systems especially if you're running on thin margins already. AMD also didn't have integrated graphics back then like Intel did so you needed to sort out a GPU too. This is why the Athlon XP-M was often an option in more highend systems with dedicated GPUs like the Clevo and Alienware (pre-Dell) systems.
So it's not quite as simplistic as you might think, the cost of CPUs is only one tiny part of it.
Who told you that? Maybe you should try firing up some thread monitors before you talk this bullshit. Most games of any complexity, and even many games of virtually none, are multithreaded. This was mostly true even before the advent of the Xbox 360, but after that just about every cross-platform game became multithreaded, with at least three threads. Since Microsoft and Sony have both gone to consoles with eight cores, multithreaded games are even more ubiquitous.
So no, you're full of crap right there.
Well there certainly are more threads in use, but the real question is what are they doing? The biggest bottleneck in games - as far as the CPU is concerned - is setting up your command lists and buffers. In current GPU APIs this is a sequential process and is inherently single-threaded. You can do multithreading to some degree (see DX11 multi-threading) but the actual access to the immediate context is single-threaded so you suffer the synchronization penalty anyway which is why DX11 single-threaded vs multi-threaded is such a mixed bag performance-wise.
DX12 and Vulkan aim to change that by reducing the responsibility of the driver and moving that responsibility to the application, this allows for a less sequential pipeline.
So you're somewhat right but the question isn't how many threads there are but what they are doing, also your suggestion of a thread monitor will often produce a bit of a red herring since it will also collect synchronization overhead. For example you can have it show one core maxed out and then 8 cores maxed out but the application doesn't run any faster, the reason is the same: the pipeline is inherently sequential so the usage you are seeing is just busy-wait, it's not actually doing anything though, sometimes this overhead is so large you see it actually making the multi-threaded version run slower.
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.
