I was thinking about networking textbooks which say things like 'though a UDP packet could in theory get dropped en route, this hardly ever happens in practice'. I didn't take account of the fact that these books were talking mostly about LANs and other private networks rather than the big, bad Internet.
If UDP is reliable enough for NFS, it should be reliable enough for web pages, right? If the reply to your request doesn't arrive after a certain time you can just send the request again.
Good point about the response not fitting in a UDP packet: does NFS avoid this problem by always requesting small enough chunks of data to fit in a single packet?
Once you start having to do both rerequesting dropped packets and reordering those that arrive out of sequence it does start to look as though TCP is a better bet, since it does these things for you. Nonetheless, since dropped UDP packets are fairly uncommon in practice it might be quicker most of the time to save on the overhead of setting up a TCP connection and just send a single UDP packet instead.
If you get frequent-flyer miles from flights paid for by your company, don't those extra miles also belong to the company? If you use them for personal travel you should at least get explicit permission for this.
There was a company making a business model out of helping other firms work around the incentive structures of airlines (which were thought to corrupt employees, making them choose the flight with the best perks, rather than the cheapest). So firms would accumulate the extra miles for themselves. I can't remember the company's name now, however.
In the UK there is nothing in the Highway Code about flashing headlamps to warn of speed traps. I think it is illegal because of separate legislation (or maybe it is not illegal at all and I am misremembering). Equally there is nothing in the HC about drink-driving... the Code doesn't exclusively define the law on motoring.
Yes, it's a pity that HTTP doesn't use UDP to start with. Why design a stateless protocol and then put it on top of TCP, requiring a connection to be set up and torn down for each HTTP request?
(OK, newer HTTP versions can fetch multiple pages while keeping the connection open - but still it seems that UDP would be a better fit. Except, perhaps, for POST requests, since those are not usually idempotent.)
People will use headlights for another 50 years...Lights will be integral part of cities... Unless they ban flashing of lights.... this cant be outlawed
In some places (Connecticut, and Britain, I think, and surely others) it is illegal to flash your headlights at another motorist to warn him of a speed trap. Outrageous but true! For some reason it is this particular law, rather than anything about copyrights or encryption or wiretapping, which suggests to me the slow drift towards a police state.
Well Dr Pepper's campaign seems to have worked: after seeing this Slashdot article this morning, when I wanted something to drink I bought a can of Dr Pepper (for the first time in ages) from the vending machine. Of course the fact that the only choice was Dr Pepper or Sprite may have had something to do with it.
'Advice' in Emacs Lisp is handy for running your own custom code before or after any existing function. So it's another way of adding hooks to existing code. A highly customizable app like Emacs is a natural place for this sort of language facility.
And of course, INTERCAL has the 'COME FROM' statement.
I'm pretty sure that in a few years time, there will be a medium which will be (a) cheaper than today's RAM and (b) faster than anything which is not random-access.
The design choice is this. You have devices which are cheap, but very slow and which do not have random access, requiring things like elevator scheduling algorithms to get even reasonable performance. These are currently called disks. On the other hand, there are devices which are more expensive, but much faster and random-access (or very close to it). By definition these are called random access memory (RAM). It seems pretty clear that both these types of memory will be around in the future.
By the time large databases fit in memory, DDR RAM or RDRAM as we know it today will surely be obsolete, but there will be some other kind of RAM to replace it.
1) Even with an on-disk RDBMS you're still limited by RAM to a certain extent: selecting from tables will only be acceptably fast when you have enough RAM for all the important stuff to be cached in memory. OK, you can create indexes, but some things (eg arbitrary substring lookup) aren't easy to index.
Making an RDBMS perform well even for databases that are bigger than RAM size requires tuning and to know what you are doing. I imagine that if using object prevalence is an option, then there is a class of medium-sized applications where you have the choice of either hiring a knowledgeable DBA to optimize your Oracle setup, or just buying an obscene amount of memory. Nowadays the latter option may be cheaper and easier.
2) Replaying a log would be pretty quick, I imagine, since it is just reading from disk and updating data in RAM. (As opposed to an RDBMS which must both read from disk and write to disk when recovering.) Anyway, there's no particular reason why the checkpoint should be once a day. Suppose your database fits into ten gigabytes - then with current disk speeds you coud easily write a complete snapshot every ten minutes or so.
3) You can still use SQL with an in-memory database, it'll just be faster, that's all:-). Somebody would need to write the SQL engine but it's surely not a hard task if all you need do is naively evaluate the query and not worry about joining strategies etc. (Well, not worry quite so much as you would if running off disk.)
Even if your database doesn't fit in affordable RAM today, it probably will in a few years. RAM prices fall faster than database sizes increase. Already a couple of gigabytes of storage is more than enough for a big class of applications.
Mirroring is cool though because it boosts read performance, and does so without having to pick a stripe size. Striping improves only reads bigger than the stripe size, and of course once you have striping you have to store parity information too in case of failure, which slows everything down.
Yeah, you don't get any extra space compared to a single disk, but I find one disk more than big enough anyway:-). Even for many servers nowadays a single disk is big enough - just not reliable enough and often not fast enough.
With mirroring, a write has to go to all of the disks, but still the write speed is no worse than writing to a single disk. But what I'd like to see is a form of mirroring where writes don't have to go to all disks at once, but maybe just one or two with the others catching up afterwards.
So you would tell the driver 'I want any data written to go to at least two disks in my ten-disk array'. Then a write would at first go to two disks chosen at random (or chosen for being less busy with other writes), and later on when there is some spare time the same write could be propagated to the other disks. Then you would be safe against the failure of one disk, but most of the array could continue reading while a couple of disks are writing. Recovery after a crash would involve looking at each disk to see which has the most up-to-date information for each sector, so you'd need to keep some kind of record of what disk was written most recently for the given sector. And that record would itself have to be distributed across multiple disks. But even allowing for that, such a mirroring system could give big improvements in write performance.
RAID1 doesn't lose the whole array from a single failure, surely? I thought RAID1 meant store the same data on every disk in the array, which would make it more resilient than RAID4 or RAID5.
Red Herring, the magazine considered a must-read among the technology elite,
Who are these 'technology elite'? Do they still exist after the dotcom bubble burst? Did they ever exist? Were their numbers ever big enough to sustain a magazine?
In terms of viewers/listeners, his biggest role was probably as the Voice of Canada during WW2, but most SF fans will be too young (or too non-Canadian) to remember that.
Well, if you have ten X terminals you need a central server running applications. This server needs to be kept patched and up to date, new apps need to be installed, and so on. If you have to do that job on one machine you might as well do it for ten machines, and push the same filesystem image to each box (or maintain the machines using a package system like RPM). OK it is more work, but not _that_ much more work.
OK, so copy the files to the hard disk. But if the disk gets wiped or the game moves to a different computer, there is no need for reinstallation and no loss of saved data. The idea still isn't practical for other reasons, however.
They also complained that Microsoft forced buyers to purchase expensive bundles of software rather than picking only the products they desired.
The thing is, the prices for Office software are essentially arbitrary. It costs Microsoft exactly the same amount whether you buy just Word or the whole suite. Software companies like to make out that they are doing consumers a favour by offering 'flexible' pricing plans, but in fact the various complex systems are just there for market segmentation, to get the most out of each individual consumer. The idea of 'pay for what you use' makes little sense when each extra thing you use costs precisely zero to the manufacturer.
If anything, they should be forcing Microsoft to bundle everything together - if you could only buy Windows + Office + Exchange Server + SQL Server + MS Bob 2.0 as a single package, and there were a big crackdown on piracy, then the price would come way down because MS would not want to surrender the desktop. But enforcing this would have no basis in competition law.
Yes, and the point is that the patent office cannot distinguish between 'good' and 'bad' patents in a certain field (such a judgement would be far too subjective), so it comes down to a binary choice: grant patents on computer programs, or not.
Damn right. Universities that run Unix will almost certainly be running a fat-client model, that is, a full Unix system on each desktop. If a Sun workstation in 1989 had enough power to run as a standalone machine, why should it be necessary to resort to X terminals now? A full Unix box is not that much more difficult to administer than an X terminal (well, not if you do it right and have a single configuration pushed to every one of the desktops) and the hardware is not any more expensive (I'm pretty sure the biggest cost of a system nowadays is getting a decent monitor).
When I was at university there was a policy saying 'you will not send any message that attempts or purports to be anonymous'. It's arguable whether sharing a file on a P2P network is equivalent to sending an anonymous message, but it's against the spirit of the policy I think. If you are putting content out there, you should be prepared to sign your name to it. I do not think this is unreasonable within a university.
I don't think you should judge an individual patent on whether it helps society as a whole, but rather judge a whole class of patents. If you extend the patent system to a given field (such as software) then some of the patents granted will have a net benefit to society (taking into account incentives to develop the 'invention' in the first place, the negative effects on competition, and many other factors) and some of the patents granted will have a negative effect overall. You should ask, taking all patents in the particular field together, is it economically worthwhile for the USPTO to start granting patents in this field?
I think the Supreme Court ruled that the USPTO did not have to individually assess patents on whether they 'promote progress in science and the useful arts'. Rather, it is the job of the patent office to implement as a whole the system decided by Congress, and Congress must choose the boundaries of the patent system to promote progress.
Sure it's your own business whether to use P2P or not. I just said you wouldn't *need* to use such systems.
If you don't have web space then I guess you don't have the option of putting files on a web page, even for those that are legal. But I'd hope that universities (the topic of the article) provide their students with personal web space; the ones which aren't enlightened enough to do that probably block the P2P services as well.
Slashdot Mirror
I was thinking about networking textbooks which say things like 'though a UDP packet could in theory get dropped en route, this hardly ever happens in practice'. I didn't take account of the fact that these books were talking mostly about LANs and other private networks rather than the big, bad Internet.
If UDP is reliable enough for NFS, it should be reliable enough for web pages, right? If the reply to your request doesn't arrive after a certain time you can just send the request again.
Good point about the response not fitting in a UDP packet: does NFS avoid this problem by always requesting small enough chunks of data to fit in a single packet?
Once you start having to do both rerequesting dropped packets and reordering those that arrive out of sequence it does start to look as though TCP is a better bet, since it does these things for you. Nonetheless, since dropped UDP packets are fairly uncommon in practice it might be quicker most of the time to save on the overhead of setting up a TCP connection and just send a single UDP packet instead.
If you get frequent-flyer miles from flights paid for by your company, don't those extra miles also belong to the company? If you use them for personal travel you should at least get explicit permission for this.
There was a company making a business model out of helping other firms work around the incentive structures of airlines (which were thought to corrupt employees, making them choose the flight with the best perks, rather than the cheapest). So firms would accumulate the extra miles for themselves. I can't remember the company's name now, however.
In the UK there is nothing in the Highway Code about flashing headlamps to warn of speed traps. I think it is illegal because of separate legislation (or maybe it is not illegal at all and I am misremembering). Equally there is nothing in the HC about drink-driving... the Code doesn't exclusively define the law on motoring.
Yes, it's a pity that HTTP doesn't use UDP to start with. Why design a stateless protocol and then put it on top of TCP, requiring a connection to be set up and torn down for each HTTP request?
(OK, newer HTTP versions can fetch multiple pages while keeping the connection open - but still it seems that UDP would be a better fit. Except, perhaps, for POST requests, since those are not usually idempotent.)
Well Dr Pepper's campaign seems to have worked: after seeing this Slashdot article this morning, when I wanted something to drink I bought a can of Dr Pepper (for the first time in ages) from the vending machine. Of course the fact that the only choice was Dr Pepper or Sprite may have had something to do with it.
'Advice' in Emacs Lisp is handy for running your own custom code before or after any existing function. So it's another way of adding hooks to existing code. A highly customizable app like Emacs is a natural place for this sort of language facility.
And of course, INTERCAL has the 'COME FROM' statement.
RAM will be slower than disks? I doubt it.
I'm pretty sure that in a few years time, there will be a medium which will be (a) cheaper than today's RAM and (b) faster than anything which is not random-access.
The design choice is this. You have devices which are cheap, but very slow and which do not have random access, requiring things like elevator scheduling algorithms to get even reasonable performance. These are currently called disks. On the other hand, there are devices which are more expensive, but much faster and random-access (or very close to it). By definition these are called random access memory (RAM). It seems pretty clear that both these types of memory will be around in the future.
By the time large databases fit in memory, DDR RAM or RDRAM as we know it today will surely be obsolete, but there will be some other kind of RAM to replace it.
Advogato article on this topic (with comments)
1) Even with an on-disk RDBMS you're still limited by RAM to a certain extent: selecting from tables will only be acceptably fast when you have enough RAM for all the important stuff to be cached in memory. OK, you can create indexes, but some things (eg arbitrary substring lookup) aren't easy to index.
:-). Somebody would need to write the SQL engine but it's surely not a hard task if all you need do is naively evaluate the query and not worry about joining strategies etc. (Well, not worry quite so much as you would if running off disk.)
Making an RDBMS perform well even for databases that are bigger than RAM size requires tuning and to know what you are doing. I imagine that if using object prevalence is an option, then there is a class of medium-sized applications where you have the choice of either hiring a knowledgeable DBA to optimize your Oracle setup, or just buying an obscene amount of memory. Nowadays the latter option may be cheaper and easier.
2) Replaying a log would be pretty quick, I imagine, since it is just reading from disk and updating data in RAM. (As opposed to an RDBMS which must both read from disk and write to disk when recovering.) Anyway, there's no particular reason why the checkpoint should be once a day. Suppose your database fits into ten gigabytes - then with current disk speeds you coud easily write a complete snapshot every ten minutes or so.
3) You can still use SQL with an in-memory database, it'll just be faster, that's all
Even if your database doesn't fit in affordable RAM today, it probably will in a few years. RAM prices fall faster than database sizes increase. Already a couple of gigabytes of storage is more than enough for a big class of applications.
Mirroring is cool though because it boosts read performance, and does so without having to pick a stripe size. Striping improves only reads bigger than the stripe size, and of course once you have striping you have to store parity information too in case of failure, which slows everything down.
:-). Even for many servers nowadays a single disk is big enough - just not reliable enough and often not fast enough.
Yeah, you don't get any extra space compared to a single disk, but I find one disk more than big enough anyway
With mirroring, a write has to go to all of the disks, but still the write speed is no worse than writing to a single disk. But what I'd like to see is a form of mirroring where writes don't have to go to all disks at once, but maybe just one or two with the others catching up afterwards.
So you would tell the driver 'I want any data written to go to at least two disks in my ten-disk array'. Then a write would at first go to two disks chosen at random (or chosen for being less busy with other writes), and later on when there is some spare time the same write could be propagated to the other disks. Then you would be safe against the failure of one disk, but most of the array could continue reading while a couple of disks are writing. Recovery after a crash would involve looking at each disk to see which has the most up-to-date information for each sector, so you'd need to keep some kind of record of what disk was written most recently for the given sector. And that record would itself have to be distributed across multiple disks. But even allowing for that, such a mirroring system could give big improvements in write performance.
RAID1 doesn't lose the whole array from a single failure, surely? I thought RAID1 meant store the same data on every disk in the array, which would make it more resilient than RAID4 or RAID5.
In terms of viewers/listeners, his biggest role was probably as the Voice of Canada during WW2, but most SF fans will be too young (or too non-Canadian) to remember that.
Interesting. I thought the show just suffered from biblical analogies taken a bit too far. Still maybe that's what Mormonism is. Hmm,
Mormonism: religion -> science fiction
Scientology: science fiction -> religion
Well, if you have ten X terminals you need a central server running applications. This server needs to be kept patched and up to date, new apps need to be installed, and so on. If you have to do that job on one machine you might as well do it for ten machines, and push the same filesystem image to each box (or maintain the machines using a package system like RPM). OK it is more work, but not _that_ much more work.
OK, so copy the files to the hard disk. But if the disk gets wiped or the game moves to a different computer, there is no need for reinstallation and no loss of saved data. The idea still isn't practical for other reasons, however.
The thing is, the prices for Office software are essentially arbitrary. It costs Microsoft exactly the same amount whether you buy just Word or the whole suite. Software companies like to make out that they are doing consumers a favour by offering 'flexible' pricing plans, but in fact the various complex systems are just there for market segmentation, to get the most out of each individual consumer. The idea of 'pay for what you use' makes little sense when each extra thing you use costs precisely zero to the manufacturer.
If anything, they should be forcing Microsoft to bundle everything together - if you could only buy Windows + Office + Exchange Server + SQL Server + MS Bob 2.0 as a single package, and there were a big crackdown on piracy, then the price would come way down because MS would not want to surrender the desktop. But enforcing this would have no basis in competition law.
Yes, and the point is that the patent office cannot distinguish between 'good' and 'bad' patents in a certain field (such a judgement would be far too subjective), so it comes down to a binary choice: grant patents on computer programs, or not.
Damn right. Universities that run Unix will almost certainly be running a fat-client model, that is, a full Unix system on each desktop. If a Sun workstation in 1989 had enough power to run as a standalone machine, why should it be necessary to resort to X terminals now? A full Unix box is not that much more difficult to administer than an X terminal (well, not if you do it right and have a single configuration pushed to every one of the desktops) and the hardware is not any more expensive (I'm pretty sure the biggest cost of a system nowadays is getting a decent monitor).
When I was at university there was a policy saying 'you will not send any message that attempts or purports to be anonymous'. It's arguable whether sharing a file on a P2P network is equivalent to sending an anonymous message, but it's against the spirit of the policy I think. If you are putting content out there, you should be prepared to sign your name to it. I do not think this is unreasonable within a university.
I don't think you should judge an individual patent on whether it helps society as a whole, but rather judge a whole class of patents. If you extend the patent system to a given field (such as software) then some of the patents granted will have a net benefit to society (taking into account incentives to develop the 'invention' in the first place, the negative effects on competition, and many other factors) and some of the patents granted will have a negative effect overall. You should ask, taking all patents in the particular field together, is it economically worthwhile for the USPTO to start granting patents in this field?
I think the Supreme Court ruled that the USPTO did not have to individually assess patents on whether they 'promote progress in science and the useful arts'. Rather, it is the job of the patent office to implement as a whole the system decided by Congress, and Congress must choose the boundaries of the patent system to promote progress.
Sure it's your own business whether to use P2P or not. I just said you wouldn't *need* to use such systems.
If you don't have web space then I guess you don't have the option of putting files on a web page, even for those that are legal. But I'd hope that universities (the topic of the article) provide their students with personal web space; the ones which aren't enlightened enough to do that probably block the P2P services as well.