They only have themselves to blame for this. You can buy an iPhone from Apple and use it on any GSM network, so 'not having the iPhone' really doesn't mean anything for GSM carriers, except that they've managed to persuade the US public that you can only buy a phone from your carrier.
Of course, what they really mean is that they are not making as much profit from the 'subsidy' as they are used to. When a carrier sells you a phone, they are giving you a loan at around a 10-40% APR for the phone and raking in a huge amount of money from this. In a lot of cases, they actually make more money from the loan than from the contract. In the case of Apple, they're only making something like 15-20% of the cost of the phone as profit.
Keep in mind that 10 years ago mobile data usage was tiny. Ignoring termination costs (i.e. the cost of calling other networks), providing voice + SMS to everyone with a mobile phone is pretty cheap. Voice on GSM only goes up to 13Kb/s, which is a pretty tiny slice of the 3+Mb/s that HSPA can provide. When people start streaming videos to their phones, however, the usage goes a long way up...
I don't really follow ReactOS development actively, but one thing that they've done is improve the OS personality layer so that it's possible for userspace programs to use libraries that depend on different personalities, unlike Windows where you have to pick between Win32 and POSIX.
Even better, if mobile phone carriers stopped selling phones altogether. Most of the smaller ones in the UK have stopped already. Just buy a phone, buy a SIM, combine the two yourself.
Of course, if you look at SIM-only plans, you see how much you're actually paying for the 'free' phone. My carrier, for example, offers a £12 SIM-only plan and an identical £30 smartphone plan. The SIM-only deal is a 1-month contract, the smartphone plan is a 12-month contract. So, if you use it for the minimum period, you've paid £216 more than if you were on the SIM-only plan. The smartphone plan comes with a few choices of phone. The first one I looked at, the HTC Desire S, costs £154 (new) unlocked, on Amazon. Probably less if you shop around.
So, the 'subsidised' 'free' phone actually works out as a loan with an APR of about 40%. If you buy it now on your credit card and pay the bill at the end of the year, you'll still be better off...
And the design goal of Linux was to provide a POSIX-compliant kernel for running UNIX programs. There was nothing about adding improvements there either. So, ummm, what's your point?
Hi Ray. You may be right, but when you back up your assertion with a link that says 'please log in to view this page' then I am forced to disagree citing this source.
ReactOS is not just duplicating the design. It is also extending it. It is, however, aiming to keep the same ABI. This is hardly an original goal - it is one shared by several modern UNIX and UNIX-like systems. If you think ReactOS is just copying the Windows NT design and not adding improvements, then you've obviously not paid any attention to it in the last ten years.
In Objective-C blocks, locals that are bound are referenced indirectly via a pointer. This is pretty cheap in the on-stack case - the variable and the pointer will be in the same cache line - and when the block is copied (which happens automatically in ARC mode when you assign a pointer to it to the heap or a global) so the general solution works quite nicely. It is still possible to construct cyclic dependencies if the a bound variable references the block, but it's nontrivial.
I don't think 'you don't pay for what you don't use' is really the C++ mantra. Having worked on C++ compiler and library implementation, I would say that the real mantra is 'no feature may go into the language if it decreases microbenchmark results, even if it will make large projects faster'.
I don't understand what you mean here. Are you saying the service would buy a copy, and then stream it to only one person at a time?
If resale of electronic items is permitted under the first sale doctrine, then it is 100% legal for a service to buy one film from, say, iTunes or Amazon, sell it for one token in their own currency, stream it, and then buy it back in exchange for one token in their electronic currency. A service like Netflix, instead of paying hundreds of thousands of dollars for streaming rights could just buy a few hundred copies - sell them and buy them back, completely transparently to the user.
Reading the rest of your post, it's unclear whether you suffer from an inability to read or an inability to think, but it's clear that you have failed to comprehend either my original post or my reply, so I'm not sure why I expect you to understand if I explain a third time.
ReactOS is duplicating Windows NT, which is a design originally from 1993, although they're actually aiming for compatibility with the 2001 version. Linux and *BSD are duplicating UNIX, which is a design originally from 1969. Interesting? Maybe not. Useful? Probably.
It's also used in quite a few embedded systems running low-end x86 chips. The advantage of something like DOS in this respect is that it's almost like not having an OS, but it still gives you a basic filesystem and program launcher, then gets out of your way.
This is true, but you also have to consider the time / PITA it would take to do this
What PITA? The point is, if this were allowed, then a service could be set up to do this. To its users, it would appear like a streaming / rental service, but instead of paying the studios a higher price for a streaming license it would just pay them the $10 per copy and stream it to as many people as wanted it (but only one at a time).
So once you've bought all your media and resold it (for slightly less of course) each month
Huh? Why for slightly less? We're talking about digital copies. There is no detectable difference between the original and the version that 4,000 people have watched already. You'd buy one copy, sell it, buy it back, sell it, buy it back. You wouldn't have to use real money, you could use tokens that you issue, so 'selling' and 'buying' just mean incrementing and decrementing a value in a database.
It's stored in the same way as a normal hard disk - in ferromagnetic domains on a platter. You can still read it back using the same techniques as current drives (i.e. put a coil over it and see which way the induced current flows), but you then have a drive that you can write to orders of magnitude than you can read from it. I can think of a few places where this might be useful. The most obvious is the underlying storage for something like ZFS. For reliability, you want to flush everything to the backing store as quickly as possible, and with copy-on-write and snapshotting you may never erase it, but most of your reads are satisfied from flash or DRAM caches. A drive using this technology would let you dump data there as quickly as you wanted and would let you read it back for data recovery if you needed to, while in normal operation you wouldn't care about the read speed because reading from the disk is comparatively rare. It would also be useful for a number of scientific applications. I did some work a few years ago with someone building a solar observatory. A single one of their cameras generated 10GB/s of data, and they had 8 cameras in a typical setup. They run these for the entire time that the sun is visible. A single drive that can handle a sustained write speed of 1GB/s would be very useful for them (although they'd fill up several per hour...).
For consumer devices, random read speed is still the most important factor, and mechanical drives suck at that.
Actually, it's a spurious argument, because you're not buying the copy, you're buying a license to possess a copy, as the copyright industry keeps telling us. You are not transferring the copy when you resell, you are transferring the right to the copy.
The real problem that sale itself becomes largely impossible if you permit resale of electronic copies due to the speed of transfer. Consider any piece of music, any film, or any book that you've bought a copy of. How often do you actually use them? I doubt that there is any piece of media that you own that you listen to even 1% of your time. So why not sell them when you're not listening to them, and buy them back when you want to? You can't really do this with physical goods because the effort of shipping them and the wear makes it impossible. It's quite possible, however, for 1,000 people to watch the same digital copy of a film. If you have 100 copies of a film that you sell to people who want to watch them and buy back immediately afterwards, then it's entirely possible that you'll have enough for an entire country.
A film at iPlayer HD quality would take me 36 minutes to download on my current Internet connection, and 18 minutes at the speed of the connection that my ISP is upgrading me to (their new lowest-speed tier) this year. Even if you require the transfer of the data, then this just adds 18 minutes to the duration of the film for my period of ownership (I can start watching it before it's finished transferring it, but I can't start returning it until I no longer want to own it). So a typical film can be sold and returned every 2 hours. In the course of a year, a single copy can be sold and returned over 4,000 times (there is probably someone in one time zone that wants to watch it at any given time).
A lot of the things I watch are at least 10 years old (not because I object to new stuff, just that there is - obviously - ten times as much stuff that I want to watch produced in the last ten years than in the last one year, and I haven't got around to watching some of it yet). If a studio could sell one copy and have it watched 40,000 times, then how would it stay in business? The upper bound on the number of copies of a film that they could sell would probably be about 10,000 - and that's for a real blockbuster.
Of course, the sensible conclusion to reach here is that 'selling' is now the wrong model for these goods. A better idea would be providing a service that gave convenient access to all new productions and a mechanism for funding the creation of new ones...
but after many years developing with dynamic languages, I will tell you that mismatched-typing issues are a tiny minority of bugs I've seen make it to production.
I couldn't agree with you more here
Once upon a time, type theorists said 'use strong typing and the compiler can generate better code because it has more known invariants!' Then the StrongTalk team showed that a decent compiler could infer better type information via type feedback than the user specified with explicit annotations. So the type theorists said 'use strong typing, because you'll have fewer bugs!' Then someone pointed them to the proof (which is actually well within the realms of undergraduate mathematics) that you can't prove any nontrivial property of a program using type theory. Then the type theorists started to become quiet and only the type theory fanboys kept talking about strong typing as if it were a good thing.
Now of course, we have Category Theory, which will definitely deliver all of the things that Type Theory promised to deliver. Honest!
If closures and lambda expressions were so easy to implement using basic inheritance, Java would already have it
Closures and objects are trivially provable to be equivalent - you can represent both in the same lambda calculus terms (and Simula and Smalltalk both implemented one in terms of the other - a Simula class is a closure that returns itself, a Smalltalk closure is an object). The problem is not the semantics or expressiveness in the theoretical sense, it's the syntax. The thing that makes closures useful in languages that have them is that they are less verbose to create than classes. You can create a Java class called Closure with an invoke() method, create a subclass of it for each call site, instantiate it, set all of the things you want to be bound variables as instance variables, and then pass it to something that will call the invoke() method (or some variant with different semantics). But no one wants to write code like that, because it's spectacularly ugly and verbose.
Languages like Clojure target the JVM and do exactly this kind of trick. They allow you to have closures in a language that uses the same underlying object model as Java. A big part of the reason that Java lacks them is that it was designed as a language for average programmers, and so intentionally omitted programming features that the designers considered were complex to use.
a slightly saner object model for people coming from C++ or Java
Java has a Smalltalk-derived object model and C++ has a Simula-derived object model that have only one thing in common: that they both use classes (although they use very different definitions of what a class is). I shudder to imagine what kind of ugliness you get when trying to make something that is intended for people coming from either...
I'll prefix this by saying that Javascript is not my favourite language, although I have written a compiler for a dialect of it and an Objective-C compiler that emits JavaScript.
A lot of what you're talking about has nothing to do with the language and everything to do with the libraries. Given a DOM binding and a function for generating asynchronous HTTP requests, everything that you request is pretty trivial in most high(ish)-level languages and would almost certainly perform better. Writing a fast implementation of JavaScript is insanely hard. One of the big reasons why it is easier to make Java perform faster than Smalltalk - in spite of the fact that the two have a lot in common in terms of memory and object models - is that Java has integer types, so a + b can be compiled to a single add instruction by a naive compiler, while doing the same thing in Smalltalk requires you to perform some nontrivial type inference. In JavaScript, it's even worse because integers must transparently overflow to double-precision floating point values.
It would almost certainly be more maintainable too. JavaScript was intended for scripting, not for writing large applications. It lacks any module feature - or even classes. You can split a JavaScript program into multiple files, but then including them in a different order can significantly alter the semantics of the program. In other languages, you can separate independent parts into separate components and not, for example, pollute the global namespace with local concerns.
The lack of GC - or even some approximation - is what makes C++11 lambdas completely horrible. The language does nothing to ensure that your bound variables actually persist for the lifetime of the closure. You are required to use smart pointers for all of them. This is trivial stuff for the compiler to do (in Objective-C, for example, block variables - including C values and structures - are automatically moved to the heap when required by a block persisting) and a pain for the programmer to do. So, of course, C++ makes the programmer do it...
They do already. But if you're buying 3 drives then you're going to - proportionally - pay a lot more in handling charges. In terms of manpower, it costs about the same (actually, a bit less) to put a load of drives on a pallet and load them into a van as it does to get three drives off the production line and ship them to a single address. If you turn up at the factory, a lot of these places will happily sell you drives quite cheaply, but if you want them to ship them to you then you have to cover their costs. This cost is a lot easier to absorb when it's split over 1,000 drives than when it's split over 3.
I bought three 2TB drives about a week before the flood. They cost £49.15 + VAT. The same model today, from the same supplier, costs £81.20 + VAT. About a month after the flood, it cost about £130, so the prices are slowly returning to their pre-flood levels...
Slashdot Mirror
They only have themselves to blame for this. You can buy an iPhone from Apple and use it on any GSM network, so 'not having the iPhone' really doesn't mean anything for GSM carriers, except that they've managed to persuade the US public that you can only buy a phone from your carrier.
Of course, what they really mean is that they are not making as much profit from the 'subsidy' as they are used to. When a carrier sells you a phone, they are giving you a loan at around a 10-40% APR for the phone and raking in a huge amount of money from this. In a lot of cases, they actually make more money from the loan than from the contract. In the case of Apple, they're only making something like 15-20% of the cost of the phone as profit.
Keep in mind that 10 years ago mobile data usage was tiny. Ignoring termination costs (i.e. the cost of calling other networks), providing voice + SMS to everyone with a mobile phone is pretty cheap. Voice on GSM only goes up to 13Kb/s, which is a pretty tiny slice of the 3+Mb/s that HSPA can provide. When people start streaming videos to their phones, however, the usage goes a long way up...
I don't really follow ReactOS development actively, but one thing that they've done is improve the OS personality layer so that it's possible for userspace programs to use libraries that depend on different personalities, unlike Windows where you have to pick between Win32 and POSIX.
Even better, if mobile phone carriers stopped selling phones altogether. Most of the smaller ones in the UK have stopped already. Just buy a phone, buy a SIM, combine the two yourself.
Of course, if you look at SIM-only plans, you see how much you're actually paying for the 'free' phone. My carrier, for example, offers a £12 SIM-only plan and an identical £30 smartphone plan. The SIM-only deal is a 1-month contract, the smartphone plan is a 12-month contract. So, if you use it for the minimum period, you've paid £216 more than if you were on the SIM-only plan. The smartphone plan comes with a few choices of phone. The first one I looked at, the HTC Desire S, costs £154 (new) unlocked, on Amazon. Probably less if you shop around.
So, the 'subsidised' 'free' phone actually works out as a loan with an APR of about 40%. If you buy it now on your credit card and pay the bill at the end of the year, you'll still be better off...
And the design goal of Linux was to provide a POSIX-compliant kernel for running UNIX programs. There was nothing about adding improvements there either. So, ummm, what's your point?
Hi Ray. You may be right, but when you back up your assertion with a link that says 'please log in to view this page' then I am forced to disagree citing this source.
ReactOS is not just duplicating the design. It is also extending it. It is, however, aiming to keep the same ABI. This is hardly an original goal - it is one shared by several modern UNIX and UNIX-like systems. If you think ReactOS is just copying the Windows NT design and not adding improvements, then you've obviously not paid any attention to it in the last ten years.
In Objective-C blocks, locals that are bound are referenced indirectly via a pointer. This is pretty cheap in the on-stack case - the variable and the pointer will be in the same cache line - and when the block is copied (which happens automatically in ARC mode when you assign a pointer to it to the heap or a global) so the general solution works quite nicely. It is still possible to construct cyclic dependencies if the a bound variable references the block, but it's nontrivial.
I don't think 'you don't pay for what you don't use' is really the C++ mantra. Having worked on C++ compiler and library implementation, I would say that the real mantra is 'no feature may go into the language if it decreases microbenchmark results, even if it will make large projects faster'.
I don't understand what you mean here. Are you saying the service would buy a copy, and then stream it to only one person at a time?
If resale of electronic items is permitted under the first sale doctrine, then it is 100% legal for a service to buy one film from, say, iTunes or Amazon, sell it for one token in their own currency, stream it, and then buy it back in exchange for one token in their electronic currency. A service like Netflix, instead of paying hundreds of thousands of dollars for streaming rights could just buy a few hundred copies - sell them and buy them back, completely transparently to the user.
Reading the rest of your post, it's unclear whether you suffer from an inability to read or an inability to think, but it's clear that you have failed to comprehend either my original post or my reply, so I'm not sure why I expect you to understand if I explain a third time.
ReactOS is duplicating Windows NT, which is a design originally from 1993, although they're actually aiming for compatibility with the 2001 version. Linux and *BSD are duplicating UNIX, which is a design originally from 1969. Interesting? Maybe not. Useful? Probably.
It's also used in quite a few embedded systems running low-end x86 chips. The advantage of something like DOS in this respect is that it's almost like not having an OS, but it still gives you a basic filesystem and program launcher, then gets out of your way.
This is true, but you also have to consider the time / PITA it would take to do this
What PITA? The point is, if this were allowed, then a service could be set up to do this. To its users, it would appear like a streaming / rental service, but instead of paying the studios a higher price for a streaming license it would just pay them the $10 per copy and stream it to as many people as wanted it (but only one at a time).
So once you've bought all your media and resold it (for slightly less of course) each month
Huh? Why for slightly less? We're talking about digital copies. There is no detectable difference between the original and the version that 4,000 people have watched already. You'd buy one copy, sell it, buy it back, sell it, buy it back. You wouldn't have to use real money, you could use tokens that you issue, so 'selling' and 'buying' just mean incrementing and decrementing a value in a database.
One friend is nearly 400 pounds and looks like the dough boy and thinks he will get a hot chick.
He could be right. After all, 'hot' and 'totally insecure and craving any kind of attention' are not exactly disjoint sets...
Hot, sane, and interesting, however, could be a lot more of a challenge.
I only get +5 insightful when I'm trolling.
It's stored in the same way as a normal hard disk - in ferromagnetic domains on a platter. You can still read it back using the same techniques as current drives (i.e. put a coil over it and see which way the induced current flows), but you then have a drive that you can write to orders of magnitude than you can read from it. I can think of a few places where this might be useful. The most obvious is the underlying storage for something like ZFS. For reliability, you want to flush everything to the backing store as quickly as possible, and with copy-on-write and snapshotting you may never erase it, but most of your reads are satisfied from flash or DRAM caches. A drive using this technology would let you dump data there as quickly as you wanted and would let you read it back for data recovery if you needed to, while in normal operation you wouldn't care about the read speed because reading from the disk is comparatively rare. It would also be useful for a number of scientific applications. I did some work a few years ago with someone building a solar observatory. A single one of their cameras generated 10GB/s of data, and they had 8 cameras in a typical setup. They run these for the entire time that the sun is visible. A single drive that can handle a sustained write speed of 1GB/s would be very useful for them (although they'd fill up several per hour...).
For consumer devices, random read speed is still the most important factor, and mechanical drives suck at that.
Actually, it's a spurious argument, because you're not buying the copy, you're buying a license to possess a copy, as the copyright industry keeps telling us. You are not transferring the copy when you resell, you are transferring the right to the copy.
The real problem that sale itself becomes largely impossible if you permit resale of electronic copies due to the speed of transfer. Consider any piece of music, any film, or any book that you've bought a copy of. How often do you actually use them? I doubt that there is any piece of media that you own that you listen to even 1% of your time. So why not sell them when you're not listening to them, and buy them back when you want to? You can't really do this with physical goods because the effort of shipping them and the wear makes it impossible. It's quite possible, however, for 1,000 people to watch the same digital copy of a film. If you have 100 copies of a film that you sell to people who want to watch them and buy back immediately afterwards, then it's entirely possible that you'll have enough for an entire country.
A film at iPlayer HD quality would take me 36 minutes to download on my current Internet connection, and 18 minutes at the speed of the connection that my ISP is upgrading me to (their new lowest-speed tier) this year. Even if you require the transfer of the data, then this just adds 18 minutes to the duration of the film for my period of ownership (I can start watching it before it's finished transferring it, but I can't start returning it until I no longer want to own it). So a typical film can be sold and returned every 2 hours. In the course of a year, a single copy can be sold and returned over 4,000 times (there is probably someone in one time zone that wants to watch it at any given time).
A lot of the things I watch are at least 10 years old (not because I object to new stuff, just that there is - obviously - ten times as much stuff that I want to watch produced in the last ten years than in the last one year, and I haven't got around to watching some of it yet). If a studio could sell one copy and have it watched 40,000 times, then how would it stay in business? The upper bound on the number of copies of a film that they could sell would probably be about 10,000 - and that's for a real blockbuster.
Of course, the sensible conclusion to reach here is that 'selling' is now the wrong model for these goods. A better idea would be providing a service that gave convenient access to all new productions and a mechanism for funding the creation of new ones...
To date I've met a lot of C++ programmers that have tried Javascript. I've only known one who was any good at it
To be fair, meeting a C++ programmer who is good at C++ is also pretty rare...
but after many years developing with dynamic languages, I will tell you that mismatched-typing issues are a tiny minority of bugs I've seen make it to production.
I couldn't agree with you more here
Once upon a time, type theorists said 'use strong typing and the compiler can generate better code because it has more known invariants!' Then the StrongTalk team showed that a decent compiler could infer better type information via type feedback than the user specified with explicit annotations. So the type theorists said 'use strong typing, because you'll have fewer bugs!' Then someone pointed them to the proof (which is actually well within the realms of undergraduate mathematics) that you can't prove any nontrivial property of a program using type theory. Then the type theorists started to become quiet and only the type theory fanboys kept talking about strong typing as if it were a good thing.
Now of course, we have Category Theory, which will definitely deliver all of the things that Type Theory promised to deliver. Honest!
If closures and lambda expressions were so easy to implement using basic inheritance, Java would already have it
Closures and objects are trivially provable to be equivalent - you can represent both in the same lambda calculus terms (and Simula and Smalltalk both implemented one in terms of the other - a Simula class is a closure that returns itself, a Smalltalk closure is an object). The problem is not the semantics or expressiveness in the theoretical sense, it's the syntax. The thing that makes closures useful in languages that have them is that they are less verbose to create than classes. You can create a Java class called Closure with an invoke() method, create a subclass of it for each call site, instantiate it, set all of the things you want to be bound variables as instance variables, and then pass it to something that will call the invoke() method (or some variant with different semantics). But no one wants to write code like that, because it's spectacularly ugly and verbose.
Languages like Clojure target the JVM and do exactly this kind of trick. They allow you to have closures in a language that uses the same underlying object model as Java. A big part of the reason that Java lacks them is that it was designed as a language for average programmers, and so intentionally omitted programming features that the designers considered were complex to use.
a slightly saner object model for people coming from C++ or Java
Java has a Smalltalk-derived object model and C++ has a Simula-derived object model that have only one thing in common: that they both use classes (although they use very different definitions of what a class is). I shudder to imagine what kind of ugliness you get when trying to make something that is intended for people coming from either...
I'll prefix this by saying that Javascript is not my favourite language, although I have written a compiler for a dialect of it and an Objective-C compiler that emits JavaScript.
A lot of what you're talking about has nothing to do with the language and everything to do with the libraries. Given a DOM binding and a function for generating asynchronous HTTP requests, everything that you request is pretty trivial in most high(ish)-level languages and would almost certainly perform better. Writing a fast implementation of JavaScript is insanely hard. One of the big reasons why it is easier to make Java perform faster than Smalltalk - in spite of the fact that the two have a lot in common in terms of memory and object models - is that Java has integer types, so a + b can be compiled to a single add instruction by a naive compiler, while doing the same thing in Smalltalk requires you to perform some nontrivial type inference. In JavaScript, it's even worse because integers must transparently overflow to double-precision floating point values.
It would almost certainly be more maintainable too. JavaScript was intended for scripting, not for writing large applications. It lacks any module feature - or even classes. You can split a JavaScript program into multiple files, but then including them in a different order can significantly alter the semantics of the program. In other languages, you can separate independent parts into separate components and not, for example, pollute the global namespace with local concerns.
The lack of GC - or even some approximation - is what makes C++11 lambdas completely horrible. The language does nothing to ensure that your bound variables actually persist for the lifetime of the closure. You are required to use smart pointers for all of them. This is trivial stuff for the compiler to do (in Objective-C, for example, block variables - including C values and structures - are automatically moved to the heap when required by a block persisting) and a pain for the programmer to do. So, of course, C++ makes the programmer do it...
They do already. But if you're buying 3 drives then you're going to - proportionally - pay a lot more in handling charges. In terms of manpower, it costs about the same (actually, a bit less) to put a load of drives on a pallet and load them into a van as it does to get three drives off the production line and ship them to a single address. If you turn up at the factory, a lot of these places will happily sell you drives quite cheaply, but if you want them to ship them to you then you have to cover their costs. This cost is a lot easier to absorb when it's split over 1,000 drives than when it's split over 3.
Yes, but what would happen if Godzilla laid waste to all of south-east Asia? See? No foresight at all!
I bought three 2TB drives about a week before the flood. They cost £49.15 + VAT. The same model today, from the same supplier, costs £81.20 + VAT. About a month after the flood, it cost about £130, so the prices are slowly returning to their pre-flood levels...