Re:Uh...it's still there, you know
on
The Web We Lost
·
· Score: 1
. But they've probable contributed more to a free and open internet than anyone since Mozilla thrashed IE.
I agree with you on Google. Just to ad $.02. After AOL stopped funding Mozilla, Google was who took over. The reason that Mozilla had the money to grow from 10% marketshare to 30% was Google, so they get at least 1/2 credit for that one too.
The big change in the web was 1993 when AOL users came on Usenet. Imagine for a moment what the internet would be like if everyone had to use real name accounts tied to workplace email, but all the employers were more or less cool and not paranoid. There was little security and machines tied together with RSH, rlogin... and where the machines didn't tie together you could freely use low security protocols like FTP, Telnet and RSH. There was no spam. No unethical, "man in the middles".
This article is about minor shifts in data aggregation. The big shifts IMHO were:
a) anonymity b) commerce c) the move from text based to image based (i.e. HTTP replacing Gopher and for information) d) the death of Usenet and it being replaced with web based forums
I have no idea if the social media sites creating add on services but making the data harder for APIs is a good or a bad thing. What I can say though is in the scope of things it is not that huge a change.
IMHO IPv6 and going back to a world where every machine is directly accessible by every machine. That potentially could really create connection like we had 20 years ago.
A calculate doesn't have the same form factor as a laptop / desktop. You are going to want to take advantage of that additional space.
A good deal of what you are asking for spreadsheets do. When you need more than that, throw me in as another vote for Sage to create something like a MathCad type environment. Also I agree bc is a good choice for quick and dirty manipulations.
There is nothing to fund here. iOS can operate without the provisioning file model. That's how cydia works. Any iPhone owner who wants to can enable loading software without provisioning files.
As for security: Android, Linux (in general), Windows and OS X aren't remotely as secure as iOS. iOS is more on par with something like OpenBSD, EnGarde Secure Linux or NSS Windows 7. Customers seem to be extremely enthusiastic about the enhanced security. They seem to love being on a system that is immune to viruses unless the end user deliberately disables security features.
Now you mention something about funding. To the best of my knowledge there are no permissions based systems that are as secure as capability systems. So yeah Apple has insane amounts of cash, but you are talking theoretical computer science here. We have no idea what it would cost to deliver iOS security without the provisioning system.
Third, users should ultimately be the ones choosing between security vs. functionality... not the vendor. The device is owned by the user, not the vendor.
Apple agrees with you. What they don't want to create is a situation where users are pressured into reduced security by developers. Users who are knowledgeable enough to make those choices can do whatever they want. If you know enough to make those choices then you know enough to create your own provisioning files for your device. They know how to bypass the security mechanisms and push stuff through from the command line on their mac. And similarly for the naive who have friends with developer licenses their friends can create a provisioning file.
If they have a friends / business that's willing to fully support them they can register with a different set of servers using the Enterprise SDK. Apple doesn't make it impossible or even very difficult.
The problem that most people have is that Apple customers really like Apple's strict management and aren't willing to opt out of the security features. But that is the users making a choice.
Agreed everything in the chain needs to be trusted. But under Microsoft's design you had untrusted subsystems that wouldn't be part of the trusted chain. There were multiple chains.
OSes work this way. Most users are untrusted and have low permissions, other users are trusted and have more permissions. The thing making the determination about who has access to what needs to be trusted. Browsers have the same idea.
Trusted computing just applies these ideas all the way from hardware interfaces to memory reading and sharing to DRM files to application libraries.
The FSF is a terrible source on these issues. They tend to conflate:
a) What vendor X is specifically proposing with what other vendors are doing. b) What is proposed from what the technology enables c) The purpose as defined by the vendor and a worst case scenario.
I like the FSF but on this issue their propaganda has gone well beyond just being mildly overstated.
In particular in Microsoft's / Longhorn / Palladium case, there was also going to be an untrusted part of the system that could run any code. That untrusted part was where most programs were going to live and it would have access to do anything to untrusted parts of the system including most hardware, provided a trusted application was not also running. If a trusted application were running it would have virtualized hardware. That's just not what Apple does.
Apple allow interpreters providing the interpreters are marketed to people who understand what they are getting. See Gambit Scheme, Lua interpreters, or ND1 (RPL language), Codea (children's language). They are also working on Ruby Cocoa to allow interpreted code.
But it would definitely support more indie development which is one of the greatest things money just can't buy.
The iOS store has been a huge success for indie and small development. For small developers reduced marketing costs, customer processing, reviews.... are easily worth 30%. It is bigger developers that see that cost as punitively high.
As for opening the platform up. The problem is one of security. The security model on iOS requires the generation of provisioning files. Which means Apple ultimately has to support the distribution on an individual software -> device level. If you don't want to use provisioning files and just load whatever you want, that's just jailbreaking and that has been widely available throughout the iPhones life.
No there weren't in terms of meaningful marketshare. Microsoft's share has been well over 85% for almost two decades and as high as 95% during some of that time. iOS doesn't come close.
How is Apple killing OEMs that sell PCs other than Apple won the high profit high end? It certainly wasn't Apple that advised the PC OEMs to engage in a race to the bottom cost war, cutting their margins and their R&D budgets further and further. That was something they did to themselves, and something Microsoft did encourage at the time. This year's midrange PCs are very innovative and show what the OEMs should have been doing all along.
As far as developer freedom and Apple most of the people who complain most bitterly about Apple's policies on/. aren't Apple developers. They are quite often wrong on the facts, and misleading. You can't "take on" a product you don't use. The discussion among Apple developers are on issues like upgrade pricing and customer communication. The restrictions that bother the Android people are generally seen in their context by Apple developers.
Microsoft / Office is an exception to the iOS business because of its marketshare and dominance. This article is just about money not freedom.
Palladium allowed for data security. It wasn't about restricting applications at all it was about allowing PCs to have trusted computing. That's not something Apple to this day really offers, though they've put in place a lot of it.
As an aside, Palladium had encryption technology implemented in hardware with multiple keys that were one way storable. This is quite a bit more advanced than Apple's fused device UID/GID AES key. So no, not Palladium to the letter.
MySQL makes their money now via. Oracle contracting. When they were an independent company they made their money selling commercial licenses for MySQL. There were no proprietary extension they sold.
It seems to me that this is the fundamental problem with GPL, and some other, open source licenses; it all depends on the honor system. Sure, they are technically legally binding, but if nobody holds anybody's feet to the fire, that means nothing.
Your problem is with the whole notion of civil law, where people enforce their own contract rights. The GPL is a license which exists within the body of copyright law. It automatically inherits problems from copyright which automatically inherits any problems from civil law.
He's right it is spyware. And that's fine. But what he needs to be is very very careful in making sure to be as fair as possible in his factual descriptions including all the minor differences so there aren't factual disputes that he is misrepresenting the situation.
I've been a big fan of the FSF since around 90/91 when Peter Norton's speech introduced me to them. RMS has done tremendous things for free software. But overly aggressive and unbalanced criticism doesn't help the causes he is advocating. If the person being critiqued believes that charges are (1) simply wrong on the facts and then (2) exaggerated in the effects they just ignore the criticism. One or the other can be effective, both just comes off as unhinged.
I hate to say this, but this is becoming pattern for RMS.
Why would you want to run Cydia? Cydia is a cool stuff for iOS that Android has and often many times over. The advantage would be to run the hundreds of thousands of Apple app store apps on Android.
. Yet, if that were the case, functional programs along with functional compilers would already be producing programs substantially faster on vectorizing CPUs
I would argue they are. The entire high speed graphics libraries that are used by GPUs are a good example of this. Graphics are way faster today because of the functional code that is executed on GPUs. Another example of this massive parallelism is Google's use of map / reduce which starting in the late 1990s allowed them to do a decomposition of the entire internet regularly.
Of course, I know the above isn't that simple and it helps little that poor programmers who can functional languages may well code so badly to miss out on most the compiler benefits.
No I actually think even poor programers can benefit from this. The problem is that functional compilers are much less sophisticated than structured / object oriented ones. Compiler theory and CPU theory over the last 3 decades has been about making C code run fast, and then a lot about virtual CPUs with bytecode. Functional compilers in some senses are a generation ahead in terms of innovations but in terms of raw performance about a generation behind. GCC used to be like this, very innovative but about much slower than good compilers. Linus' team worked hard for about 6 years to get GCC's performance up and by the early 2000s they had. Someone is going to have to do something similar, a GHC that's much less feature rich but much faster.
Certainly, I'm not holding my breathe for a [near] purely functional language based OS.:)
I am. I think huge number of CPUs being standard and diverse semi-independent chips to boot will make this more and more necessary. You see this already in hardware languages, the shift towards functional has been profound. Right now that functional code is shielding the end users from the complexity of modern hardware but I'd assume that eventually people will want OSes that take better advantage of what the hardware could potentially do. Apple's focus on performance is a real change in an industry which had moved away from performance towards inexpensive, they are raising the bar.
I suspect that many of the dynamic languages will move in a functional direction and to get performance will have their systems written more functionally. Perl 6 being a good example of the change that's happened in just a few decades, where a lot of ideas from GHC and Haskell have bled over. If Perl6 hadn't stagnated it would be out years ago and would have like Scala and Clojure have moved the industry more in a functional direction.
So, instead, I think we're left to further designs of compilers to tackle that mythical 10-% of code which, I think, may well account for much closer to 99% of code on many systems.:/
You and I don't disagree that if you don't use functional it is 99%. My point is that once the programmer needs to give the system that much isolation and hints he might as well write functional. But obviously if the system could work on out of the box C# that's huge. Microsoft's research is very cutting edge and if they get this to work they have the kinds of advantages that it will be hard for anyone to compete with for a decade or more.
rogrammers already do it all the time in object oriented programming though encapsulation and method-based access
I agree that's why it is possible to have objects reside on clients and go parallel in that way. But that often isn't a very good division of labor and communication between threads can be too expensive. Just having a couple thousand threads around even if most are blocked might be good enough to get some boost and certainly at least they are able to make use of additional CPUs but I don't see that as similar to being able to cleanly divide a large workload with low communication needs like in functional.
As far as the weakness for functional. What I see is the big advantage is that encourages you to write the bulk of your code in a way that makes parallelizing trivial whether that be the compiler or the programmer. Most functional code (after partial evaluation) is going to be reducible to one variable transforms f: a -> b (map) then if you hit one that isn't you merge two lists (or self merge the list) g: a -> b -> c (reduce)
That's super clean and because of the associative criteria I can keep communication between processes very low. And that gets rid of the vast bulk of my code. That leaves the small fraction that is I/O, stateful... code. Now there what Microsoft is doing makes some sense. But isolating off 90+% of code immediately strikes me as far better.
In terms of bottlenecks in theory there shouldn't be any. Once you hit a bottleneck that means your algorithm was wrong. Functional makes it easy to change algorithms and encourages that sort of approach.
Still, since functional languages merely shift the road blocks instead of really removing them...and push towards having genius level voodoo programmers in every application for optimizing at that level...I'd still rather MS Research and others actually further their compiler designs.:)
I love what Microsoft's compiler group does. But I don't think it is about genius voodoo. Excel proves that rather poor programmers can handle functional. Javascript's popularity proves that people can do interfaces that way. Etc...
D is explicitly cross paradigm. This paper is about using using code that was designed for non-functional paradigms and tracking changes. D allows the author to use the appropriate paradigm in the appropriate spot. I see D as being more like scala in that you'll end up with stuff that moves in the direction but doesn't quite get there.
For example take this code block:
foreach(words; signs2words)
words = words.chomp().toLower();
if(words.length > 1)
writefln(words.join(" "));
In a functional language hat you would do is all the calculation and have the output be a lazy stream. Then pass the stream to write. So the compiler has it easy: construction of stream = safe to make parallel display of stream = needs to be single threaded
conversely the above D code the write (stateful operation) is interspersed with the stateless one. That's what you want to avoid.
Oh I agree it is a mindset. It is just a heck of a lot easier to do it in a language that makes it easy rather than in a language that makes it hard. It is also easier to acquire the mindset.
Slashdot Mirror
. But they've probable contributed more to a free and open internet than anyone since Mozilla thrashed IE.
I agree with you on Google. Just to ad $.02. After AOL stopped funding Mozilla, Google was who took over. The reason that Mozilla had the money to grow from 10% marketshare to 30% was Google, so they get at least 1/2 credit for that one too.
The big change in the web was 1993 when AOL users came on Usenet. Imagine for a moment what the internet would be like if everyone had to use real name accounts tied to workplace email, but all the employers were more or less cool and not paranoid. There was little security and machines tied together with RSH, rlogin... and where the machines didn't tie together you could freely use low security protocols like FTP, Telnet and RSH. There was no spam. No unethical, "man in the middles".
This article is about minor shifts in data aggregation. The big shifts IMHO were:
a) anonymity
b) commerce
c) the move from text based to image based (i.e. HTTP replacing Gopher and for information)
d) the death of Usenet and it being replaced with web based forums
I have no idea if the social media sites creating add on services but making the data harder for APIs is a good or a bad thing. What I can say though is in the scope of things it is not that huge a change.
IMHO IPv6 and going back to a world where every machine is directly accessible by every machine. That potentially could really create connection like we had 20 years ago.
A calculate doesn't have the same form factor as a laptop / desktop. You are going to want to take advantage of that additional space.
A good deal of what you are asking for spreadsheets do. When you need more than that, throw me in as another vote for Sage to create something like a MathCad type environment. Also I agree bc is a good choice for quick and dirty manipulations.
There is nothing to fund here. iOS can operate without the provisioning file model. That's how cydia works. Any iPhone owner who wants to can enable loading software without provisioning files.
As for security: Android, Linux (in general), Windows and OS X aren't remotely as secure as iOS. iOS is more on par with something like OpenBSD, EnGarde Secure Linux or NSS Windows 7. Customers seem to be extremely enthusiastic about the enhanced security. They seem to love being on a system that is immune to viruses unless the end user deliberately disables security features.
Now you mention something about funding. To the best of my knowledge there are no permissions based systems that are as secure as capability systems. So yeah Apple has insane amounts of cash, but you are talking theoretical computer science here. We have no idea what it would cost to deliver iOS security without the provisioning system.
Third, users should ultimately be the ones choosing between security vs. functionality... not the vendor. The device is owned by the user, not the vendor.
Apple agrees with you. What they don't want to create is a situation where users are pressured into reduced security by developers. Users who are knowledgeable enough to make those choices can do whatever they want. If you know enough to make those choices then you know enough to create your own provisioning files for your device. They know how to bypass the security mechanisms and push stuff through from the command line on their mac. And similarly for the naive who have friends with developer licenses their friends can create a provisioning file.
If they have a friends / business that's willing to fully support them they can register with a different set of servers using the Enterprise SDK. Apple doesn't make it impossible or even very difficult.
The problem that most people have is that Apple customers really like Apple's strict management and aren't willing to opt out of the security features. But that is the users making a choice.
Agreed everything in the chain needs to be trusted. But under Microsoft's design you had untrusted subsystems that wouldn't be part of the trusted chain. There were multiple chains.
OSes work this way. Most users are untrusted and have low permissions, other users are trusted and have more permissions. The thing making the determination about who has access to what needs to be trusted. Browsers have the same idea.
Trusted computing just applies these ideas all the way from hardware interfaces to memory reading and sharing to DRM files to application libraries.
The FSF is a terrible source on these issues. They tend to conflate:
a) What vendor X is specifically proposing with what other vendors are doing.
b) What is proposed from what the technology enables
c) The purpose as defined by the vendor and a worst case scenario.
I like the FSF but on this issue their propaganda has gone well beyond just being mildly overstated.
In particular in Microsoft's / Longhorn / Palladium case, there was also going to be an untrusted part of the system that could run any code. That untrusted part was where most programs were going to live and it would have access to do anything to untrusted parts of the system including most hardware, provided a trusted application was not also running. If a trusted application were running it would have virtualized hardware. That's just not what Apple does.
Apple allow interpreters providing the interpreters are marketed to people who understand what they are getting. See Gambit Scheme, Lua interpreters, or ND1 (RPL language), Codea (children's language). They are also working on Ruby Cocoa to allow interpreted code.
But it would definitely support more indie development which is one of the greatest things money just can't buy.
The iOS store has been a huge success for indie and small development. For small developers reduced marketing costs, customer processing, reviews.... are easily worth 30%. It is bigger developers that see that cost as punitively high.
As for opening the platform up. The problem is one of security. The security model on iOS requires the generation of provisioning files. Which means Apple ultimately has to support the distribution on an individual software -> device level. If you don't want to use provisioning files and just load whatever you want, that's just jailbreaking and that has been widely available throughout the iPhones life.
No there weren't in terms of meaningful marketshare. Microsoft's share has been well over 85% for almost two decades and as high as 95% during some of that time. iOS doesn't come close.
How is Apple killing OEMs that sell PCs other than Apple won the high profit high end? It certainly wasn't Apple that advised the PC OEMs to engage in a race to the bottom cost war, cutting their margins and their R&D budgets further and further. That was something they did to themselves, and something Microsoft did encourage at the time. This year's midrange PCs are very innovative and show what the OEMs should have been doing all along.
As far as developer freedom and Apple most of the people who complain most bitterly about Apple's policies on /. aren't Apple developers. They are quite often wrong on the facts, and misleading. You can't "take on" a product you don't use. The discussion among Apple developers are on issues like upgrade pricing and customer communication. The restrictions that bother the Android people are generally seen in their context by Apple developers.
Microsoft / Office is an exception to the iOS business because of its marketshare and dominance. This article is just about money not freedom.
Palladium allowed for data security. It wasn't about restricting applications at all it was about allowing PCs to have trusted computing. That's not something Apple to this day really offers, though they've put in place a lot of it.
As an aside, Palladium had encryption technology implemented in hardware with multiple keys that were one way storable. This is quite a bit more advanced than Apple's fused device UID/GID AES key. So no, not Palladium to the letter.
Oh I see. Yes a lack of an offer is very bad. Point taken and I agree.
My point was there is no problem in requiring purchase first.
MySQL makes their money now via. Oracle contracting. When they were an independent company they made their money selling commercial licenses for MySQL. There were no proprietary extension they sold.
It seems to me that this is the fundamental problem with GPL, and some other, open source licenses; it all depends on the honor system. Sure, they are technically legally binding, but if nobody holds anybody's feet to the fire, that means nothing.
Your problem is with the whole notion of civil law, where people enforce their own contract rights. The GPL is a license which exists within the body of copyright law. It automatically inherits problems from copyright which automatically inherits any problems from civil law.
I've already replied but someone should mod this up, the author clearly showing he is using a standard mechanism to comply.
Now you have the right to demand source under the GPL. It becomes a violation if the author refuses.
He's right it is spyware. And that's fine. But what he needs to be is very very careful in making sure to be as fair as possible in his factual descriptions including all the minor differences so there aren't factual disputes that he is misrepresenting the situation.
I've been a big fan of the FSF since around 90/91 when Peter Norton's speech introduced me to them. RMS has done tremendous things for free software. But overly aggressive and unbalanced criticism doesn't help the causes he is advocating. If the person being critiqued believes that charges are (1) simply wrong on the facts and then (2) exaggerated in the effects they just ignore the criticism. One or the other can be effective, both just comes off as unhinged.
I hate to say this, but this is becoming pattern for RMS.
Why would you want to run Cydia? Cydia is a cool stuff for iOS that Android has and often many times over. The advantage would be to run the hundreds of thousands of Apple app store apps on Android.
T-Mobile abroad and T-Mobile in the USA have little in common other than a brand name. They used to be more related but they have forked.
That's a great phone and an amazing price. But the Nexus 4 isn't quite comparable to the top of the line phones: iPhone 5, HTC 8X, Lumia 920, Siii,
This chart is a few months out of date but you can see the difference in specs between the phones listed and the Nexus 4: http://www.cultofmac.com/189929/the-iphone-5-how-it-stacks-up-against-the-competition-chart/
. Yet, if that were the case, functional programs along with functional compilers would already be producing programs substantially faster on vectorizing CPUs
I would argue they are. The entire high speed graphics libraries that are used by GPUs are a good example of this. Graphics are way faster today because of the functional code that is executed on GPUs. Another example of this massive parallelism is Google's use of map / reduce which starting in the late 1990s allowed them to do a decomposition of the entire internet regularly.
Of course, I know the above isn't that simple and it helps little that poor programmers who can functional languages may well code so badly to miss out on most the compiler benefits.
No I actually think even poor programers can benefit from this. The problem is that functional compilers are much less sophisticated than structured / object oriented ones. Compiler theory and CPU theory over the last 3 decades has been about making C code run fast, and then a lot about virtual CPUs with bytecode. Functional compilers in some senses are a generation ahead in terms of innovations but in terms of raw performance about a generation behind. GCC used to be like this, very innovative but about much slower than good compilers. Linus' team worked hard for about 6 years to get GCC's performance up and by the early 2000s they had. Someone is going to have to do something similar, a GHC that's much less feature rich but much faster.
Certainly, I'm not holding my breathe for a [near] purely functional language based OS. :)
I am. I think huge number of CPUs being standard and diverse semi-independent chips to boot will make this more and more necessary. You see this already in hardware languages, the shift towards functional has been profound. Right now that functional code is shielding the end users from the complexity of modern hardware but I'd assume that eventually people will want OSes that take better advantage of what the hardware could potentially do. Apple's focus on performance is a real change in an industry which had moved away from performance towards inexpensive, they are raising the bar.
I suspect that many of the dynamic languages will move in a functional direction and to get performance will have their systems written more functionally. Perl 6 being a good example of the change that's happened in just a few decades, where a lot of ideas from GHC and Haskell have bled over. If Perl6 hadn't stagnated it would be out years ago and would have like Scala and Clojure have moved the industry more in a functional direction.
So, instead, I think we're left to further designs of compilers to tackle that mythical 10-% of code which, I think, may well account for much closer to 99% of code on many systems. :/
You and I don't disagree that if you don't use functional it is 99%. My point is that once the programmer needs to give the system that much isolation and hints he might as well write functional. But obviously if the system could work on out of the box C# that's huge. Microsoft's research is very cutting edge and if they get this to work they have the kinds of advantages that it will be hard for anyone to compete with for a decade or more.
rogrammers already do it all the time in object oriented programming though encapsulation and method-based access
I agree that's why it is possible to have objects reside on clients and go parallel in that way. But that often isn't a very good division of labor and communication between threads can be too expensive. Just having a couple thousand threads around even if most are blocked might be good enough to get some boost and certainly at least they are able to make use of additional CPUs but I don't see that as similar to being able to cleanly divide a large workload with low communication needs like in functional.
As far as the weakness for functional. What I see is the big advantage is that encourages you to write the bulk of your code in a way that makes parallelizing trivial whether that be the compiler or the programmer. Most functional code (after partial evaluation) is going to be reducible to one variable transforms
f: a -> b (map) then if you hit one that isn't you merge two lists (or self merge the list)
g: a -> b -> c (reduce)
That's super clean and because of the associative criteria I can keep communication between processes very low. And that gets rid of the vast bulk of my code. That leaves the small fraction that is I/O, stateful... code. Now there what Microsoft is doing makes some sense. But isolating off 90+% of code immediately strikes me as far better.
In terms of bottlenecks in theory there shouldn't be any. Once you hit a bottleneck that means your algorithm was wrong. Functional makes it easy to change algorithms and encourages that sort of approach.
Still, since functional languages merely shift the road blocks instead of really removing them...and push towards having genius level voodoo programmers in every application for optimizing at that level...I'd still rather MS Research and others actually further their compiler designs. :)
I love what Microsoft's compiler group does. But I don't think it is about genius voodoo. Excel proves that rather poor programmers can handle functional. Javascript's popularity proves that people can do interfaces that way. Etc...
D is explicitly cross paradigm. This paper is about using using code that was designed for non-functional paradigms and tracking changes. D allows the author to use the appropriate paradigm in the appropriate spot. I see D as being more like scala in that you'll end up with stuff that moves in the direction but doesn't quite get there.
For example take this code block:
foreach(words; signs2words)
words = words.chomp().toLower();
if(words.length > 1)
writefln(words.join(" "));
In a functional language hat you would do is all the calculation and have the output be a lazy stream. Then pass the stream to write. So the compiler has it easy:
construction of stream = safe to make parallel
display of stream = needs to be single threaded
conversely the above D code the write (stateful operation) is interspersed with the stateless one. That's what you want to avoid.
Oh I agree it is a mindset. It is just a heck of a lot easier to do it in a language that makes it easy rather than in a language that makes it hard. It is also easier to acquire the mindset.