640KB was a lot of memory. The first IBM PCs had 16-256KB of RAM and were competing against 8-bit computers with 1-64KB. These were the machines that CP/M ran on. UNIX, needing 16KB for just the kernel, was massive in comparison - it was only small in comparison to minicomputer / mainframe operating systems. CP/M ran on machines with 16KB of RAM, with most of that available to the program. The operating system itself could run from ROM. DOS 1.0 was a cheap CP/M clone, running on IBM PCs with 16KB of RAM. It was easy to port CP/M programs to DOS, so it started with a lot of applications (including VisiCalc, the first killer app).
The later PCs, with 640KB of RAM were able to run MINIX or Xenix, but they were also able to run Windows 3.0, so there was a choice between Windows 3.0 on top of DOS, which let you run GUI applications and all of your legacy DOS applications, or UNIX without any legacy compatibility and without most of the advantages of a real operating system since the hardware didn't support protected memory.
The 286 had protected memory, but via a segmentation system. The 386 was the first x86 chip to be powerful enough for a real operating system with protected memory and preemptive multitasking, but by the time it was introduced there was so much legacy DOS code floating around that any operating system that couldn't run DOS applications was dead in the water.
By this time, UNIX was mired down in the AT&T vs UCB lawsuit and also competing with OS/2 and Windows NT, both of which had protected memory, preemptive multitasking, and the ability to run both DOS and Windows 3.0 programs.
Capacity can't remain constant if you want everyone to use their bandwidth all of the time, that's the point. If usage patterns change then you need to either improve the infrastructure or degrade the service that you offer. The point of usage-based billing is to slow down the change and to get the people who really need the extra capacity (and are therefore willing to pay extra) to fund the infrastructure development.
No, this isn't new, it's an argument that's been used since the USAPATRIOT Act passed. Well, maybe they're saying 'cloud' instead of 'costing' or 'colocation'. The other good argument is 'the USA has no data protection laws so if you do business in the EU and host your data in the USA then you're opening yourself up to potential liability'.
Windows? Windows didn't even exist back then. The competitor on the low end was CP/M. A few years later MS introduced their CP/M clone, DOS. Windows came about a decade later. No one used UNIX on personal computers because it was only lightweight by mainframe / minicomputer standards. Most personal computer didn't have protected memory and multitasking was a completely pointless operating system feature on a system that barely had enough RAM for one program.
Window got ahead because DOS was already entrenched and it provided backwards compatibility. Early versions of Windows ran on DOS, so in the worst case you could always quit Windows and run the DOS program outside, but most business apps ran happily inside the Windows DOS box. Most people installed Windows 3.0 and earlier as a way to run multiple DOS programs at once.
Are you using some strange definition of fixed costs? Fixed costs by definition do not change.
The costs are fixed, up to a certain threshold. It costs a fix amount to provide a service in a certain range. There is then an increase and it costs a larger fixed amount to provide a service within that. To give you an analogy: imagine you run a cell tower that uses some magic protocol and provides any amount of bandwidth to anyone within range. The cost of providing service to everyone within range of the tower is fixed. If you want to provide service to people outside this area then you need to build and operate another tower. This is also a fixed cost, but it's larger than your initial fixed cost.
The same is true with real networks. It costs a certain fixed amount to provide a certain amount of access. If you have a 100Mb/s link, it costs the same amount to provide a 10Mb/s guaranteed service to 1 customer as it does to provide the same service to 10 customers. This is a fixed cost: it does not depend on the number of customers. If you provide a contended service to 100 customers, then the cost is the same, as long as their usage patterns are such that no more than 10 of them are ever trying to saturate their links at once (or more than 20 of them trying to use 50%, and so on). If the usage patterns change, then the conditions change. Now you are providing a different service to the one that you designed the network for. You need a capital investment to improve the network to the level where it can handle this. At that point, the costs are also fixed, but at a higher level.
Eventually, but usually indirectly. For example, you write some Java code for compositing an image or drawing a line on Android - most of the time that's executing it will be in the Skia library, not in the Java code.
Users = customers in this case, it's free retard, are you referring to me when you say?
No, customers are the people who pay. Users who don't pay are not customers. Their existence or nonexistence is totally irrelevant to a project. In the case of FireFox, they may indirectly be customers of the project as a whole, if they don't change their search page from the default Google one, since Google pays a tiny amount per visitor. They are not customers of this developer, because they are not paying him anything even indirectly. Other contributors are, because they are paying him in contributions to the codebase.
I don't say this often, but your views are f'in stupid, and nobody would hire you or let you work on any open source project with such views
And yet a significant fraction of my income comes from being paid to work on open source projects and I have commit access to two relatively large ones (LLVM and FreeBSD) and a few smaller ones. When I work on them, the people who pay me are my customers, and I care about their views. The people who are also working to improve my code are paying me with their contributions, so I care about their views (and, to a slightly lesser extent, about the views of the people who are paying them). I even care about people who are taking these projects and using them with other projects that I want to use.
But I don't care about anyone who is just taking the code and giving nothing back - why should I? They're welcome to use them, but if they're not giving anything back then their opinions are not really important. If they're going to file detailed bug reports, that's a contribution that I value (the bugs may not affect me now, but any bug is likely to affect me eventually and fixing it before it does is great). If they're just armchair quarterbacking then the only response they can expect is 'patches welcome'. You need a massive entitlement mentality to believe that just because you downloaded something for free that you are entitled to direct how it evolves in the future.
As I said, this attitude isn't unique to Free Software. If you phone up Adobe and say 'I downloaded Photoshop and it should have these features' do you think they'll care? Now if you phone them up and say 'my company bought 1,000 copies and we hit this bug, will you fix it?' you're much more likely to get a positive response.
Explain to me how the burstiness of internet traffic has anything to do with the fixed costs of running a network?
I did in the post you replied to. The cost is constant as long as your users are not simultaneously trying to use enough to hit the amount that you've allocated. If your users are all using the capacity in short bursts then you can fit more users in the same pipe than if they are all using it at the same time. If you can fit fewer users in the same capacity, then this increases the fixed costs. Why is this hard for you to understand?
I actually had a chat on slashdot with a developer of ff. The guy was so disillusioned towards why would people ever have expectations of an open source project and he can do wtf he wants cause he's not getting paid to do it. Well he's right, but what will he do when nobody is using firefox anymore?
If he's not getting paid for it, then why would he care if it has any users? As long as it does what he wants, he's fine. Software developers never care about users, even proprietary ones. They care about customers, who are a subset of users. Free software projects care about contributors (whether they're contributing money, designs, code, art, or even bug reports). People who just use the project but don't contribute anything are totally irrelevant.
The fixed costs are the same no matter how much bandwith we use
That's partly true, but not really. It would be true in a circuit-switched network, like ISDN, where you had 64Kb/s reserved for you and you alone, but even then it was only true for the last mile unless you had a leased line. Most Internet users are very bursty. When sending or receiving email they may spike, when they watch a video it may jump up to using 10-50% of their bandwidth for a bit, but most of the time it's idle and most of the rest of the time it's not using 100% of its capacity. That means that if you have a 100Mb/s link you can sell 100 people 10Mb/s links and most of the time they'll actually see 10Mb/s when they try it. If 10 of those people try using 10Mb/s all of the time, then the ISP needs to provide 200Mb/s of backbone capacity.
If they weren't overselling then it wouldn't be a problem, but then your Internet connection would cost ten times as much because then they'd need 10Mb/s of backbone for every 10Mb/s customer, and most of the time that link would be sitting idle. It's true that if these 100 hypothetical customers aren't using an average of 1Mb/s each all of the time then there is wasted capacity, but if 11 of them try to saturate their links simultaneously then there is going to be a problem.
Thumb-2 is very dense. All of the ARM instructions that common compilers generate are there. There are several other things about ARM that make it better for low-power systems:
16 registers and no register-limited instructions mean that you have far fewer register-register moves than in x86 (the x86 register-memory instructions offset this somewhat). This is one of the big improvements that x86-64 brings to the table.
Predicated instructions mean that you can avoid a lot of short branches. This is great on a pipelined superscalar chip - you execute all instructions and just don't retire the results on the ones that shouldn't have been executed. This means that ARM chips need a less complex branch predictor to get similar performance to x86. Less complexity means lower power. ARM didn't even bother with branch prediction until a few years ago.
A single instruction format. Both ARM and Thumb2 have very simple layouts. Decoding an ARM or Thumb instruction is really easy. The Thumb-2 decoder is about as complex as the micro-op decoder in an x86 chip.
ARM and thumb instructions are fixed length. This means that you never get an instruction spanning multiple cache lines. On x86, you'll often see compilers insert no-ops to ensure that you won't see this problem.
There are also some very dense instructions. The load / store multiple instructions, for example, let you push and pop an arbitrary subset of the registers. Saving all of the caller-save (or all of the callee-save) registers is a single ARM instruction. This means that you can have very small function prologs and epilogs in ARM code. In fact, you can implement setjmp() and longjmp() with a single ARM instruction too.
Load and store instructions that make address computation easy and support addressing relative to any register. This makes library code (which needs to be position independent) a lot denser on ARM than x86. On x86 you need to call and then pop to get the current instruction pointer, and then you can use this value (in another register, costing you one of your four approximately general-purpose registers) as a base for address computation. With ARM, you just do a ip-relative load (and ARM loads let you do things like r1 + r2 << 4 in a single instruction, so you can store an array start in r1, an index in r2, and access array elements in a single instruction).
In terms of compression, I implemented the same function recently for ARM, x86-64 and x86. The sizes of the text section from the assembled versions were:
ARM: 360 bytes
x86-32: 471 bytes
x86-64: 651 bytes
The 64-bit version is slightly more complicated, but only very slightly (the extra complexity is about 4 instructions, the rest is the same).
For compiling, which is integer and branch heavy, my Cortex A8 seems to be about as fast per clock as my Core 2 Duo. It takes about 6 times as long to compile (doing make -j2 on the C2D, just make on the ARM), but is about 1/3 the clock speed and only has one core. For anything that uses double-precision floating point the ARM core is very weak, although most of those things can be run on the DSP or GPU (and use even less power).
They use Java, but not for anything performance critical. The rendering GUI are all C/C++ and they use an LLVM-based DSL compiler for things like animations. Most of the time the Java code is either sleeping waiting for user action or calling into non-Java code.
When one of these delusional "open source hardware" projects finally turns a profit
Is turning a profit their goal now? I thought it was to produce a community-developed open source phone that placed the owners in complete control of their device. Maybe I missed the announcement.
and matters, then we'll talk.
Matters to whom? To its contributors and users? I think it matters to them already. To everyone in the world? I don't think any phone does that.
I used to, but then I realised that there are very few films I want to watch more than a couple of times. I'd much rather watch something new. For me, buying a DVD is not much different from renting it twice, so unless it's cheaper than a single rental I won't bother.
So? I don't pirate, but I rent TV shows on DVD. It costs less than a cable subscription to have 3 DVDs at home at once and since I don't receive broadcast TV I don't need a TV license, so it works out at about the same total cost.
I don't have a TV, so my view of what's on the BBC comes from iPlayer and may not be representative, but recently I've enjoyed (off the top of my head) The Fades (Buffy for grownups), the new series of Merlin, the last season of Spooks, QI, Have I Got News for You, Doctor Who, and Garrow's Law. QI had a few significant errors in the last show, but was still funny. HIGNFY doesn't seem to have suffered, but maybe I'm not not sufficiently jaded.
Why do you need to replace them? I don't know where you live, but in the UK a Freeview set top box only costs about £20 (my step father got a couple for £10 in the massive discounts a year or two ago). Just plug it into the old TVs and they'll work.
Slashdot Mirror
That was why they made them in the first place - using Dell's in Apple's datacentres was bad for PR. Now it's not so relevant.
The later PCs, with 640KB of RAM were able to run MINIX or Xenix, but they were also able to run Windows 3.0, so there was a choice between Windows 3.0 on top of DOS, which let you run GUI applications and all of your legacy DOS applications, or UNIX without any legacy compatibility and without most of the advantages of a real operating system since the hardware didn't support protected memory.
The 286 had protected memory, but via a segmentation system. The 386 was the first x86 chip to be powerful enough for a real operating system with protected memory and preemptive multitasking, but by the time it was introduced there was so much legacy DOS code floating around that any operating system that couldn't run DOS applications was dead in the water.
By this time, UNIX was mired down in the AT&T vs UCB lawsuit and also competing with OS/2 and Windows NT, both of which had protected memory, preemptive multitasking, and the ability to run both DOS and Windows 3.0 programs.
Capacity can't remain constant if you want everyone to use their bandwidth all of the time, that's the point. If usage patterns change then you need to either improve the infrastructure or degrade the service that you offer. The point of usage-based billing is to slow down the change and to get the people who really need the extra capacity (and are therefore willing to pay extra) to fund the infrastructure development.
Who said anything about Java? The exploits in question are in C code using the NDK.
No, this isn't new, it's an argument that's been used since the USAPATRIOT Act passed. Well, maybe they're saying 'cloud' instead of 'costing' or 'colocation'. The other good argument is 'the USA has no data protection laws so if you do business in the EU and host your data in the USA then you're opening yourself up to potential liability'.
The static analyser in clang is free and would catch several of the things that people who R'd TFA say were mentioned.
Windows? Windows didn't even exist back then. The competitor on the low end was CP/M. A few years later MS introduced their CP/M clone, DOS. Windows came about a decade later. No one used UNIX on personal computers because it was only lightweight by mainframe / minicomputer standards. Most personal computer didn't have protected memory and multitasking was a completely pointless operating system feature on a system that barely had enough RAM for one program.
Window got ahead because DOS was already entrenched and it provided backwards compatibility. Early versions of Windows ran on DOS, so in the worst case you could always quit Windows and run the DOS program outside, but most business apps ran happily inside the Windows DOS box. Most people installed Windows 3.0 and earlier as a way to run multiple DOS programs at once.
Are you using some strange definition of fixed costs? Fixed costs by definition do not change.
The costs are fixed, up to a certain threshold. It costs a fix amount to provide a service in a certain range. There is then an increase and it costs a larger fixed amount to provide a service within that. To give you an analogy: imagine you run a cell tower that uses some magic protocol and provides any amount of bandwidth to anyone within range. The cost of providing service to everyone within range of the tower is fixed. If you want to provide service to people outside this area then you need to build and operate another tower. This is also a fixed cost, but it's larger than your initial fixed cost.
The same is true with real networks. It costs a certain fixed amount to provide a certain amount of access. If you have a 100Mb/s link, it costs the same amount to provide a 10Mb/s guaranteed service to 1 customer as it does to provide the same service to 10 customers. This is a fixed cost: it does not depend on the number of customers. If you provide a contended service to 100 customers, then the cost is the same, as long as their usage patterns are such that no more than 10 of them are ever trying to saturate their links at once (or more than 20 of them trying to use 50%, and so on). If the usage patterns change, then the conditions change. Now you are providing a different service to the one that you designed the network for. You need a capital investment to improve the network to the level where it can handle this. At that point, the costs are also fixed, but at a higher level.
Eventually, but usually indirectly. For example, you write some Java code for compositing an image or drawing a line on Android - most of the time that's executing it will be in the Skia library, not in the Java code.
Users = customers in this case, it's free retard, are you referring to me when you say?
No, customers are the people who pay. Users who don't pay are not customers. Their existence or nonexistence is totally irrelevant to a project. In the case of FireFox, they may indirectly be customers of the project as a whole, if they don't change their search page from the default Google one, since Google pays a tiny amount per visitor. They are not customers of this developer, because they are not paying him anything even indirectly. Other contributors are, because they are paying him in contributions to the codebase.
I don't say this often, but your views are f'in stupid, and nobody would hire you or let you work on any open source project with such views
And yet a significant fraction of my income comes from being paid to work on open source projects and I have commit access to two relatively large ones (LLVM and FreeBSD) and a few smaller ones. When I work on them, the people who pay me are my customers, and I care about their views. The people who are also working to improve my code are paying me with their contributions, so I care about their views (and, to a slightly lesser extent, about the views of the people who are paying them). I even care about people who are taking these projects and using them with other projects that I want to use.
But I don't care about anyone who is just taking the code and giving nothing back - why should I? They're welcome to use them, but if they're not giving anything back then their opinions are not really important. If they're going to file detailed bug reports, that's a contribution that I value (the bugs may not affect me now, but any bug is likely to affect me eventually and fixing it before it does is great). If they're just armchair quarterbacking then the only response they can expect is 'patches welcome'. You need a massive entitlement mentality to believe that just because you downloaded something for free that you are entitled to direct how it evolves in the future.
As I said, this attitude isn't unique to Free Software. If you phone up Adobe and say 'I downloaded Photoshop and it should have these features' do you think they'll care? Now if you phone them up and say 'my company bought 1,000 copies and we hit this bug, will you fix it?' you're much more likely to get a positive response.
Explain to me how the burstiness of internet traffic has anything to do with the fixed costs of running a network?
I did in the post you replied to. The cost is constant as long as your users are not simultaneously trying to use enough to hit the amount that you've allocated. If your users are all using the capacity in short bursts then you can fit more users in the same pipe than if they are all using it at the same time. If you can fit fewer users in the same capacity, then this increases the fixed costs. Why is this hard for you to understand?
I actually had a chat on slashdot with a developer of ff. The guy was so disillusioned towards why would people ever have expectations of an open source project and he can do wtf he wants cause he's not getting paid to do it. Well he's right, but what will he do when nobody is using firefox anymore?
If he's not getting paid for it, then why would he care if it has any users? As long as it does what he wants, he's fine. Software developers never care about users, even proprietary ones. They care about customers, who are a subset of users. Free software projects care about contributors (whether they're contributing money, designs, code, art, or even bug reports). People who just use the project but don't contribute anything are totally irrelevant.
The smallpox vaccine was tested by intentionally exposing people to smallpox. The medical profession tends to frown on that kind of thing these days.
The fixed costs are the same no matter how much bandwith we use
That's partly true, but not really. It would be true in a circuit-switched network, like ISDN, where you had 64Kb/s reserved for you and you alone, but even then it was only true for the last mile unless you had a leased line. Most Internet users are very bursty. When sending or receiving email they may spike, when they watch a video it may jump up to using 10-50% of their bandwidth for a bit, but most of the time it's idle and most of the rest of the time it's not using 100% of its capacity. That means that if you have a 100Mb/s link you can sell 100 people 10Mb/s links and most of the time they'll actually see 10Mb/s when they try it. If 10 of those people try using 10Mb/s all of the time, then the ISP needs to provide 200Mb/s of backbone capacity.
If they weren't overselling then it wouldn't be a problem, but then your Internet connection would cost ten times as much because then they'd need 10Mb/s of backbone for every 10Mb/s customer, and most of the time that link would be sitting idle. It's true that if these 100 hypothetical customers aren't using an average of 1Mb/s each all of the time then there is wasted capacity, but if 11 of them try to saturate their links simultaneously then there is going to be a problem.
4K is 2160p. It is 4096×2160. They decided to use the horizontal number instead of the vertical this time because it is bigger.
No company is required (by law) to pay more than minimum wage yet, oddly enough, many do.
Actually, Google doesn't include CarrierIQ code in the OS they ship
Of course they don't. They don't want any competition when it comes to spying on their users...
16 registers and no register-limited instructions mean that you have far fewer register-register moves than in x86 (the x86 register-memory instructions offset this somewhat). This is one of the big improvements that x86-64 brings to the table.
Predicated instructions mean that you can avoid a lot of short branches. This is great on a pipelined superscalar chip - you execute all instructions and just don't retire the results on the ones that shouldn't have been executed. This means that ARM chips need a less complex branch predictor to get similar performance to x86. Less complexity means lower power. ARM didn't even bother with branch prediction until a few years ago.
A single instruction format. Both ARM and Thumb2 have very simple layouts. Decoding an ARM or Thumb instruction is really easy. The Thumb-2 decoder is about as complex as the micro-op decoder in an x86 chip.
ARM and thumb instructions are fixed length. This means that you never get an instruction spanning multiple cache lines. On x86, you'll often see compilers insert no-ops to ensure that you won't see this problem.
There are also some very dense instructions. The load / store multiple instructions, for example, let you push and pop an arbitrary subset of the registers. Saving all of the caller-save (or all of the callee-save) registers is a single ARM instruction. This means that you can have very small function prologs and epilogs in ARM code. In fact, you can implement setjmp() and longjmp() with a single ARM instruction too.
Load and store instructions that make address computation easy and support addressing relative to any register. This makes library code (which needs to be position independent) a lot denser on ARM than x86. On x86 you need to call and then pop to get the current instruction pointer, and then you can use this value (in another register, costing you one of your four approximately general-purpose registers) as a base for address computation. With ARM, you just do a ip-relative load (and ARM loads let you do things like r1 + r2 << 4 in a single instruction, so you can store an array start in r1, an index in r2, and access array elements in a single instruction).
In terms of compression, I implemented the same function recently for ARM, x86-64 and x86. The sizes of the text section from the assembled versions were:
The 64-bit version is slightly more complicated, but only very slightly (the extra complexity is about 4 instructions, the rest is the same).
For compiling, which is integer and branch heavy, my Cortex A8 seems to be about as fast per clock as my Core 2 Duo. It takes about 6 times as long to compile (doing make -j2 on the C2D, just make on the ARM), but is about 1/3 the clock speed and only has one core. For anything that uses double-precision floating point the ARM core is very weak, although most of those things can be run on the DSP or GPU (and use even less power).
They use Java, but not for anything performance critical. The rendering GUI are all C/C++ and they use an LLVM-based DSL compiler for things like animations. Most of the time the Java code is either sleeping waiting for user action or calling into non-Java code.
When one of these delusional "open source hardware" projects finally turns a profit
Is turning a profit their goal now? I thought it was to produce a community-developed open source phone that placed the owners in complete control of their device. Maybe I missed the announcement.
and matters, then we'll talk.
Matters to whom? To its contributors and users? I think it matters to them already. To everyone in the world? I don't think any phone does that.
I like to own movies I buy
I used to, but then I realised that there are very few films I want to watch more than a couple of times. I'd much rather watch something new. For me, buying a DVD is not much different from renting it twice, so unless it's cheaper than a single rental I won't bother.
So? I don't pirate, but I rent TV shows on DVD. It costs less than a cable subscription to have 3 DVDs at home at once and since I don't receive broadcast TV I don't need a TV license, so it works out at about the same total cost.
I don't have a TV, so my view of what's on the BBC comes from iPlayer and may not be representative, but recently I've enjoyed (off the top of my head) The Fades (Buffy for grownups), the new series of Merlin, the last season of Spooks, QI, Have I Got News for You, Doctor Who, and Garrow's Law. QI had a few significant errors in the last show, but was still funny. HIGNFY doesn't seem to have suffered, but maybe I'm not not sufficiently jaded.
Why do you need to replace them? I don't know where you live, but in the UK a Freeview set top box only costs about £20 (my step father got a couple for £10 in the massive discounts a year or two ago). Just plug it into the old TVs and they'll work.