Yes they could. Filtering would actually help prevent it since the images would be blocked. Not blocking but prosecuting those that look at it would make the spamming attack work. I really don't think that the people that want to block some media are actually evil. I think they really do want to help. They be mistaken but I think that most of them actually think that they are helping.
You know I was one of the people that believed that the EXT4 people where correct. Now with this data I have to say they blew it. Yep it meets Posix but I would say that in this case Posix isn't good enough. They need to fix EXT4 or we could just use JFS, XFS, or Ext3 until this gets fixed.
"Are there any specific products that Sun sells that IBM doesn't have equivalents of? Sun has some good products" Yes OpenOffice and Java. Too bad IBM didn't buy Troll Tech as well. I think IBM still has so anger issues with Microsoft. I could see them really pushing for a Microsoft free stack from top to bottom even if it was FOSS. IBM makes a lot of money from services. A free stack just means more services to sell. I wonder if they will buy Opera next. Imagine Solaris, KDE, Openoffice, and Opera all rolled into a nice Free distro:)
Your incorrect. I would love to have a world without kiddie porn sites. At best the censorship will prevent a few people that want to go to those sites getting there. Do you have any idea how many people have almost no technical knowledge at all? It could prevent some people from going there my mistake. Most rules like this make honest people honest. Honestly most people that want censorship fall into two categories. One the people that really want to protect kids or people that want too look like they are doing something good with little effort. None of them really are out to create 1984.
Well I would say that just leaving them up would be bordering on entrapment. It wouldn't be hard for somebody to spam people with HTML Email with links back to those sites. Most people don't turn off the images in email like I do. If a site is illegal in a certain country for some reason and that country decided to block it then that list should be made public. Keeping the list secret is just wrong. Every site that is blocked should have a reason that it is blocked and they type of content that is on it. If you are going to block it the let people know why.
I thought it was 75% myself since I remember my science teacher saying that in like third grade. That was back when we rode our dinosaurs to school.
Actually your correct but the thing is that way to many people forget the science they had learned because they never really need it. Of course I have seen such silly stuff here on Slashdot that I doubt that it is restricted to joe six pack.
Your nuts. Very few programmers are any good at grammar. Spelling doesn't matter as long as you spell it the same way very time. Just run iDocSz in your spell checker some time.
Well as for how much overhead I would have to say that it would be too much for what you gain. If you really want ACID then use a database that is what they are for. In this case the programmer messed up on a few levels IMHO. First He should have written to a temp file and then called fsync. Then done a rename on the original to a.bak and then renamed the temp. Second he should have had sanity checks on the data in the file. If the data fails the sanity checks then you fall back to your bak file. Third if the bak fails sanity checks then you use some safe defaults and all the user to reconfigure. You really don't want an end user locked out of their GUI. What I find so interesting is the evolution of how we store data files. When I started programming we used to use text files for configuration. Then we found out that we could just write out blocks of memory containing data structures to a file. It was fast and it worked until something goes wrong. Now we have gone back to text/xml files because we can do sanity checks and prevent crashes. Plus it is easier to document and convert to new versions.
I have done a good amount of Web development. I used a good amount of file io for configuration and such. I am not fond of the set variables in the source file method of setting up configuration. Yes I know everybody uses it but I don't. But yes Web programing seems to tends to go with the MySQL as a file system replacement. If you want to call it a limitation well then fine except that EVERYTHING has some limitation. There is just no way that this can be blamed on the file system at all. The cause is simply in this case application programmer IQ error.
You did say it was a flaw. Not in that post but you did say it was. It has been a long time since I took my OS class but even then that is not how file systems worked. First file systems do work the way you want in a file handle. Once that handle is closed then if you are going to do anything else with that file you must call fsync. The reason is performance. Back in the day good filesystems used was is called elevator seaking. The head of the drive would travel up and down the drive like an elevator. If the writes and reads where always sequential that poor drive head would be darting all over the place and the drive performance would be terrible. How you could add a check that before any new operation was done that That a check was made and an fsync is called if needed. The problem with that is that check would be called thousands or even millions times for no good reason just to allow a programmer to not make a call to fsync. It isn't worth it and it is documented. Trust me the exact same issue can happen on many file systems and it is up to programmers to read the docs and follow them. I can not imagine writhing a lot of software without every having to do disk io even if it just to save configuration information.
That is a bad assumption. It isn't the way Posix works. It is documented and easy to work around. After every write, close, and any other disk operation in your program call fsync() as documented. Heck even under DOS you couldn't be sure that the file was written until you called close.
No. That is why we have fsync(). No file system will promise you data integrity with a power failure. That is why you should run with a UPS. You can not depend on the write delay time. What happens if you get a really fast processor and say a really slow drive? Unless you are building software that only runs on ONE set of hardware you just can not do that. This is a bug that was always in KDE and they got lucky up till now.
"It most definitely is a filesystem limitation. That is different from saying that it's the filesystem's fault. " Funny that isn't what you said. "Blaming it on the applications is a cop-out. The filesystem is flawed, plain and simple. "
But to use your airplane analogy. If you fill the planes tanks with water then ram it into a brick wall and it doesn't come out the other side without scratching the paint then that is a limitation. The problem is that to make a file system work the way you want it to you would pay a big price in performance to make up for programmer incompetence.
I did. I just don't understand how you could call a developers competent and not expect them to read documentation of the file system calls they are using. I am not the greatest developer of all times but I know how fsync works. Everybody makes mistakes but this was 100% the mistake of the application programmer that didn't call fsync. It was and is in no way a problem with or a limitation of the file system. Maybe competent means something different your language than in English.
It isn't a file system limitation. And here is why. 1. The POSIX standard specifies that writes may be delayed. Every modern file system may delay writes. 2. The POSIX standard then gives you a way to flush the buffer at the time of the programs choosing. It is called fsync(). If the programmer called that well documented function then all would have been well. You have the best performance possible and you can insure that file is flushed before you do something else. The file system didn't cause this bug. The posix spec didn't cause this bug. The programmer that didn't use the tools as documented caused his own bug.
"I was simply saying that not all "competent developers" are aware of this situation." And you would be totally wrong. This is the way Posix works. If you are making Posix calls then you better know how they work. If you really think it should handled by the interpreter or compiler then you should then feel the bug is in the compiler or interpreter but not in the filesystem. But no the developers that use a language that DOESN'T document that IO is synced and doesn't use the library calls to do that sync is incompetent.
Well for one thing this IS part of the language. I don't think there is a single clib that doesn't have fsync but I could be wrong. Second then BLAME your language. If the langauge is supposed to work that way then they should code it so every write and close function also does and fsync. If you are making calls to the API or using a library YES YOU BLOODY WELL SHOULD KNOW HOW THEY WORK. And what does any of this have to do with knowing assembly?
It isn't a flaw. It is documented and the programmers didn't follow the docs. There is a specific command called fsync to flush the buffers to prevent the problem. In fact here is a link to that call http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html
Yes if we had a prefect world we would have instant IO but we do not. The flaw is in the application plan and simple. They didn't use the api properly and it really is just that simple.
The simple answer is because Active X is basically a singed windows executable that gets downloaded and then run in the browser. It is pretty much dependent on the Windows API and was never really designed to be run in a sandbox. You can run Active X under Linux if you get Wine and IE under Wine working. So yes it doesn't have too run only under windows.. But it really is just a terrible security plan from top to bottom.
Same in the US. The gov even gets notified if you make too big of a deposit. Mainly for tax reasons but then taxes is how they often bust Mafia members here. No tin foil for me. I really don't care if the government knows how many WiFi routers, USB drives, or case fans I buy. The only thing that bugs me is the cost of all that tracking. It really just doesn't bug me. Next time I will work harder on the silliness level of my post so as too not miss lead the few people on Slashdot that still have their sanity.
Slashdot Mirror
Yes they could. Filtering would actually help prevent it since the images would be blocked. Not blocking but prosecuting those that look at it would make the spamming attack work.
I really don't think that the people that want to block some media are actually evil. I think they really do want to help.
They be mistaken but I think that most of them actually think that they are helping.
You know I was one of the people that believed that the EXT4 people where correct. Now with this data I have to say they blew it. Yep it meets Posix but I would say that in this case Posix isn't good enough. They need to fix EXT4 or we could just use JFS, XFS, or Ext3 until this gets fixed.
But IBM can not own Linux, Gnome, or Firefox.
Solaris has ZFS and really is a pretty nice OS.
"Are there any specific products that Sun sells that IBM doesn't have equivalents of? Sun has some good products" :)
Yes OpenOffice and Java.
Too bad IBM didn't buy Troll Tech as well.
I think IBM still has so anger issues with Microsoft. I could see them really pushing for a Microsoft free stack from top to bottom even if it was FOSS. IBM makes a lot of money from services. A free stack just means more services to sell.
I wonder if they will buy Opera next.
Imagine Solaris, KDE, Openoffice, and Opera all rolled into a nice Free distro
Nice idea. Maybe they will include you, your parents, grandparents, or less technical friends as well?
Really that is just so nice.
Your incorrect. I would love to have a world without kiddie porn sites. At best the censorship will prevent a few people that want to go to those sites getting there. Do you have any idea how many people have almost no technical knowledge at all? It could prevent some people from going there my mistake. Most rules like this make honest people honest.
Honestly most people that want censorship fall into two categories. One the people that really want to protect kids or people that want too look like they are doing something good with little effort. None of them really are out to create 1984.
Well I would say that just leaving them up would be bordering on entrapment.
It wouldn't be hard for somebody to spam people with HTML Email with links back to those sites. Most people don't turn off the images in email like I do.
If a site is illegal in a certain country for some reason and that country decided to block it then that list should be made public.
Keeping the list secret is just wrong.
Every site that is blocked should have a reason that it is blocked and they type of content that is on it. If you are going to block it the let people know why.
I thought it was 75% myself since I remember my science teacher saying that in like third grade. That was back when we rode our dinosaurs to school.
Actually your correct but the thing is that way to many people forget the science they had learned because they never really need it.
Of course I have seen such silly stuff here on Slashdot that I doubt that it is restricted to joe six pack.
Your nuts.
Very few programmers are any good at grammar. Spelling doesn't matter as long as you spell it the same way very time.
Just run iDocSz in your spell checker some time.
Well as for how much overhead I would have to say that it would be too much for what you gain. .bak and then renamed the temp.
If you really want ACID then use a database that is what they are for.
In this case the programmer messed up on a few levels IMHO.
First He should have written to a temp file and then called fsync. Then done a rename on the original to a
Second he should have had sanity checks on the data in the file. If the data fails the sanity checks then you fall back to your bak file.
Third if the bak fails sanity checks then you use some safe defaults and all the user to reconfigure.
You really don't want an end user locked out of their GUI.
What I find so interesting is the evolution of how we store data files.
When I started programming we used to use text files for configuration. Then we found out that we could just write out blocks of memory containing data structures to a file. It was fast and it worked until something goes wrong.
Now we have gone back to text/xml files because we can do sanity checks and prevent crashes. Plus it is easier to document and convert to new versions.
I have done a good amount of Web development. I used a good amount of file io for configuration and such. I am not fond of the set variables in the source file method of setting up configuration. Yes I know everybody uses it but I don't. But yes Web programing seems to tends to go with the MySQL as a file system replacement.
If you want to call it a limitation well then fine except that EVERYTHING has some limitation. There is just no way that this can be blamed on the file system at all. The cause is simply in this case application programmer IQ error.
You did say it was a flaw. Not in that post but you did say it was. It has been a long time since I took my OS class but even then that is not how file systems worked.
First file systems do work the way you want in a file handle. Once that handle is closed then if you are going to do anything else with that file you must call fsync.
The reason is performance. Back in the day good filesystems used was is called elevator seaking. The head of the drive would travel up and down the drive like an elevator. If the writes and reads where always sequential that poor drive head would be darting all over the place and the drive performance would be terrible.
How you could add a check that before any new operation was done that That a check was made and an fsync is called if needed. The problem with that is that check would be called thousands or even millions times for no good reason just to allow a programmer to not make a call to fsync.
It isn't worth it and it is documented.
Trust me the exact same issue can happen on many file systems and it is up to programmers to read the docs and follow them.
I can not imagine writhing a lot of software without every having to do disk io even if it just to save configuration information.
That is a bad assumption. It isn't the way Posix works. It is documented and easy to work around.
After every write, close, and any other disk operation in your program call fsync() as documented.
Heck even under DOS you couldn't be sure that the file was written until you called close.
No. That is why we have fsync().
No file system will promise you data integrity with a power failure. That is why you should run with a UPS.
You can not depend on the write delay time. What happens if you get a really fast processor and say a really slow drive? Unless you are building software that only runs on ONE set of hardware you just can not do that.
This is a bug that was always in KDE and they got lucky up till now.
Just use fsync()
Problem solved. Read the Posix docs, or the clib docs and you will never run into this problem.
"It most definitely is a filesystem limitation. That is different from saying that it's the filesystem's fault. "
Funny that isn't what you said.
"Blaming it on the applications is a cop-out. The filesystem is flawed, plain and simple. "
But to use your airplane analogy. If you fill the planes tanks with water then ram it into a brick wall and it doesn't come out the other side without scratching the paint then that is a limitation.
The problem is that to make a file system work the way you want it to you would pay a big price in performance to make up for programmer incompetence.
I did. I just don't understand how you could call a developers competent and not expect them to read documentation of the file system calls they are using.
I am not the greatest developer of all times but I know how fsync works. Everybody makes mistakes but this was 100% the mistake of the application programmer that didn't call fsync. It was and is in no way a problem with or a limitation of the file system.
Maybe competent means something different your language than in English.
It isn't a file system limitation. And here is why.
1. The POSIX standard specifies that writes may be delayed. Every modern file system may delay writes.
2. The POSIX standard then gives you a way to flush the buffer at the time of the programs choosing. It is called fsync(). If the programmer called that well documented function then all would have been well.
You have the best performance possible and you can insure that file is flushed before you do something else.
The file system didn't cause this bug. The posix spec didn't cause this bug. The programmer that didn't use the tools as documented caused his own bug.
"I was simply saying that not all "competent developers" are aware of this situation."
And you would be totally wrong.
This is the way Posix works. If you are making Posix calls then you better know how they work. If you really think it should handled by the interpreter or compiler then you should then feel the bug is in the compiler or interpreter but not in the filesystem.
But no the developers that use a language that DOESN'T document that IO is synced and doesn't use the library calls to do that sync is incompetent.
Well for one thing this IS part of the language. I don't think there is a single clib that doesn't have fsync but I could be wrong.
Second then BLAME your language. If the langauge is supposed to work that way then they should code it so every write and close function also does and fsync.
If you are making calls to the API or using a library YES YOU BLOODY WELL SHOULD KNOW HOW THEY WORK.
And what does any of this have to do with knowing assembly?
It isn't a flaw. It is documented and the programmers didn't follow the docs. There is a specific command called fsync to flush the buffers to prevent the problem.
In fact here is a link to that call http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html
Yes if we had a prefect world we would have instant IO but we do not. The flaw is in the application plan and simple.
They didn't use the api properly and it really is just that simple.
How about a new AppleTV?
The 10" screen would be a display/ control panel for the device.
The simple answer is because Active X is basically a singed windows executable that gets downloaded and then run in the browser.
It is pretty much dependent on the Windows API and was never really designed to be run in a sandbox.
You can run Active X under Linux if you get Wine and IE under Wine working. So yes it doesn't have too run only under windows.. But it really is just a terrible security plan from top to bottom.
Same in the US. The gov even gets notified if you make too big of a deposit. Mainly for tax reasons but then taxes is how they often bust Mafia members here.
No tin foil for me. I really don't care if the government knows how many WiFi routers, USB drives, or case fans I buy. The only thing that bugs me is the cost of all that tracking. It really just doesn't bug me.
Next time I will work harder on the silliness level of my post so as too not miss lead the few people on Slashdot that still have their sanity.
Ewww. I am now convinced.
Really post some facts or even some opinions instead of insults.