It isn't just physicists trying to 'impose' the decimal prefixes on poor defenceless computer users. What about Ethernet - 10, 100 or 1000 megabits per second? Or your 56 kilobit/s modem? Then of course hard disks have been measured in decimal megabytes and gigabytes for a long time now.
BTW - the other thing the kernel patch should have fixed is to write 'byte' instead of 'B', since B often stands for bel as in decibel (and 'b' stands for bit). Sometimes in information theory you might be talking about bels and bits in the same sentence, so there is some scope for confusion. Alternatively, make it implicit that all memory sizes are in terms of the machine's addressing capability, and just say '40505 free' instead of '40505 bytes free'.
If you're worried about download time, just get the patches!
(Okay that only works if you've got the previous version - you can download a whole sequence of patches for bigger jumps, but after a while it gets bigger than the kernel itself. I'd like to see a general patch generator where you type in what version you currently have and it generates the smallest patch file just for you. Alternatively some way of using rsync would save on bandwidth.)
I was thinking about payment being made from one ISP to another (or from user to ISP) at the connection between their two networks. For example you would pay a small per-megabyte charge when web browsing with your cable modem; your ISP would pass on most or all of that charge as payment for the other ISP it contacts to fetch the page. Spoofing your IP address to evade payment isn't really possible because you're billed by your own ISP based on what physically goes over your modem link.
As for 'administration fees' and that sort of thing, I just hope that competition among ISPs will help to keep down this sort of abuse, just like competition between banks. I wouldn't mind paying a fairly calculated fee for the bandwidth I actually used, but I'd ditch my ISP quickly if they started inventing random new charges.
'Digital divide': no I don't think so. An analogue modem uses such a piddly amount of bandwidth that the charges wouldn't be worth bothering with, or at any rate dwarfed by the phone bill you pay anyhow. I'm not thinking of charging for content, just for the resources you actually use. You could make the same 'X divide' argument about metered electricity usage, or phone bills, or anything else where you pay according to consumption. It doesn't make the principle wrong.
Cost: you'd pay just your own ISP, at a fixed rate (say one cent per megabyte). You can imagine a scheme where the ISP charges more for worldwide traffic than for connections to nearby hosts, but I don't think it would get that complicated in practice. Customers could just move to the ISP offering the best rates.
Abuse: I was thinking of small charges, just enough to pay the costs of bandwidth. In fact it would be sufficient to make the charges less than the actual cost of bandwidth - if they covered 80% of the cost then a small site could serve five times as many users before running out of money, and that might be good enough. It wouldn't be profitable to put up 'huge bloated sites' - not that many would visit them anyway.
You are right that in some cases charging for bandwidth will inhibit usage of the net (demo versions of software or whatever). That is more psychological than economic, since the amounts are so small, but important nonetheless. I feel this way as a user myself - it's just _nicer_ to know that you are paying a flat fee. Perhaps the answer is to have a bandwidth-payment system but stop it at the final link, so ISPs pay in proportion to what their users consume, but average out the costs between all users (rather like how it is now).
The one advantage you do cite, an incentive for sites to write tighter HTML, is not actually true. If instead of paying $x for your outgoing bandwith you are paying effectively $x / 5 or even zero, there is _less_ incentive to create smaller pages. OTOH there is a (tiny) incentive for users to visit less bloated sites.
Re:Is it the price of bandwidth?
on
Adcritic Shuts Down
·
· Score: 4, Interesting
The bandwidth payment model is kinda broken. Mobile phones really took off once it became established that you pay for _making_ calls and not so much for receiving them (though a flat line-rental charge is acceptable). It shouldn't cost a site more if it's popular; rather, the users requesting pages should pay for the bandwith they consume. (This is a tiny amount of money, and it's not the same as micropayments - you really are paying for usage of a scarce resource, and it's between you and your ISP.)
The trouble is that for marketing reasons ISPs want to offer nominally flat-rate services (even though in reality they'll kick you off for going above some arbitrary limit) but hosting companies charge for actual usage. And there is AFAIK no payment structure to decide who is 'responsible' for a connection - just packet counting. Billing the side which initiates a TCP connection would be a reasonable first approximation.
Another way out would be for small or hobbyist sites to run throttling webservers and stop serving pages temporarily when some quota of bandwidth runs out. However, the pages would remain accessible through web caches. This would lead to a demand from users that ISPs run a decent http cache, again pushing some of the responsibility for the surfing habits of 'random hordes' onto the ISP rather than the (un)lucky website.
At my university each candidate is issued a standard calculator at the start of each exam, and they're collected up afterwards. You're not allowed to bring your own calculator into the exam room any more than your own answer booklet to write on. (Your own pens are okay since nobody's found a magical cheat-helping pen.)
Calculators are so cheap nowadays that you don't have much excuse not to do this. Although your solution of requiring only 'scientific' (I assume this means, not graphical) calculators is also a good answer.
Unfortunately, people aren't going to stop building features into calculators just because teachers would prefer it that way. It's the schools' responsibility to decide what type of calculators are and are not acceptable in class or in tests.
Maybe the African species wouldn't be well adapted to Australia. A lion might accidentally take one bite of (insert highly poisonous small thing that lives in Australia) and drop dead.
I think a three-way death match with lions, crocodiles and humans would make good television. This guy is a media magnate, right?
A DEB package references the other packages it requires, not the libraries or binaries contained in the package, thereby alleviating the problem of depending on different library versioning conventions.
RPM has this.
It also allows for pre- and post-dependencies, which help apt handle the often complex task of updating between major versions of Debian, by making sure that packages are updated in the proper order.
I believe RPM will handle this too, but I'd have to check the documentation.
Try upgrading from Redhat 5.x to 7.2 sometime, and see how much work you have to put into it.
This is almost entirely because RedHat didn't spend time on building their packages carefully to make this upgrade smooth. Whereas Debian developers are very careful about such things. Get hundreds of fanatical Debian developers building an RPM-based distro, and a commercially-focused Linux distributor using dpkg, and you'd see the same situation.
There were troubles with upgrading to Debian unstable packages on Corel Linux - and Corel Linux is much more closely related to Debian than SuSE is to RedHat. If I wanted to make the mistake of equating differences between distributions and flaws in the package tool, I would say 'this means that dpkg sucks and gives you dependency hell. Use RedHat or BSD ports instead'.
The difficulties with installing (say) SuSE packages on Mandrake are due to differences in the packaging conventions of those two distributions. And the ease of upgrading packages on Debian is because _all_ the packages come from a single source and follow a strict set of conventions. It has very little to do with the merits of dpkg versus rpm.
The RPM format at best only provides the name and major version of any dynamic libraries a package requires.
Have you ever actually used RPM? It allows you to specify prerequisites with their versions in more or less the same way as dpkg. Certainly a lot more than just the version of shared libraries.
It's true that a lot of RPM builders do not bother to include this information. But that's not the fault of the format itself. A lot of the claimed advantages of.deb over.rpm are really just because the Debian people are more conscientous about packaging and anal (in a good way) about getting the dependencies correct. Ditching RPM is not the answer, better packaging quality is.
Trouble is that as the Cygwin FAQ points out, Cygwin is not secure in a multi-user environment. So if someone is sitting at the machine locally they could exploit the Cygwin DLL to take over your ssh session.
The insecurity of Cygwin doesn't stop it being a very useful tool for single user Windows boxes, but it is kinda silly to use it to compile what's meant to be a security-enhancing program like ssh.
Okay, so how long until cable Internet providers kludge up a protocol to send audio data over MAGIC, use a software V.90 modem implementation treating the audio packets like an analogue phone line, and run PPP on top of that?
A port to MCA, plus a separate port to PowerPC and RS/6000, doesn't necessarily mean a port to MCA RS/6000. This is the situation for Linux. It runs on MCA Intel boxes, and PCI RS/6000s, but not MCA RS/6000s.
(As you might guess, newer RS/6ks are not MCA, so a port isn't _that_ important.)
The ESDI disks work fine under Linux, if slowly. I used to have two of them in my Model 80 (before going SCSI). Pick your kernel version carefully though: some of the MCA support has rotted in newer versions. 2.2.14 works like a charm.
Usually the difficulty is not so much the kernel drivers as getting your distribution to realize that ESDI disks exist. To install Slackware I had to make some fake device nodes/dev/hda* to make the ESDI disks appear as IDE ones to the installer. Then I was able to install Slackware and finally make the correct device nodes (/dev/eda*) and fix up/etc/fstab and/etc/lilo.conf by hand.
Sorry to hijack this NetBSD thread with writing about Linux, but it's probably more an MCA discussion than a NetBSD discussion. The Linux support for MCA is a lot more mature than any of the BSDs: many of the OSes will boot and run but Linux supports a wider range of devices commonly found on MCA boxes. OTOH that makes NetBSD a more challenging project to undertake:-)
In Britain some museums (eg the Natural History Museum) are counted as academic institutions so they appear in.ac.uk along with the universities. Strangely, the next-door Science Museum seems not to appreciate this and is redirecting from its old nmsi.ac.uk domain to something much less classy.
Darn, that Slashdot goatse indicator is spoiling the surprise of clicking on the links to find out what the domains actually are:-(.
Cold air masses across the border from Canada... I would have expected _warm_ air masses. But then, my only knowledge of these things is from watching South Park.
Re:Same as it ever was...
on
Homepage Usability
·
· Score: 4, Insightful
Yes, Nielsen can sound like a broken record. But the only reason he's saying the same things over and over again is because they *still need saying*.
Even after five years of widespread web use, there are still many who just don't get it, who think that the way to pull users to a site is to hide the useful information and clog it with graphics and effects that were passe in 1997. (Possibly these sites are a little reduced in number after the dotcom crash, but not gone altogether. And there's always the worry that existing sites will forget their purpose and go downhill (eg Altavista).)
So I say that Nielsen should keep on plugging away with the same message. You may have heard it all before but not everyone has.
I got in trouble for donating 500 licences of MS Office 98, and MS windows that had been bundled with our machines
when we changed to all open source. Apparently the IRS does not consider donation of microsoft software as a
charitable contributuion of any value.
Interesting... I thought Microsoft managed to 'donate' thousands of CDs costing $0.50 each to manufacture and write it off against tax at the full retail price of that software. If the IRS counts it as tax-deductible when Microsoft does it, why is the ruling any different when another party makes the same donation?
But the argument you make doesn't stop metered billing being used for electricity, or (in many places) water. Once people get used to it they will settle down and there will probably be fewer timewasting disputes. It's just that nobody wants to be the first to introduce it.
(Personally I don't mind paying according to usage, as long as it really is the scarce resource being metered and not something else. So I'd be happy to pay a fixed charge per bit, but not artificial charges per IP address.)
It would be nice to download the engine as free software from Sourceforge, together with a minimal set of graphics and levels. Then pay real money for the full game data (sprites, sound effects, levels and so on). This is more or less what happens with Doom, I think.
Slashdot Mirror
It isn't just physicists trying to 'impose' the decimal prefixes on poor defenceless computer users. What about Ethernet - 10, 100 or 1000 megabits per second? Or your 56 kilobit/s modem? Then of course hard disks have been measured in decimal megabytes and gigabytes for a long time now.
BTW - the other thing the kernel patch should have fixed is to write 'byte' instead of 'B', since B often stands for bel as in decibel (and 'b' stands for bit). Sometimes in information theory you might be talking about bels and bits in the same sentence, so there is some scope for confusion. Alternatively, make it implicit that all memory sizes are in terms of the machine's addressing capability, and just say '40505 free' instead of '40505 bytes free'.
If you're worried about download time, just get the patches!
(Okay that only works if you've got the previous version - you can download a whole sequence of patches for bigger jumps, but after a while it gets bigger than the kernel itself. I'd like to see a general patch generator where you type in what version you currently have and it generates the smallest patch file just for you. Alternatively some way of using rsync would save on bandwidth.)
I was thinking about payment being made from one ISP to another (or from user to ISP) at the connection between their two networks. For example you would pay a small per-megabyte charge when web browsing with your cable modem; your ISP would pass on most or all of that charge as payment for the other ISP it contacts to fetch the page. Spoofing your IP address to evade payment isn't really possible because you're billed by your own ISP based on what physically goes over your modem link.
As for 'administration fees' and that sort of thing, I just hope that competition among ISPs will help to keep down this sort of abuse, just like competition between banks. I wouldn't mind paying a fairly calculated fee for the bandwidth I actually used, but I'd ditch my ISP quickly if they started inventing random new charges.
'Digital divide': no I don't think so. An analogue modem uses such a piddly amount of bandwidth that the charges wouldn't be worth bothering with, or at any rate dwarfed by the phone bill you pay anyhow. I'm not thinking of charging for content, just for the resources you actually use. You could make the same 'X divide' argument about metered electricity usage, or phone bills, or anything else where you pay according to consumption. It doesn't make the principle wrong.
Cost: you'd pay just your own ISP, at a fixed rate (say one cent per megabyte). You can imagine a scheme where the ISP charges more for worldwide traffic than for connections to nearby hosts, but I don't think it would get that complicated in practice. Customers could just move to the ISP offering the best rates.
Abuse: I was thinking of small charges, just enough to pay the costs of bandwidth. In fact it would be sufficient to make the charges less than the actual cost of bandwidth - if they covered 80% of the cost then a small site could serve five times as many users before running out of money, and that might be good enough. It wouldn't be profitable to put up 'huge bloated sites' - not that many would visit them anyway.
You are right that in some cases charging for bandwidth will inhibit usage of the net (demo versions of software or whatever). That is more psychological than economic, since the amounts are so small, but important nonetheless. I feel this way as a user myself - it's just _nicer_ to know that you are paying a flat fee. Perhaps the answer is to have a bandwidth-payment system but stop it at the final link, so ISPs pay in proportion to what their users consume, but average out the costs between all users (rather like how it is now).
The one advantage you do cite, an incentive for sites to write tighter HTML, is not actually true. If instead of paying $x for your outgoing bandwith you are paying effectively $x / 5 or even zero, there is _less_ incentive to create smaller pages. OTOH there is a (tiny) incentive for users to visit less bloated sites.
The bandwidth payment model is kinda broken. Mobile phones really took off once it became established that you pay for _making_ calls and not so much for receiving them (though a flat line-rental charge is acceptable). It shouldn't cost a site more if it's popular; rather, the users requesting pages should pay for the bandwith they consume. (This is a tiny amount of money, and it's not the same as micropayments - you really are paying for usage of a scarce resource, and it's between you and your ISP.)
The trouble is that for marketing reasons ISPs want to offer nominally flat-rate services (even though in reality they'll kick you off for going above some arbitrary limit) but hosting companies charge for actual usage. And there is AFAIK no payment structure to decide who is 'responsible' for a connection - just packet counting. Billing the side which initiates a TCP connection would be a reasonable first approximation.
Another way out would be for small or hobbyist sites to run throttling webservers and stop serving pages temporarily when some quota of bandwidth runs out. However, the pages would remain accessible through web caches. This would lead to a demand from users that ISPs run a decent http cache, again pushing some of the responsibility for the surfing habits of 'random hordes' onto the ISP rather than the (un)lucky website.
At my university each candidate is issued a standard calculator at the start of each exam, and they're collected up afterwards. You're not allowed to bring your own calculator into the exam room any more than your own answer booklet to write on. (Your own pens are okay since nobody's found a magical cheat-helping pen.)
Calculators are so cheap nowadays that you don't have much excuse not to do this. Although your solution of requiring only 'scientific' (I assume this means, not graphical) calculators is also a good answer.
Unfortunately, people aren't going to stop building features into calculators just because teachers would prefer it that way. It's the schools' responsibility to decide what type of calculators are and are not acceptable in class or in tests.
How much of this is applicable to GNUstep or NeXTStep? Any of it?
I was thinking of some primitive weapon like a spear or knife. Or maybe one of those giant cotton buds they have on Gladiators.
Are accents written on capital letters? I got the impression they usually weren't.
Maybe the African species wouldn't be well adapted to Australia. A lion might accidentally take one bite of (insert highly poisonous small thing that lives in Australia) and drop dead.
I think a three-way death match with lions, crocodiles and humans would make good television. This guy is a media magnate, right?
RPM has this.
I believe RPM will handle this too, but I'd have to check the documentation.
This is almost entirely because RedHat didn't spend time on building their packages carefully to make this upgrade smooth. Whereas Debian developers are very careful about such things. Get hundreds of fanatical Debian developers building an RPM-based distro, and a commercially-focused Linux distributor using dpkg, and you'd see the same situation.
There were troubles with upgrading to Debian unstable packages on Corel Linux - and Corel Linux is much more closely related to Debian than SuSE is to RedHat. If I wanted to make the mistake of equating differences between distributions and flaws in the package tool, I would say 'this means that dpkg sucks and gives you dependency hell. Use RedHat or BSD ports instead'.
The difficulties with installing (say) SuSE packages on Mandrake are due to differences in the packaging conventions of those two distributions. And the ease of upgrading packages on Debian is because _all_ the packages come from a single source and follow a strict set of conventions. It has very little to do with the merits of dpkg versus rpm.
Have you ever actually used RPM? It allows you to specify prerequisites with their versions in more or less the same way as dpkg. Certainly a lot more than just the version of shared libraries.
It's true that a lot of RPM builders do not bother to include this information. But that's not the fault of the format itself. A lot of the claimed advantages of .deb over .rpm are really just because the Debian people are more conscientous about packaging and anal (in a good way) about getting the dependencies correct. Ditching RPM is not the answer, better packaging quality is.
The server is dead! Long live the server!
Trouble is that as the Cygwin FAQ points out, Cygwin is not secure in a multi-user environment. So if someone is sitting at the machine locally they could exploit the Cygwin DLL to take over your ssh session.
The insecurity of Cygwin doesn't stop it being a very useful tool for single user Windows boxes, but it is kinda silly to use it to compile what's meant to be a security-enhancing program like ssh.
Okay, so how long until cable Internet providers kludge up a protocol to send audio data over MAGIC, use a software V.90 modem implementation treating the audio packets like an analogue phone line, and run PPP on top of that?
A port to MCA, plus a separate port to PowerPC and RS/6000, doesn't necessarily mean a port to MCA RS/6000. This is the situation for Linux. It runs on MCA Intel boxes, and PCI RS/6000s, but not MCA RS/6000s.
(As you might guess, newer RS/6ks are not MCA, so a port isn't _that_ important.)
The ESDI disks work fine under Linux, if slowly. I used to have two of them in my Model 80 (before going SCSI). Pick your kernel version carefully though: some of the MCA support has rotted in newer versions. 2.2.14 works like a charm.
/dev/hda* to make the ESDI disks appear as IDE ones to the installer. Then I was able to install Slackware and finally make the correct device nodes (/dev/eda*) and fix up /etc/fstab and /etc/lilo.conf by hand.
:-)
Usually the difficulty is not so much the kernel drivers as getting your distribution to realize that ESDI disks exist. To install Slackware I had to make some fake device nodes
Sorry to hijack this NetBSD thread with writing about Linux, but it's probably more an MCA discussion than a NetBSD discussion. The Linux support for MCA is a lot more mature than any of the BSDs: many of the OSes will boot and run but Linux supports a wider range of devices commonly found on MCA boxes. OTOH that makes NetBSD a more challenging project to undertake
If you don't like small-mammal digestive noises then you are clearly not a Unix user :-).
In Britain some museums (eg the Natural History Museum) are counted as academic institutions so they appear in .ac.uk along with the universities. Strangely, the next-door Science Museum seems not to appreciate this and is redirecting from its old nmsi.ac.uk domain to something much less classy.
Darn, that Slashdot goatse indicator is spoiling the surprise of clicking on the links to find out what the domains actually are :-(.
Cold air masses across the border from Canada... I would have expected _warm_ air masses. But then, my only knowledge of these things is from watching South Park.
Yes, Nielsen can sound like a broken record. But the only reason he's saying the same things over and over again is because they *still need saying*.
Even after five years of widespread web use, there are still many who just don't get it, who think that the way to pull users to a site is to hide the useful information and clog it with graphics and effects that were passe in 1997. (Possibly these sites are a little reduced in number after the dotcom crash, but not gone altogether. And there's always the worry that existing sites will forget their purpose and go downhill (eg Altavista).)
So I say that Nielsen should keep on plugging away with the same message. You may have heard it all before but not everyone has.
Interesting... I thought Microsoft managed to 'donate' thousands of CDs costing $0.50 each to manufacture and write it off against tax at the full retail price of that software. If the IRS counts it as tax-deductible when Microsoft does it, why is the ruling any different when another party makes the same donation?
But the argument you make doesn't stop metered billing being used for electricity, or (in many places) water. Once people get used to it they will settle down and there will probably be fewer timewasting disputes. It's just that nobody wants to be the first to introduce it.
(Personally I don't mind paying according to usage, as long as it really is the scarce resource being metered and not something else. So I'd be happy to pay a fixed charge per bit, but not artificial charges per IP address.)
It would be nice to download the engine as free software from Sourceforge, together with a minimal set of graphics and levels. Then pay real money for the full game data (sprites, sound effects, levels and so on). This is more or less what happens with Doom, I think.