I never rent VHS/DVD or cars. I haven't flown in years, I donot use the train. Any other examples you care to try on me?
I however also wouldn't pay for just an internet site. Internet sites, even sites like last.fm, are a dime a dozen. If last.fm does not cater to my wishes, I will find another site that does, and does so free. It's like newssites deluding themselves that is worth paying for a subscription, when news is available from thousands of other free outlets.
Agreed, and these people doing the filtering, who obviously have seen too much and have become mentally twisted after a few years, should therefore not be allowed to roam free anymore. To protect the children.
As a filesystem author, I can tell you that calling fsync() for whatever reason is ALWAYS a huge performance hit. The only thing applications expect is that things are ==SEEMINGLY== done in order (as in a time line). Ext4 can send stuff over the internet for all I care, but when my application asks it to do A, B, C, then no matter what happens, I can NEVER EVER end up with A & C after a crash. The only acceptable states after a crash are nothing at all, A, A+B or A+B+C.
That still leaves plenty of room for writing things out-of-order and doing delayed block allocation, because, as long as order is guaranteed, I don't care if things happen like this:
A (10 minutes pause) B + C
The order of the actions is important, not when they get flushed (if ever), as long as no FUTURE events are flushed first without flushing all preceding events. I could write a filesystem that only touches the disc every 30 minutes (given sufficient memory) and still be able to preserve this simple basic expectation.
The bug does NOT exist in Ext3 with its default mount options, because it saves data in ordered mode. That means that it will either flush everything to disk up to a certain point in time (meta data and data alike) or nothing at all.
The problem with Ext4 is that they decided it would be a good idea to have 2 time lines. One for meta-data, and one for other data. It's possible those two are NOT in sync (as in, meta-data has been flushed up to point X in time, while data only has been flushed until point Y in time). Since meta-data is usually tiny in comparison to actual data, I don't even see why they would do this. Just donot flush meta-data until you have to actually flush real data as well. Problem solved.
Furthermore, if you indeed did change all applications to call fsync() when needed, performance of Ext4 would be worse than current Ext3 performance in ordered mode.
In any sane country, yellow light time is solely determined by the maximum allowed speed on the road the light is installed on. It's determined by reaction time, stopping distance and the maximum speed.
Exactly, my only "promotion" path was towards a management job. I don't want to stop programming, ever (if I can help it). So instead I checked my options (after 8 years of solid service), found that the company did not want to actually reward my performance better, so I quit. I work freelance now, and can safely say that it is far more rewarding in more than one sense.
Unfortunately, in the world of software development, a less brilliant programmer will also have less foresight or not have a proper grasp of complexities involved with multiple users, multiple threads, or anything else that involves scaling up an application to serve thousands instead of just him/herself when debugging it.
A brilliant programmer can not only write code faster, they can do it with less bugs, more foresight, using better algorithms and more often than not produce something that is easier to maintain/configure/extend later on as well. The end result is often an order of magnitude better than what an average programmer produces. Unfortunately, management rarely realizes how big a difference it can make on the bottom line, and rarely will these people be actually paid a salary that is an order of magnitude higher (certainly not more than their "manager"...)
The hit by the bus argument does not fly. It may take a while to figure it out, but there are people that can figure it out.
When practically the entire senior programmer team quit on the spot at a company I used to work for (I was one of the ones that quit), I figured they'd be in a lot of trouble, as quite a lot of the code written was never even seen by the ones that remained. Yet, they're thriving. They brought in some young talent and raised wages for the remaining team, and they're doing just fine. Yes, it did wake the company up (teams were restructured, wages raised, programmers actually got a say in things) and there were some problems with the next release cycle, but they're doing fine again.
Sometimes things simply are complex. For example, recently I was working on an algorithm that given a list of (value, instantInTime) pairs would determine the biggest difference of 'value' in a certain time interval. The values are not evenly distributed, can contain huge gaps, or multiple measurements in short periods. The value (as measured) is valid until another value overrides it at a later instant in time . Which means to get the value at a certain point in time, you need to walk the list to figure out what the value is at that time.
That's the easy part. Walking the list could be done using a binary search algorithm, but that wasn't even the complex part. To determine the biggest X second difference in a set of values that spawn 300 seconds, you could do this (X = intervalInMillis):
0 int getBiggestDifference(ValueSet values, int intervalInMillis) { 0 int biggestDifference = 0; 0 0 for(int t = 0; t < 300 * 1000 - intervalInMillis; t += 100) { 0 int diff = Math.abs(values.getValueAtTime(t) - values.getValueAtTime(t + intervalInMillis)); 0 0 if(diff > biggestDifference) { 0 biggestDifference = diff; 0 } 0 } 0 0 return biggestDifference; 0 }
That's the simple, inaccurate, slow version. Inaccurate because it only checks steps of 100 ms, slow because it calls "getValueAtTime" very often. Increase the accuracy or the size of the period to search, and it gets even slower. It however works 99% correct and is easy to understand.
The complex version took me quite a while to wrap my mind around, not to mention a lot of unit testing and comparing it with the "simple" version to make sure it really performed correctly (there's quite a few of nasty edge cases). It's also about 4-5 times more lines of code involving temporary data structures, and pretty much impossible to follow without a big comment to explain the algorithm used (I'm not even sure if there's a standard algorithm for it). It however scales far better when huge number of values are involved.
I hate excessive simplicity for the sake of clarity, this just tells me it was written FOR people that cannot be bothered to learn the language they're using. A place I worked at was actually considering banning certain practices that are part of the language, like multiple returns, ?: conditionals, regular expressions, fall-through cases, and so on. That's all nice and dandy, until those dumbed down programmers need to debug some framework they're using and donot understand what some rarely used operator does. Let alone having them work on threading problems or figuring why a garbage collected language is running out of memory.
If they cannot figure out a piece of complex, badly formatted piece of garbage code, then what hope is there they can debug real problems.
Way too verbose for me. If there's one thing I hate, it's variables being declared and assigned, and then only used once. Add a comment if you want to make it clearer, but please no "isThereASolarEclipseSomewhereInTheNextCentury" fields/methods.
I'm asking that when the filesystem does a sync (or commit or whatever you want to call it), that it commits EVERYTHING up to a point, not half. There's still plenty of room to reorder writes within those limits. For example, if I have 500 operations, and the filesystem is required to sync, then it can reorder those 500 operations all it wants. As long as when it's done, all of them are committed (or none). Not all of them except #399 cause it didn't like that one.
Totally agree. When the filesystem syncs, it must sync everything up to a certain point in time, and nothing after that point. If it doesn't, then you can end up with situations where steps that occurred earlier are not committed while later steps are. I wrote a journaled filesystem myself long ago, and even using a high commit interval it atleast would not mess with the order that events occurred.
A filesystem should respect the order of commands given to it. I don't care when it syncs, as long as there's no gaps in things I told it to do. Syncing later steps before having synced steps before it is ludicrous. Either sync them all in the same big batch or none at all. Syncing just half of them at random is gonna wreak havoc.
So, to put it more clearly:
OpenTempFile -> Write -> CloseTempFile -> RenameTempFileOverOriginal should never result in: OpenTempFile -> CloseTempFile -> RenameTempFileOverOriginal.
During a bad crash, I accept that the contents of one of these files may become corrupted, as writes may have been done in place and it would be excessive to have to log all content to the journal as well. I however donot accept that this can happen to dozens of files at the same time because the filesystem decided to sync future actions before syncing earlier steps.
-o sync is overkill.
A filesystem should respect the order of commands given to it. I don't care when it syncs, as long as there's no gaps in things I told it to do. Syncing later steps before having synced steps before it is ludicrous. Either sync them all in the same big batch or none at all. Syncing just half of them at random is gonna wreak havoc.
So, to put it more clearly:
OpenTempFile -> Write -> CloseTempFile -> RenameTempFileOverOriginal should never result in: OpenTempFile -> CloseTempFile -> RenameTempFileOverOriginal.
During a bad crash, I accept that the contents of one of these files may become corrupted, as writes may have been done in place and it would be excessive to have to log all content to the journal as well. I however donot accept that this can happen to dozens of files at the same time because the filesystem decided to sync future actions before syncing earlier steps.
That's all nice and stuff, but IMHO filesystems should atleast preserve the order of actions it syncs. So I don't care that when I do A, B, C, D and then E that I could end up with A + B + C or even just A, or nothing at all, that's fine.
However, ending up with something like:
A + D + E
seems to be highly undesirable. If the filesystem decides to a sync on its own, it should atleast sync everything up to a certain point in time, not pick and choose whatever happens to be handy. Most filesystems in fact do this, and the only thing they donot guarantee is that actual content *during* a sync is 100% safe (which means you only corrupt a file that was being written at the time crash). EXT4 seems to take it to a new level and will sync meta-data ahead of time without even attempting to write out the data that was part of earlier steps...
KDE never calls fsync(2), so the data from step one is not committed to be on disk. Thus, KDE is atomically replacing the old file with an uncommitted file. If the system crashes before it gets around to writing the data, too bad.
POSIX may allow it, but I was under the impression that filesystems should try and remain in a sane state. That means if my application does A, B, C and then D, that I expect the following to be on disk no matter what happens, either:
1) Nothing
2) A
3) A + B
4) A + B + C
5) A + B + C + D
It seems that EXT4 will deem that some of these are not as equal as others (if C for example is a data write), and can give you a new result like:
6) A + B + D
That's certainly unexpected, and highly undesirable if D happens to be something like "delete backup file" or a rename over an old file.
5 seconds seemed reasonable. 2.5 minutes does not. I have serious doubts that this will have much performance benefits at all. Furthermore, the performance benefits are likely to evaporate when used on SSD's, which are likely to become popular soon.
Even though you may wish that all applications treated filesystems as a transactional database, the reality is that almost none do, unless they actually are implementing a transactional database.
Most flatscreens I seen can't do a proper "black". Sure it looks great in the brightly lit store, but once you bring it home, and want to enjoy a nice movie in a dark room, suddenly every black is dark gray, making the picture look washed out. The funny bit is when I tell people this, they will tell me that their flatscreen has a 1:10000 contrast ratio or some such tripe... what they don't know is that this ratio is based on different images, not in the same image.
I was about to say the same thing. The drummer probably hears the effect, and just syncs to that consciously or subconsciously. I've done some drumming, and I know that I can and will be swayed by other effects if they're consistent and close enough to the tempo I want to play.
Slashdot Mirror
I'm not the OP, however...
I never rent VHS/DVD or cars. I haven't flown in years, I donot use the train. Any other examples you care to try on me?
I however also wouldn't pay for just an internet site. Internet sites, even sites like last.fm, are a dime a dozen. If last.fm does not cater to my wishes, I will find another site that does, and does so free. It's like newssites deluding themselves that is worth paying for a subscription, when news is available from thousands of other free outlets.
I suspect they may tell you to stop using the proxy. Then again, there's nothing stopping you from using a US based proxy.
Agreed, and these people doing the filtering, who obviously have seen too much and have become mentally twisted after a few years, should therefore not be allowed to roam free anymore. To protect the children.
As a filesystem author, I can tell you that calling fsync() for whatever reason is ALWAYS a huge performance hit. The only thing applications expect is that things are ==SEEMINGLY== done in order (as in a time line). Ext4 can send stuff over the internet for all I care, but when my application asks it to do A, B, C, then no matter what happens, I can NEVER EVER end up with A & C after a crash. The only acceptable states after a crash are nothing at all, A, A+B or A+B+C.
That still leaves plenty of room for writing things out-of-order and doing delayed block allocation, because, as long as order is guaranteed, I don't care if things happen like this:
A (10 minutes pause) B + C
The order of the actions is important, not when they get flushed (if ever), as long as no FUTURE events are flushed first without flushing all preceding events. I could write a filesystem that only touches the disc every 30 minutes (given sufficient memory) and still be able to preserve this simple basic expectation.
The bug does NOT exist in Ext3 with its default mount options, because it saves data in ordered mode. That means that it will either flush everything to disk up to a certain point in time (meta data and data alike) or nothing at all.
The problem with Ext4 is that they decided it would be a good idea to have 2 time lines. One for meta-data, and one for other data. It's possible those two are NOT in sync (as in, meta-data has been flushed up to point X in time, while data only has been flushed until point Y in time). Since meta-data is usually tiny in comparison to actual data, I don't even see why they would do this. Just donot flush meta-data until you have to actually flush real data as well. Problem solved.
Furthermore, if you indeed did change all applications to call fsync() when needed, performance of Ext4 would be worse than current Ext3 performance in ordered mode.
That's nice, it's a good thing I can hear apostrophes when someone speaks english...
So... the ISP's are at fault. They should simply refuse, until a law comes into existance, at which point it will be the governments fault.
In any sane country, yellow light time is solely determined by the maximum allowed speed on the road the light is installed on. It's determined by reaction time, stopping distance and the maximum speed.
So, google, yahoo, msn, etc.. blocked in australia yet? I hear they all link to child porn.
Exactly, my only "promotion" path was towards a management job. I don't want to stop programming, ever (if I can help it). So instead I checked my options (after 8 years of solid service), found that the company did not want to actually reward my performance better, so I quit. I work freelance now, and can safely say that it is far more rewarding in more than one sense.
Unfortunately, in the world of software development, a less brilliant programmer will also have less foresight or not have a proper grasp of complexities involved with multiple users, multiple threads, or anything else that involves scaling up an application to serve thousands instead of just him/herself when debugging it.
A brilliant programmer can not only write code faster, they can do it with less bugs, more foresight, using better algorithms and more often than not produce something that is easier to maintain/configure/extend later on as well. The end result is often an order of magnitude better than what an average programmer produces. Unfortunately, management rarely realizes how big a difference it can make on the bottom line, and rarely will these people be actually paid a salary that is an order of magnitude higher (certainly not more than their "manager"...)
The hit by the bus argument does not fly. It may take a while to figure it out, but there are people that can figure it out.
When practically the entire senior programmer team quit on the spot at a company I used to work for (I was one of the ones that quit), I figured they'd be in a lot of trouble, as quite a lot of the code written was never even seen by the ones that remained. Yet, they're thriving. They brought in some young talent and raised wages for the remaining team, and they're doing just fine. Yes, it did wake the company up (teams were restructured, wages raised, programmers actually got a say in things) and there were some problems with the next release cycle, but they're doing fine again.
That's the easy part. Walking the list could be done using a binary search algorithm, but that wasn't even the complex part. To determine the biggest X second difference in a set of values that spawn 300 seconds, you could do this (X = intervalInMillis):
That's the simple, inaccurate, slow version. Inaccurate because it only checks steps of 100 ms, slow because it calls "getValueAtTime" very often. Increase the accuracy or the size of the period to search, and it gets even slower. It however works 99% correct and is easy to understand.
The complex version took me quite a while to wrap my mind around, not to mention a lot of unit testing and comparing it with the "simple" version to make sure it really performed correctly (there's quite a few of nasty edge cases). It's also about 4-5 times more lines of code involving temporary data structures, and pretty much impossible to follow without a big comment to explain the algorithm used (I'm not even sure if there's a standard algorithm for it). It however scales far better when huge number of values are involved.
I hate excessive simplicity for the sake of clarity, this just tells me it was written FOR people that cannot be bothered to learn the language they're using. A place I worked at was actually considering banning certain practices that are part of the language, like multiple returns, ?: conditionals, regular expressions, fall-through cases, and so on. That's all nice and dandy, until those dumbed down programmers need to debug some framework they're using and donot understand what some rarely used operator does. Let alone having them work on threading problems or figuring why a garbage collected language is running out of memory.
If they cannot figure out a piece of complex, badly formatted piece of garbage code, then what hope is there they can debug real problems.
Way too verbose for me. If there's one thing I hate, it's variables being declared and assigned, and then only used once. Add a comment if you want to make it clearer, but please no "isThereASolarEclipseSomewhereInTheNextCentury" fields/methods.
No, that is not what I'm asking.
I'm asking that when the filesystem does a sync (or commit or whatever you want to call it), that it commits EVERYTHING up to a point, not half. There's still plenty of room to reorder writes within those limits. For example, if I have 500 operations, and the filesystem is required to sync, then it can reorder those 500 operations all it wants. As long as when it's done, all of them are committed (or none). Not all of them except #399 cause it didn't like that one.
Totally agree. When the filesystem syncs, it must sync everything up to a certain point in time, and nothing after that point. If it doesn't, then you can end up with situations where steps that occurred earlier are not committed while later steps are. I wrote a journaled filesystem myself long ago, and even using a high commit interval it atleast would not mess with the order that events occurred.
(with formatting this time)
-o sync is overkill.
A filesystem should respect the order of commands given to it. I don't care when it syncs, as long as there's no gaps in things I told it to do. Syncing later steps before having synced steps before it is ludicrous. Either sync them all in the same big batch or none at all. Syncing just half of them at random is gonna wreak havoc.
So, to put it more clearly:
OpenTempFile -> Write -> CloseTempFile -> RenameTempFileOverOriginal should never result in: OpenTempFile -> CloseTempFile -> RenameTempFileOverOriginal.
During a bad crash, I accept that the contents of one of these files may become corrupted, as writes may have been done in place and it would be excessive to have to log all content to the journal as well. I however donot accept that this can happen to dozens of files at the same time because the filesystem decided to sync future actions before syncing earlier steps.
-o sync is overkill. A filesystem should respect the order of commands given to it. I don't care when it syncs, as long as there's no gaps in things I told it to do. Syncing later steps before having synced steps before it is ludicrous. Either sync them all in the same big batch or none at all. Syncing just half of them at random is gonna wreak havoc. So, to put it more clearly: OpenTempFile -> Write -> CloseTempFile -> RenameTempFileOverOriginal should never result in: OpenTempFile -> CloseTempFile -> RenameTempFileOverOriginal. During a bad crash, I accept that the contents of one of these files may become corrupted, as writes may have been done in place and it would be excessive to have to log all content to the journal as well. I however donot accept that this can happen to dozens of files at the same time because the filesystem decided to sync future actions before syncing earlier steps.
That's all nice and stuff, but IMHO filesystems should atleast preserve the order of actions it syncs. So I don't care that when I do A, B, C, D and then E that I could end up with A + B + C or even just A, or nothing at all, that's fine.
However, ending up with something like:
A + D + E
seems to be highly undesirable. If the filesystem decides to a sync on its own, it should atleast sync everything up to a certain point in time, not pick and choose whatever happens to be handy. Most filesystems in fact do this, and the only thing they donot guarantee is that actual content *during* a sync is 100% safe (which means you only corrupt a file that was being written at the time crash). EXT4 seems to take it to a new level and will sync meta-data ahead of time without even attempting to write out the data that was part of earlier steps...
POSIX may allow it, but I was under the impression that filesystems should try and remain in a sane state. That means if my application does A, B, C and then D, that I expect the following to be on disk no matter what happens, either:
1) Nothing
2) A
3) A + B
4) A + B + C
5) A + B + C + D
It seems that EXT4 will deem that some of these are not as equal as others (if C for example is a data write), and can give you a new result like:
6) A + B + D
That's certainly unexpected, and highly undesirable if D happens to be something like "delete backup file" or a rename over an old file.
5 seconds seemed reasonable. 2.5 minutes does not. I have serious doubts that this will have much performance benefits at all. Furthermore, the performance benefits are likely to evaporate when used on SSD's, which are likely to become popular soon.
Even though you may wish that all applications treated filesystems as a transactional database, the reality is that almost none do, unless they actually are implementing a transactional database.
Most flatscreens I seen can't do a proper "black". Sure it looks great in the brightly lit store, but once you bring it home, and want to enjoy a nice movie in a dark room, suddenly every black is dark gray, making the picture look washed out. The funny bit is when I tell people this, they will tell me that their flatscreen has a 1:10000 contrast ratio or some such tripe... what they don't know is that this ratio is based on different images, not in the same image.
Dancing hamster? Where can I get!?!?
..and this is why I donot understand they censor their own forums. If I want to talk about the issue, I can do so anyway, elsewhere.
I was about to say the same thing. The drummer probably hears the effect, and just syncs to that consciously or subconsciously. I've done some drumming, and I know that I can and will be swayed by other effects if they're consistent and close enough to the tempo I want to play.