R&D gets money from the sales. Subsidies help lower the entry barrier and grow the market. Larger the market - more money gets into the R&D.
Lots of things were not viable initially without gov't help. Public transportation, metallurgy, telecommunications, energy - are all the industries gov't helped to jump start by giving subsidies and tax breaks. Because there is no single party - or group of parties - large enough to finance the whole thing till it becomes, as you put it, "compelling economic option".
It's pretty stupid to compare economic viability of 50+ year old industry (covering 90+% of market) with 10+ year old industry (striving to gain a percent or two).
I like how pragmatically Germans went after the solar: it makes sense in long term, thus it makes sense to start R&D sooner than later. And apparently it is going well enough that they are even planning to repel the subsidies (to much chagrin of some).
Unlike x86, each and every arm platform boots in a slightly different way. Thus, most of work of getting Debian running will involve dealing with bootloader and Kernel. Which is not really debian-specific work. After that, people can start working porting debian-installer for the system in question.
Something tells me that we have another weirdo ARM board with its own "Debian" distro, joining the disarray ranks of dozen others: poorly supported, barely maintained, and soon forgotten.
Considering the total amount of effort invested (and wasted) by developers into building the custom distros, I'm surprised (and disappointed) that nobody has actually stepped up, organized and standardized booting/etc on the ARM SoC yet. (IMO ARM Ltd itself should have done that a decade ago, since IMO it is one of the major roadblocks to the broader adoption of the ARM.)
N.B. Historically, I actually had more termal problems related to the Intel's than to AMD's CPUs.
But it is true that in the power efficiency department, the Intel i-series are better than the AMDs.
Though it is not a clear cut, if you take the whole system power consumption. Intel CPU + nVidia GPU would draw about the same (or more) power as AMD's comparable integrated CPU/GPU.
Note that, in comparison to ARM CPUs, x86 SoCs are *crazy* overpriced. There are superb ARM SoCs for just 20 USD. WTF are you doing selling similar consumer-grade chips for 100 USD??
ARM CPUs still do not have proper pipe-lining. Out-of-order execution is castrated too. That basically kills ARM CPUs in any workload with lots of math (think games and encryption).
And how about the CPU cache? 1MB of cache for ARM is still a high-end feature, while most desktop CPUs have 4 or more MB of cache. Huge HUGE difference for the memory bandwidth.
ARM has its niche (which if ARM really wanted could have been very very broad and not niche at all) but as soon as you start gaming or do any real work, they simply pale in comparison.
P.S. The use case I was researching in the past was the VPN. Most modern ARM SoCs hit around 1-2MB/s of sustained traffic encryption (on single core). My very old Intel CPU easily hits ~8MB/s (probably more, don't have bandwidth to test) on single core. And the ARM SoCs with quad-core >1GHz CPUs, which can do more than 1MB/s, cost more than $20. (E.g. ODROID U3 - $70.)
How is Windows not fragmented being that there are multiple versions out there from XP up to Windows 8?
Because MSFT provides a stable base API which changes rarely/slowly. All extra bells and whistles are separate APIs. One can still compile natively 20yo Win32 WinAPI application and it would run without any problems.
That's also a part reason why Windows is relatively bloated: there are multiple APIs/API versions available simultaneously for backward compatibility.
That's what makes Window not fragmented: lots and lots and lots of hard work on part of Microsoft.
In comparison, the Google is like a spoiled child: grabs new toy, plays with it for a minute, breaks it, throws it away 'cause it's broken and moves on to the next toy.
How Google can make the updates mandatory, if they keep bumping up the H/W requirements with every release?
And in what universe a major OS overhaul still qualifies as an "update"?
Some vendors are pretty active in the Android development, but they simply can't expose themselves to the risks involved in supplanting a whole OS to just fix few bugs. Important bugs - yes. But the risk is the bricking of the whole device, of which Google would bear no brunt, while manufacturers are exposed 100%.
Google's stance on updates (and lots lots of other things) is simply lazy, arrogant and short-sighted. I can't even start guessing why some people (especially here) keep evangelizing them so much. (Though, earning shitload of money while being lazy and arrogant, might explain it.)
I have worked ~5 years in maintenance and have intentionally omitted it.
In maintenance, for it to be any effective, the problem is even worse: you have to be twice as creative, to find solutions which do not have side-effects yet fit the original specification/requirements.
I have seen many results of maintenance done by the "generic" outsourced stuff and on average they were not spectacular, and occasionally they were outright disastrous.
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned.
Why people forget the creative side of programming?
The programming is indeed bunch of skills. But if you do not have right mind set - inquisitive and creative - your career in programming would be full of frustration.
The only software where one doesn't really need any creativity - is already written and there is literally no work there.
P.S. Of course there is the "flip side" to the creative side of the programming - "monkey" coding and testing. But for most of this work you do not even need to have any deep programming skills. Reading and comprehending documentation fully (an ability which is again easily forgotten by the sensational headline writers) is more useful and also much under-appreciated. And then there is also the writing of tech documentation...
HTTPS is already designed with that kind of decoupling in mind. But it wouldn't make sense to offer encryption without identity verification to the end-user, because that would make the encryption useless, so any protocol that does encryption has to do both.
I know that. That's basic AAA.
Also note that for an effective MITM attack you would need to have new certificate for which you have got the private key. There are a number of things that will make this increasingly difficult in the future, like certificate pinning, increased willingness of browsers and OS vendors to blacklist CAs, and increased monitoring for rogue certificates which makes it easier to find rogue CAs.
I think you fail to realize the scale, the proportions, of the opposition the browsers face.
It's not some script kiddies who are threat here.
That's countries covering close to a half planet's population. They might as well simply outlaw the browsers. In fact, they already do outlaw some encryption software.
I personally would still argue that the CA system is the Achilles heel of HTTPS but the situation is getting better and it's a matter of time until we get a more distributed and robust way of certificate verification.
But that's another problem: you can't make CA distributed. CAs are the "single point of failure" which are allowed to be that, based on the promise that they will work hard not to fail. Making it distributed would basically nullify the promise, making the whole CA system vulnerable. IOW, nothing changes.
Even with the identity verification, the encryption is not a guarantee against the MITM.
Because the man (the one in the middle) could have hijacked the certificate.
The oft quoted example here is the China injecting the JS into the unencrypted traffic. They probably do not even need to hack anything to hijack the certificate - they likely already have the laws which force the CA to hand over the certificates legally. And once that happens, back you are at the drawing board.
Decoupling at least allows the two technologies (A) to be developed independently and (B) to be easier replaced.
[...] TLS on TCP is lots slower when there is any packet loss.
And how a (almost) stateless protocol like QUIC supposed to handle the packet loss any better?
The previous write-ups about the Google protocols were all like one based on the premise that packet loss is a very very rare occurrence. That's why they use effectively a stateless transport: because they assume that errors are rare. In other words, they are too very bad at handling it.
Coming from the old days of IPX vs TCP debates, I remember how the IPX proponents were going abruptly silent in the face of a bad network connection: IPX wasn't able to transfer literally anything, while TCP slowly was churning data, allowing to download OS update and fix the issue. It would be hilarious (and not unexpected) if (or rather when) Google would step into the same cowpie.
3D graphics is an outlier in the driver development.
But for a useable desktop, 2D graphics is sufficient. The 2D is commonly supported via GPU's ROM and as such implementing a 2D driver isn't hard.
Even 3D in itself isn't as hard. The problem is that games require (A) lots of edge cases optimized and (B) huge number of acceleration features implemented.
If you insist on your definition of RAD you'll likely run into limitations (any RAD system) and be disappointed.
No, I will not be. I have used in the past the Borland Delphi for 5+ years and well aware of the limitations which come with the paradigm (rigid system libraries, "there is only true way to do it", "if there is no button for it, it's impossible", and so on). (And yes, to this day, I deeply hate Borland Delphi.)
I'm interested in RAD for specific purpose, so to say. To show that GUI development can be as easy as writing 10-20 lines of shell, but with the bonus of having a UI which is little bit more than text console. And, well, introduce some GUI into the Linux part of the product.
I don't really see the point of full RAD to be honest.
I do not look at them as a programming language or programming environment.
I see them as a tool to quickly develop and deploy a simple GUI, when the text console doesn't cut it.
Slashdot Mirror
By the looks of it, they are talking about new rail track.
If there is a problem of delays with the current one, that means the rail system doesn't have redundant tracks to route the traffic around a problem.
One more track, less chance of one broken train holding up the whole traffic.
My guess is you will find some way to justify the idea that it isnt a subsidy... just like right here where you found a way to ignore it completely.
I haven't ignored it.
I simply can't understand your condescending tone about it.
It is pretty normal for gov't to jump start industry by helping it one way or another. It happened (and happens) in a lot of important industries.
But you are acting here as if it was something weird and unusual.
R&D gets money from the sales. Subsidies help lower the entry barrier and grow the market. Larger the market - more money gets into the R&D.
Lots of things were not viable initially without gov't help. Public transportation, metallurgy, telecommunications, energy - are all the industries gov't helped to jump start by giving subsidies and tax breaks. Because there is no single party - or group of parties - large enough to finance the whole thing till it becomes, as you put it, "compelling economic option".
That is why they pin hope on R&D, and not scaling, to get us their.
And in your opinion, where from come the R&D money? From Santa Claus?
In other words, it presently is not a compelling economic option.
You need to read about economies of scale.
It's pretty stupid to compare economic viability of 50+ year old industry (covering 90+% of market) with 10+ year old industry (striving to gain a percent or two).
I like how pragmatically Germans went after the solar: it makes sense in long term, thus it makes sense to start R&D sooner than later. And apparently it is going well enough that they are even planning to repel the subsidies (to much chagrin of some).
runs a version of Debian.
What does that mean? From the official Debian wiki:
Porting to new platforms
Unlike x86, each and every arm platform boots in a slightly different way. Thus, most of work of getting Debian running will involve dealing with bootloader and Kernel. Which is not really debian-specific work. After that, people can start working porting debian-installer for the system in question.
Something tells me that we have another weirdo ARM board with its own "Debian" distro, joining the disarray ranks of dozen others: poorly supported, barely maintained, and soon forgotten.
Considering the total amount of effort invested (and wasted) by developers into building the custom distros, I'm surprised (and disappointed) that nobody has actually stepped up, organized and standardized booting/etc on the ARM SoC yet. (IMO ARM Ltd itself should have done that a decade ago, since IMO it is one of the major roadblocks to the broader adoption of the ARM.)
Hotter, but not so hot as to cause problems.
N.B. Historically, I actually had more termal problems related to the Intel's than to AMD's CPUs.
But it is true that in the power efficiency department, the Intel i-series are better than the AMDs.
Though it is not a clear cut, if you take the whole system power consumption. Intel CPU + nVidia GPU would draw about the same (or more) power as AMD's comparable integrated CPU/GPU.
Note that, in comparison to ARM CPUs, x86 SoCs are *crazy* overpriced. There are superb ARM SoCs for just 20 USD. WTF are you doing selling similar consumer-grade chips for 100 USD??
ARM CPUs still do not have proper pipe-lining. Out-of-order execution is castrated too. That basically kills ARM CPUs in any workload with lots of math (think games and encryption).
And how about the CPU cache? 1MB of cache for ARM is still a high-end feature, while most desktop CPUs have 4 or more MB of cache. Huge HUGE difference for the memory bandwidth.
ARM has its niche (which if ARM really wanted could have been very very broad and not niche at all) but as soon as you start gaming or do any real work, they simply pale in comparison.
P.S. The use case I was researching in the past was the VPN. Most modern ARM SoCs hit around 1-2MB/s of sustained traffic encryption (on single core). My very old Intel CPU easily hits ~8MB/s (probably more, don't have bandwidth to test) on single core. And the ARM SoCs with quad-core >1GHz CPUs, which can do more than 1MB/s, cost more than $20. (E.g. ODROID U3 - $70.)
Cheaper. AMD always was and is cheaper than comparable Intel parts. Ditto AMD vs nVidia.
For the lower price you lose some performance, especially in the edge cases. But for most tasks, the difference is almost negligible.
P.S. Though the case is different in the gaming, where pretty much the whole market optimizes exclusively for the Intel/nVidia.
Easily believable if PassMark was compiled using icc (Intel C Compiler).
How is Windows not fragmented being that there are multiple versions out there from XP up to Windows 8?
Because MSFT provides a stable base API which changes rarely/slowly. All extra bells and whistles are separate APIs. One can still compile natively 20yo Win32 WinAPI application and it would run without any problems.
That's also a part reason why Windows is relatively bloated: there are multiple APIs/API versions available simultaneously for backward compatibility.
That's what makes Window not fragmented: lots and lots and lots of hard work on part of Microsoft.
In comparison, the Google is like a spoiled child: grabs new toy, plays with it for a minute, breaks it, throws it away 'cause it's broken and moves on to the next toy.
Google on On Android Compatibility
The article is 5 years old, which is in the Google universe is like couple millennia. They have changes pretty much everything since then.
Then make a point to push for a model where every major X. release gets X.Y minor updates and bug fixes.
AFAIK that's how it worked - till 4.x series.
But with 4.x series Google has broke the pattern: almost every 4.x release was a major release with incompatible interface.
Effectively of Android 4.x, the Android OS is on a rolling releases.
How Google can make the updates mandatory, if they keep bumping up the H/W requirements with every release?
And in what universe a major OS overhaul still qualifies as an "update"?
Some vendors are pretty active in the Android development, but they simply can't expose themselves to the risks involved in supplanting a whole OS to just fix few bugs. Important bugs - yes. But the risk is the bricking of the whole device, of which Google would bear no brunt, while manufacturers are exposed 100%.
Google's stance on updates (and lots lots of other things) is simply lazy, arrogant and short-sighted. I can't even start guessing why some people (especially here) keep evangelizing them so much. (Though, earning shitload of money while being lazy and arrogant, might explain it.)
I have worked ~5 years in maintenance and have intentionally omitted it.
In maintenance, for it to be any effective, the problem is even worse: you have to be twice as creative, to find solutions which do not have side-effects yet fit the original specification/requirements.
I have seen many results of maintenance done by the "generic" outsourced stuff and on average they were not spectacular, and occasionally they were outright disastrous.
The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned.
Why people forget the creative side of programming?
The programming is indeed bunch of skills. But if you do not have right mind set - inquisitive and creative - your career in programming would be full of frustration.
The only software where one doesn't really need any creativity - is already written and there is literally no work there.
P.S. Of course there is the "flip side" to the creative side of the programming - "monkey" coding and testing. But for most of this work you do not even need to have any deep programming skills. Reading and comprehending documentation fully (an ability which is again easily forgotten by the sensational headline writers) is more useful and also much under-appreciated. And then there is also the writing of tech documentation...
HTTPS is already designed with that kind of decoupling in mind. But it wouldn't make sense to offer encryption without identity verification to the end-user, because that would make the encryption useless, so any protocol that does encryption has to do both.
I know that. That's basic AAA.
Also note that for an effective MITM attack you would need to have new certificate for which you have got the private key. There are a number of things that will make this increasingly difficult in the future, like certificate pinning, increased willingness of browsers and OS vendors to blacklist CAs, and increased monitoring for rogue certificates which makes it easier to find rogue CAs.
I think you fail to realize the scale, the proportions, of the opposition the browsers face.
It's not some script kiddies who are threat here.
That's countries covering close to a half planet's population. They might as well simply outlaw the browsers. In fact, they already do outlaw some encryption software.
I personally would still argue that the CA system is the Achilles heel of HTTPS but the situation is getting better and it's a matter of time until we get a more distributed and robust way of certificate verification.
But that's another problem: you can't make CA distributed. CAs are the "single point of failure" which are allowed to be that, based on the promise that they will work hard not to fail. Making it distributed would basically nullify the promise, making the whole CA system vulnerable. IOW, nothing changes.
Even with the identity verification, the encryption is not a guarantee against the MITM.
Because the man (the one in the middle) could have hijacked the certificate.
The oft quoted example here is the China injecting the JS into the unencrypted traffic. They probably do not even need to hack anything to hijack the certificate - they likely already have the laws which force the CA to hand over the certificates legally. And once that happens, back you are at the drawing board.
Decoupling at least allows the two technologies (A) to be developed independently and (B) to be easier replaced.
I'm sure the users will appreciate the extra traffic!
Only users??
Most serious hosters still charge by traffic. The web-site owners too would appreciate the increased traffic and higher bill.
Just decouple the traffic encryption and the identity verification already.
[...] TLS on TCP is lots slower when there is any packet loss.
And how a (almost) stateless protocol like QUIC supposed to handle the packet loss any better?
The previous write-ups about the Google protocols were all like one based on the premise that packet loss is a very very rare occurrence. That's why they use effectively a stateless transport: because they assume that errors are rare. In other words, they are too very bad at handling it.
Coming from the old days of IPX vs TCP debates, I remember how the IPX proponents were going abruptly silent in the face of a bad network connection: IPX wasn't able to transfer literally anything, while TCP slowly was churning data, allowing to download OS update and fix the issue. It would be hilarious (and not unexpected) if (or rather when) Google would step into the same cowpie.
opengl driver
3D graphics is an outlier in the driver development.
But for a useable desktop, 2D graphics is sufficient. The 2D is commonly supported via GPU's ROM and as such implementing a 2D driver isn't hard.
Even 3D in itself isn't as hard. The problem is that games require (A) lots of edge cases optimized and (B) huge number of acceleration features implemented.
Writing drivers isn't hard.
But for the broader acceptance of an OS, one needs a whole shitload of them.
In the past, a computer with a half dozen devices was "packed". Today? A cheap tiny ARM SoC easily runs up to 30+ built-in devices.
Not replaced, you dummy.
Elevated to a new level.
Sorry, GP meant: the only fully hardware accelerated encryption method; implementation is approved by Intel Inc.
If you insist on your definition of RAD you'll likely run into limitations (any RAD system) and be disappointed.
No, I will not be. I have used in the past the Borland Delphi for 5+ years and well aware of the limitations which come with the paradigm (rigid system libraries, "there is only true way to do it", "if there is no button for it, it's impossible", and so on). (And yes, to this day, I deeply hate Borland Delphi.)
I'm interested in RAD for specific purpose, so to say. To show that GUI development can be as easy as writing 10-20 lines of shell, but with the bonus of having a UI which is little bit more than text console. And, well, introduce some GUI into the Linux part of the product.
I don't really see the point of full RAD to be honest.
I do not look at them as a programming language or programming environment.
I see them as a tool to quickly develop and deploy a simple GUI, when the text console doesn't cut it.