Speeding. 99% of respondents want to drive faster than the speed limit, it seems.
Remember that driving is licensed, it's not a right. You are permitted to drive on the road if you obey the rules of the road, and you expect your government, who grant you that licence, to enforce the rules of the road.
You would expect the police to arrest drunk drivers - they are abusing their licence. You should expect them to control road speed, for the same reason. The rules are there, it's not as if you don't know what they are, and whether you like them or not they all apply equally to you.
If you feel that you should be able to drive faster than you're presently legally allowed to, then win the argument and get the law changed. But please stop bitching about the way that a given rule of the road applies to you; those are the terms you agreed to when you stepped into your car.
How many trucks have been tailgating you, at the speed limit, with less than 10m clearance recently? If the answer is more than 'none', I suggest you relocate.
Actually, reading up on this, I wonder about my conclusion: looks more like development dried up without an initial release, since mailing list posts go on for another year after that patent post...
The reference for that patent issue: http://lkml.indiana.edu/hypermail/linux/kernel/0010.0/0343.html - the filesystem was Daniel Phillips' Tux2, and it was making some progress before development was halted due to the risk of treading on Network Appliance's toes.
Something has to run the graphics. In general, in Unix, this would be a process or the kernel. Assuming you don't think it's a good responsibility for the kernel (it really isn't, other than the memory protection issues that come up with memory-accessing and memory-mapped hardware) then it has to be a process.
Things share the screen in graphical environments. One piece co-ordinates that sharing and manages the desktop. That process is therefore providing a service and is always a server, whether it's X or the MacOS system.
Actually, I'd argue that the LINQ-to-SQL stuff makes it *easier* rather than more difficult to target different DBs. And the CLR VM clearly runs on other (Intel) platforms as part of Silverlight.
dojox.gfx - SVG for SVG browsers, VML for non-SVG browsers, working right now as part of the dojo toolkit. Admittedly it's cruft you shouldn't need, but it means you have compatible vector graphics on IE6, IE7, FF, Safari (iPhone included) and Opera. And it's available now.
Yes, I'd sooner see SVG working at the page level on IE. But if and when it arrives, it *still* won't be compatible with everyone else's implementations...
Not a great deal of Russian spoken in the EU... But of course the EU and Russia are a long way away from America, and thus the general principle of 'things that are a long way away are *all the same*' applies.
More to the point, if you you choose to learn an Indian language, which one do you pick? Hindi is widely spoken outside its local area, in the same way English is, but it's not spoken by everyone.
In Bangalore the local language is Kannada (which most foreigners have never heard of). Go 30 miles down the road to Tamil Nadu and the local language is Tamil. And so it goes on. Plus the problem that all three of these Indian languages (and several others) have different scripts, none remotely like the Roman alphabet and in these particular examples not a great deal like each other either.
Being only an English-speaker, my dealings with Indians have naturally been self-selecting, but I've met engineers who are 'only' bilingual in their region's language and English, and would have the same problem as the rest of us would when moving around India.
Oh, and road signs in Bangalore, if you have enough of a death wish to want to drive yourself, are in Kannada and English. You never see anything else written on street or shop signs - no Hindi at all.
MS introduce an alternative licensing model for their customers. Presently, customers choose to buy MS Office even at its current cost. Wise customers in certain circumstances may choose to rent it instead, saving themselves money.
Thus, Office, on the whole, is cheaper than it was. And in specific cases is no more expensive.
These people have chosen MSOffice over OpenOffice, and now it costs them less. And you're suggesting that because MSOffice is cheaper, they'll stop using it?
I think a bug is highly unlikely, because to be honest a simple sequential read test almost has to be one of the ones they run (speaking personally, anyway: easily implemented tests first, complicated tests later), and a speed regression would be something they would be looking for.
A rebalancing would seem to be the most likely explanation but I'd love to hear their explanation of the effect on sequential read performance. Likely they consider such information proprietary, though, and won't say anything unless the market seriously rebels...
It's interesting to note that the general purpose benchmarks come out with AAK in the lead while the others, all very much sequential read focussed, don't. So the question is, what exactly are the operations that the AAK is doing faster in the mixed benchmarks? Seeking? Or maybe it's a bus bandwidth limit at the hard drive end?
Sadly, we can't tell, because the author has focussed on the sensationalism of poor performance rather than asking these questions. Seems to need a few more experiments setting up, or alternatively an answer from the horse's mouth.
Some candidate theories: - microcontroller software bug (unlikely) - hardware cost-down such as a slower, cheaper microcontroller or less RAM on the drive (quite likely) - rebalancing the performance optimisation, changing the cacheing or readahead algorithms to suit typical loads (possible, but it seems odd that this would limit linear read performance)
I agree the whole atime thing is bollocks, but you can improve efficiency while keeping the semantics - cache atime updates in one place.
The issue is the need to keep in memory a dirty copy of every inode block with updated atimes (and there are lots of inode blocks, and you have open a few files from all over the disk, so worst case you're maintaining 1 block per open file), and write them every 30s or however often.
If, instead, you kept an atime cache of (inode number, atime) which (if an entry was present) overrode the entry in the basic inode, then you could just update this cache and write its (2 or 3) blocks out to disk. You can propagate the changes to the inode atime once the file's been closed a while (and then reuse the entry in the cache, keeping its size down). You might also decide that writing the atime cache is very low urgency and only do it when other disk changes are made.
A quick off the cuff calculation suggests that a 4k block would hold 512 files worth of this information. I don't know how many open files there are on a machine at once, but on a desktop-usage one, I suspect it's less than a couple of thousand most of the time.
The risk is the effect it might have on fast path code for inode lookups. You'd be adding a hash table lookup for every inode fetch.
Do you find that CPU usage is a problem? Granted, with something like a VIA Eden, it would be, but I've got an XP2400+ and it seems to encodes MJPEGs quite happily at 768x576 with only about 20% CPU usage - which I can then transcode, cos Mythtv, like nearly every other PVR system out there, is good at that sort of thing.
It also means I can run filters on the pre-encoded signal - otherwise I'd presumably be limited to whatever the PVR hardware is capable of doing before it runs the signal through its compressor. (This is, admittedly, where CPU becomes tight - a big picture with Mythtv's kerneldeint and denoise3d is slightly too much work. But you can miss the denoise filter off if your signal's good enough, anyway, and I freely admit that the resolution it's set to is a bit over the top.)
I might switch to a PVR250 one of these days, but CPU usage just doesn't seem to be the critical issue with my PVR box at the moment and I had a non-compressing TV card anyway. As processor speed inevitably gets cheaper, I would expect the money to be better spent on speeding up the system and not offloading the work, too.
I can see what you're trying to say, but the problem is that a filesystem can't say who instigated its mount. As far as the FS is concerned, root mounted it (because it's an SUID call). So when someone comes to access a file, the FS has nothing to compare against.
Plan9 has this right - since the FS is a process and not a kernel component, it is only as trusted as the user that runs it, so root mounts are very trusted (to the extent that SUID is respected, for instance) and user mounts aren't. Sadly, Plan9 is neither free nor written in a normal language (they went with some deviant C dialect), and not really POSIX enough for anything else to deal well with it.
The GNU HURD also deals with things this way (settrans) and is Unix-alike enough that you can get ports of stuff to it.
None of these filesystems allows regular users to access remote filesystems (superuser privileges are required for mounting) like with FTP.
Not really their fault. That's a feature of Unix.
In a 'fair' OS, if you owned a block device, then you should be able to mount it (providing the files then end up all owned by you). Unix generally considers mounting to require superuser privileges for simplicity of the protection system. This isn't limited just to NFS - it's true of local data, as I described above.
If you want different, get Plan9. If you want different and free, rewrite Plan9...
Actually it's more like $5, cos American gallons are wussy and small. (83.9p/litre, $1.80 exchange rate)
And if they didn't tax petrol they'd just tax something else to make up the money. Personally I'd sooner see the tax used to discourage people from burning petrol.
And as long as people are too stupid tell the difference between any piece of paper and the paper they're actually looking for, then they deserve the underqualified staff they'll inevitably employ.
Slashdot Mirror
Speeding. 99% of respondents want to drive faster than the speed limit, it seems.
Remember that driving is licensed, it's not a right. You are permitted to drive on the road if you obey the rules of the road, and you expect your government, who grant you that licence, to enforce the rules of the road.
You would expect the police to arrest drunk drivers - they are abusing their licence. You should expect them to control road speed, for the same reason. The rules are there, it's not as if you don't know what they are, and whether you like them or not they all apply equally to you.
If you feel that you should be able to drive faster than you're presently legally allowed to, then win the argument and get the law changed. But please stop bitching about the way that a given rule of the road applies to you; those are the terms you agreed to when you stepped into your car.
How many trucks have been tailgating you, at the speed limit, with less than 10m clearance recently? If the answer is more than 'none', I suggest you relocate.
None? (In all likelihood, since it would coast gently to a stop. Don't use hyperbole.)
So when your engine management system dies and your car stops, do you think you'd win a case against the car manufacturer for that?
Actually, reading up on this, I wonder about my conclusion: looks more like development dried up without an initial release, since mailing list posts go on for another year after that patent post...
The reference for that patent issue: http://lkml.indiana.edu/hypermail/linux/kernel/0010.0/0343.html - the filesystem was Daniel Phillips' Tux2, and it was making some progress before development was halted due to the risk of treading on Network Appliance's toes.
Care to clarify what you mean?
Something has to run the graphics. In general, in Unix, this would be a process or the kernel. Assuming you don't think it's a good responsibility for the kernel (it really isn't, other than the memory protection issues that come up with memory-accessing and memory-mapped hardware) then it has to be a process.
Things share the screen in graphical environments. One piece co-ordinates that sharing and manages the desktop. That process is therefore providing a service and is always a server, whether it's X or the MacOS system.
So, userspace server it is, then.
Actually, I'd argue that the LINQ-to-SQL stuff makes it *easier* rather than more difficult to target different DBs. And the CLR VM clearly runs on other (Intel) platforms as part of Silverlight.
dojox.gfx - SVG for SVG browsers, VML for non-SVG browsers, working right now as part of the dojo toolkit. Admittedly it's cruft you shouldn't need, but it means you have compatible vector graphics on IE6, IE7, FF, Safari (iPhone included) and Opera. And it's available now.
Yes, I'd sooner see SVG working at the page level on IE. But if and when it arrives, it *still* won't be compatible with everyone else's implementations...
Not a great deal of Russian spoken in the EU... But of course the EU and Russia are a long way away from America, and thus the general principle of 'things that are a long way away are *all the same*' applies.
University-educated Indians speak English
More to the point, if you you choose to learn an Indian language, which one do you pick? Hindi is widely spoken outside its local area, in the same way English is, but it's not spoken by everyone.
In Bangalore the local language is Kannada (which most foreigners have never heard of). Go 30 miles down the road to Tamil Nadu and the local language is Tamil. And so it goes on. Plus the problem that all three of these Indian languages (and several others) have different scripts, none remotely like the Roman alphabet and in these particular examples not a great deal like each other either.
Being only an English-speaker, my dealings with Indians have naturally been self-selecting, but I've met engineers who are 'only' bilingual in their region's language and English, and would have the same problem as the rest of us would when moving around India.
Oh, and road signs in Bangalore, if you have enough of a death wish to want to drive yourself, are in Kannada and English. You never see anything else written on street or shop signs - no Hindi at all.
OK, run that last line by me one more time...
MS introduce an alternative licensing model for their customers. Presently, customers choose to buy MS Office even at its current cost. Wise customers in certain circumstances may choose to rent it instead, saving themselves money.
Thus, Office, on the whole, is cheaper than it was. And in specific cases is no more expensive.
These people have chosen MSOffice over OpenOffice, and now it costs them less. And you're suggesting that because MSOffice is cheaper, they'll stop using it?
Cambridge Uni, 90s, same principle. Desktop sessions would follow you around using VNC...
66/100, I get. Jerky on update, and I may be getting a slightly off rendering because AdBlock Plus is adding 'block' elements to the page.
I think a bug is highly unlikely, because to be honest a simple sequential read test almost has to be one of the ones they run (speaking personally, anyway: easily implemented tests first, complicated tests later), and a speed regression would be something they would be looking for.
A rebalancing would seem to be the most likely explanation but I'd love to hear their explanation of the effect on sequential read performance. Likely they consider such information proprietary, though, and won't say anything unless the market seriously rebels...
It's interesting to note that the general purpose benchmarks come out with AAK in the lead while the others, all very much sequential read focussed, don't. So the question is, what exactly are the operations that the AAK is doing faster in the mixed benchmarks? Seeking? Or maybe it's a bus bandwidth limit at the hard drive end?
Sadly, we can't tell, because the author has focussed on the sensationalism of poor performance rather than asking these questions. Seems to need a few more experiments setting up, or alternatively an answer from the horse's mouth.
Some candidate theories:
- microcontroller software bug (unlikely)
- hardware cost-down such as a slower, cheaper microcontroller or less RAM on the drive (quite likely)
- rebalancing the performance optimisation, changing the cacheing or readahead algorithms to suit typical loads (possible, but it seems odd that this would limit linear read performance)
I agree the whole atime thing is bollocks, but you can improve efficiency while keeping the semantics - cache atime updates in one place.
The issue is the need to keep in memory a dirty copy of every inode block with updated atimes (and there are lots of inode blocks, and you have open a few files from all over the disk, so worst case you're maintaining 1 block per open file), and write them every 30s or however often.
If, instead, you kept an atime cache of (inode number, atime) which (if an entry was present) overrode the entry in the basic inode, then you could just update this cache and write its (2 or 3) blocks out to disk. You can propagate the changes to the inode atime once the file's been closed a while (and then reuse the entry in the cache, keeping its size down). You might also decide that writing the atime cache is very low urgency and only do it when other disk changes are made.
A quick off the cuff calculation suggests that a 4k block would hold 512 files worth of this information. I don't know how many open files there are on a machine at once, but on a desktop-usage one, I suspect it's less than a couple of thousand most of the time.
The risk is the effect it might have on fast path code for inode lookups. You'd be adding a hash table lookup for every inode fetch.
Do you find that CPU usage is a problem? Granted, with something like a VIA Eden, it would be, but I've got an XP2400+ and it seems to encodes MJPEGs quite happily at 768x576 with only about 20% CPU usage - which I can then transcode, cos Mythtv, like nearly every other PVR system out there, is good at that sort of thing.
It also means I can run filters on the pre-encoded signal - otherwise I'd presumably be limited to whatever the PVR hardware is capable of doing before it runs the signal through its compressor. (This is, admittedly, where CPU becomes tight - a big picture with Mythtv's kerneldeint and denoise3d is slightly too much work. But you can miss the denoise filter off if your signal's good enough, anyway, and I freely admit that the resolution it's set to is a bit over the top.)
I might switch to a PVR250 one of these days, but CPU usage just doesn't seem to be the critical issue with my PVR box at the moment and I had a non-compressing TV card anyway. As processor speed inevitably gets cheaper, I would expect the money to be better spent on speeding up the system and not offloading the work, too.
I can see what you're trying to say, but the problem is that a filesystem can't say who instigated its mount. As far as the FS is concerned, root mounted it (because it's an SUID call). So when someone comes to access a file, the FS has nothing to compare against.
Plan9 has this right - since the FS is a process and not a kernel component, it is only as trusted as the user that runs it, so root mounts are very trusted (to the extent that SUID is respected, for instance) and user mounts aren't. Sadly, Plan9 is neither free nor written in a normal language (they went with some deviant C dialect), and not really POSIX enough for anything else to deal well with it.
The GNU HURD also deals with things this way (settrans) and is Unix-alike enough that you can get ports of stuff to it.
None of these filesystems allows regular users to access remote filesystems (superuser privileges are required for mounting) like with FTP.
Not really their fault. That's a feature of Unix.
In a 'fair' OS, if you owned a block device, then you should be able to mount it (providing the files then end up all owned by you). Unix generally considers mounting to require superuser privileges for simplicity of the protection system. This isn't limited just to NFS - it's true of local data, as I described above.
If you want different, get Plan9. If you want different and free, rewrite Plan9...
It has no screen and there's no guarantee that the serial ports are like those on PCs. So unless you've tried this I'm not convinced.
Hm, you could port Minix ;-)
Actually it's more like $5, cos American gallons are wussy and small. (83.9p/litre, $1.80 exchange rate)
And if they didn't tax petrol they'd just tax something else to make up the money. Personally I'd sooner see the tax used to discourage people from burning petrol.
Cambridge beer festival in 10 days, mmm... ;-)
And as long as people are too stupid tell the difference between any piece of paper and the paper they're actually looking for, then they deserve the underqualified staff they'll inevitably employ.