Re:Classic tech support advise!
on
Apple's First Flops
·
· Score: 2, Informative
Yah, it would. Cray's of the time were running a 10ns (100 Mhz) clock. We usually assumed speed-of-electricity in copper at about 1 ft/ns. Cray's are big machines and you can get pretty close to the edge of signal propogation so lopping off a few inches of wire here and there could and does tune things. Don't forget that you need to get everything done in 10 ft of wire (minus how ever many gates it went through on the way) or your signal shows up late.
Half a liter is a small spill? I don't think so! That's about half a Big Gulp. That would have had Coke everywhere in your keyboard and spilling out the sides. A small spill is more like a couple of cc's.
This is a really good point. School security is never going to be tight. Period. And would you really want to be a student or a teacher in a well secured HS? However, if you're going to have lousy security then you should make sure that you don't have anything worth stealing or that will cause problems for people if it's stolen.
I respect the folks who resigned. I read Fuat's interview and just couldn't believe that anyone who is involved in any form of journalism just couldn't get what was wrong with O'Gara's article.
But what the hell *is* LinuxWorld? All the folks who resigned were apparently unpaid?? Does anyone besides Fuat make any money for their work? Why would anyone give their time for free to such a tool? I've never really looked at the site prior to this flamefest so I don't have a good feeling for what the heck it is. Was it a useful interesting magazine? If so, why wouldn't they pay their people?
Leave the write caching on and make sure you have a backup. If you don't have any backups your data can't be that important:-). If it's really important, you might want to track down whether your drive does the right thing, or plop down a few more bucks and run SCSI drives or a (quality) RAID subsystem.
I don't think anyone is really after O'Gara for trying to find PJ and have a face-to-face with her. The article (have you read the article?) is just crap, though, with lots of ad-hominem attacks, speculation, innuendo and addresses of people who may or may not be PJ and no real information of any kind. It reads like something an 8th grader would write after they got told off on-line.
Bull crap. There's a big difference between opening yourself for lawsuits and being a tool. He goes well beyond being cautios. For example, he says that the only reason he pulled the story was because there was a DOS attack against his servers. He could have just said "In my judgement the story was reasonable but many of our readers and other staffers disagreed so we chose to remove it". If anything, he's really opened himself for a lawsuit by publicly endorsing O'Gara's invasion of privacy and stalking rather than disavowing it as a mistake she made that slipped through the system.
Ben Goodger has hit on one of the major ways that "free" software can fail and that is that the people working on the project are doing so out of the goodness of their hearts and for their own reasons. Some developers, like Goodger probably, are writing free software for the kick of having as many people use it as possible. This will make them somewhat use oriented. Others, and the KHTML guys appear to be this, are writing code for the sheer joy of writing code. And it's not fun to write stuff that cuts corners just so you can get it out the door. Of course, you may not be meeting the users' needs. But then, there's no requirement to meet users' needs. It's free - if you don't like it, fix it yourself or don't use it. In this case, Apple chose to fix it themselves. The fact that they diverged from KHTML simply shows that they have different priorities and isn't any different than FreeBSD and NetBSD spliiting.
I was trying to think of how to put this and of course, after I posted, I got my thoughts straight. It's something I've worked with long enough that it's intuitive to me, but perhaps a bit tricky to explain so bear with me here.
A priori, we have no way of knowing whether a particular write will complete or not. Therefore, any data consistency scheme which relies on predicting that a particular write will complete won't work. Instead, we have to have consistency schemes that rely on knowing that a particular write has completed.
What does this mean? Say you disable the write cache on a drive. Does this mean that you can be guaranteed that every write you start will complete properly? No. There are too many things to go wrong. The sector you're writing to might be bad, the power might turn off in the middle of the write, the controller might go belly up in the middle of the write, etc. All the you can rely on (provided everything is designed and implemented properly) is that when a write completes the data is really on disk.
Write caching is just an extension of this. Once you turn write caching on your guarantee that things are on disk is the completion of the flush command, not the completion of a write. This is very valuable because most transactions involve multiple writes. In fact, in a sophisticated protocol, like SCSI, rather than flushing the whole cache, you can tag a particular write and get the guarantee "when this write completes, all of your previous writes have completed". This gives you much better performance than constantly flushing the cache.
A journaling file system will know when it needs to get everything committed to disk in order to have a consistent state. At that point it will issue a sync to the drive to flush the drive's write cache. However, not every write has to get to the disk for the filesystem to be in a consistent state.
Now, you're yelling BS, BS, BS...hold on and listen for a minute. I write file systems for a living and have done so for over 15 years.
What is the commitment that a journaling file system makes to you? It makes the commitment that it will not be in an inconsistent state. It doesn't make the commitment that every last write will make it to disk. For example, ext3 in journaling mode only journals metadata transactions. Any data writes that you make are not guaranteed at all, unless you make the proper sync call. As someone pointed out above, fsync is not the proper call on many OS's.
The way that we have settled on to make filesystems and databases work is to create atomic transactions and move from transaction to transaction. If a transaction fails (for any reason, but let's just assume it's because the system crashed), all of the data that was written as part of it is discarded when you restart. If the partial data was not discarded then the filesystem would be in an inconsistent state AND the data that you were writing (if you care about consistency) would be in an inconsistent state. So, forcing every write to immediately go to disk is pointless as if the transaction you're doing is interrupted you'll be discarding the data anyway. It's only when you are finishing the transaction that you need to make sure that everything is on disk. By that time it might be already, especially if that transaction was large.
Let's take a simple situation. Say that you have a filesystem that guarantees that everytime you do a write() call, when the call returns that data will be on disk and available for you the next time and that if the write() errors or does not return, the file will be as it was before the write() was called. Now, you do a write of 100MB with a single call. The filesystem may scatter that data all over the disk depending on how fragmented it is. Forcing each write to disk in order will bang the head a lot and reduce your performance. By letting the write cache do its job and reorder writes as necessary your performance will be much better (we used to do this in the driver and file system cache. However, modern disk drives provided such an abstract interface that it's nearly impossible for the OS to micromanage write ordering. In the old days the OS knew where the head is because it told the damn drive where to put it. Now, you can sort of guess and you're usually wrong). Cache on ATA drives tops out at around 16MB so you will definitely flush most of the data out of the cache in the course of writing anyway. Finally, at the end, before returning, the FS would sync the drive's cache to the disks and mark the transaction as closed. Were the system to crash in the middle of the write when the system restarts it would need to discard any data that might have been written and it wouldn't matter which data had been written or not written. (Important note: Journaling file systems and databases have a recovery process after a crash. It's just a lot less involved than running fsck or DSKCHK over the whole disk)
So, write caching is valuable and widely used. In order to avoid data corruption it's not necessary to turn off caching but it is necessary for the cache to do what it is told, when it is told (all of the write caches too, not just the disk's). Were the disks truly lying to the OS it would be bad. More likely, this guy's Perl script is just not OS specific enough to get the OS to really do what he thinks he is asking it to do. There's a reason why serious data management apps need to be ported and certified on an OS. Getting everything to do its job right is tough.
He's correct, vis-a-vis Newton. This was not a Newton, though - this was a Mac Powerbook in tablet form. It would have been sold at the Mac pricepoint, not the Newton pricepoint. Probably the hand writing recognition never worked well enough and it wasn't feasible at the time to make a keyboard that you could stow out of the way in tablet mode.
Apple actually built a prototype Mac (System 7) tablet back in the mid-90's. They got as far as the "prototype" plastics being made and did a small run for internal testing (maybe a couple of dozen?). I saw some in use in the Tokyo office in '96 where they were being used to test the (Japanese language) handwriting recognition software. They were sturdy enough for day to day use and were left in the lunchroom for employees to use (the idea was to get lots of input with different people's handwriting styles). I don't recall why the project was killed then.
Pracically speaking, the legalities would only matter if you were threatened by the RIAA and had enough resources to fight them in court rather than paying them a settlement.
Were you to be making a copy of the records you own, the law seems to be pretty clear on that point - you're allowed to make a backup copy. Once you get beyond that, the actual legalities are pretty fuzzy. One of the problems is that "copyright" focuses on the right to "copy". Looking back a hundred years this made sense. Copying a book by hand is not really feasible. Make a single copy of a book using a printing press is not cost-effective. So, if you were copying materials you were probably doing it on a commercial scale and trying to make a profit which is pretty clearly against both the letter and spirit of copyright.
What did you buy when you bought those records? Did you buy a piece of vinyl that you can do anything with afterwards (such as resell, loan)? Or did you purchase a license to a certain song and the vinyl was merely the distribution media? I don't think there's a clear answer. Certainly records have been treated as the former ever since we've had records. The record companies have recently become schizoid in their attitudes favoring one interpretation or the other depending on the restriction they're trying to put on you to make more money. And, in all fairness, we (customers) tend to favor one or the other depending on if it matches what we want to do at the moment.
In your case, what's fair and ethical? My opinion would be that if you're downloading digitized versions of your records that would be fair. However, if you're downloading the same songs that had been ripped from CD's that doesn't seem fair. After all, they usually remaster music for CD release. That takes a fair amount of work. If you want people to do that work you have to give them an incentive somehow.
I don't think it's the right system but at least in France they stuck it back to the media companies who keep trying to double and triple dip. Unfortunately these schemes are usually terrible at actually distributing money to the artists who are supposed to get it.
I think the so-called "looks over the shoulder" the Windows camp gives OS X are largely mythical. Apple's relevance is very small in the grander scheme of things, is it not?
Perhaps. However, MS' OS developers may not be watching OS X but I wouldn't be surprised if there's a lot of influence from Mac OS pre X and Copland. After the death of Copland and the takeover of Apple by Jobs and the NeXT crew, many of the Copland core OS developers wound up working for Microsoft. I know that some of the features that started showing up in Windows 2000 looked a lot like the stuff that was going into Copland.
They were lucky to be in a position that their OS is bundled with 95% of computers, and streamlined their office suite in behind it. They cross-subsidized their game console with the takings from their OS and office suite monopolies.
There should be a button somewhere on the/. screen that automatically inserts this post.
Slashdot Mirror
Your English was fine. It was quite clear.
Yah, it would. Cray's of the time were running a 10ns (100 Mhz) clock. We usually assumed speed-of-electricity in copper at about 1 ft/ns. Cray's are big machines and you can get pretty close to the edge of signal propogation so lopping off a few inches of wire here and there could and does tune things. Don't forget that you need to get everything done in 10 ft of wire (minus how ever many gates it went through on the way) or your signal shows up late.
Half a liter is a small spill? I don't think so! That's about half a Big Gulp. That would have had Coke everywhere in your keyboard and spilling out the sides. A small spill is more like a couple of cc's.
This is a really good point. School security is never going to be tight. Period. And would you really want to be a student or a teacher in a well secured HS? However, if you're going to have lousy security then you should make sure that you don't have anything worth stealing or that will cause problems for people if it's stolen.
They need lightsabers because lightsabers are bad ass. Star Wars wouldn't be nearly as much fun without them. Do remember that it's a movie.
If you can remember how to spell "midicholri-whatever" you need to move out of your parents' basement.
I respect the folks who resigned. I read Fuat's interview and just couldn't believe that anyone who is involved in any form of journalism just couldn't get what was wrong with O'Gara's article.
But what the hell *is* LinuxWorld? All the folks who resigned were apparently unpaid?? Does anyone besides Fuat make any money for their work? Why would anyone give their time for free to such a tool? I've never really looked at the site prior to this flamefest so I don't have a good feeling for what the heck it is. Was it a useful interesting magazine? If so, why wouldn't they pay their people?
Leave the write caching on and make sure you have a backup. If you don't have any backups your data can't be that important :-). If it's really important, you might want to track down whether your drive does the right thing, or plop down a few more bucks and run SCSI drives or a (quality) RAID subsystem.
I don't think anyone is really after O'Gara for trying to find PJ and have a face-to-face with her. The article (have you read the article?) is just crap, though, with lots of ad-hominem attacks, speculation, innuendo and addresses of people who may or may not be PJ and no real information of any kind. It reads like something an 8th grader would write after they got told off on-line.
Bull crap. There's a big difference between opening yourself for lawsuits and being a tool. He goes well beyond being cautios. For example, he says that the only reason he pulled the story was because there was a DOS attack against his servers. He could have just said "In my judgement the story was reasonable but many of our readers and other staffers disagreed so we chose to remove it". If anything, he's really opened himself for a lawsuit by publicly endorsing O'Gara's invasion of privacy and stalking rather than disavowing it as a mistake she made that slipped through the system.
Ben Goodger has hit on one of the major ways that "free" software can fail and that is that the people working on the project are doing so out of the goodness of their hearts and for their own reasons. Some developers, like Goodger probably, are writing free software for the kick of having as many people use it as possible. This will make them somewhat use oriented. Others, and the KHTML guys appear to be this, are writing code for the sheer joy of writing code. And it's not fun to write stuff that cuts corners just so you can get it out the door. Of course, you may not be meeting the users' needs. But then, there's no requirement to meet users' needs. It's free - if you don't like it, fix it yourself or don't use it. In this case, Apple chose to fix it themselves. The fact that they diverged from KHTML simply shows that they have different priorities and isn't any different than FreeBSD and NetBSD spliiting.
Hmmm...seems like Webcore is still fast and might be small at the expense of being completely clean.
I was trying to think of how to put this and of course, after I posted, I got my thoughts straight. It's something I've worked with long enough that it's intuitive to me, but perhaps a bit tricky to explain so bear with me here.
A priori, we have no way of knowing whether a particular write will complete or not. Therefore, any data consistency scheme which relies on predicting that a particular write will complete won't work. Instead, we have to have consistency schemes that rely on knowing that a particular write has completed.
What does this mean? Say you disable the write cache on a drive. Does this mean that you can be guaranteed that every write you start will complete properly? No. There are too many things to go wrong. The sector you're writing to might be bad, the power might turn off in the middle of the write, the controller might go belly up in the middle of the write, etc. All the you can rely on (provided everything is designed and implemented properly) is that when a write completes the data is really on disk.
Write caching is just an extension of this. Once you turn write caching on your guarantee that things are on disk is the completion of the flush command, not the completion of a write. This is very valuable because most transactions involve multiple writes. In fact, in a sophisticated protocol, like SCSI, rather than flushing the whole cache, you can tag a particular write and get the guarantee "when this write completes, all of your previous writes have completed". This gives you much better performance than constantly flushing the cache.
Let's try a reply with a bit less flame attached.
A journaling file system will know when it needs to get everything committed to disk in order to have a consistent state. At that point it will issue a sync to the drive to flush the drive's write cache. However, not every write has to get to the disk for the filesystem to be in a consistent state.
Now, you're yelling BS, BS, BS...hold on and listen for a minute. I write file systems for a living and have done so for over 15 years.
What is the commitment that a journaling file system makes to you? It makes the commitment that it will not be in an inconsistent state. It doesn't make the commitment that every last write will make it to disk. For example, ext3 in journaling mode only journals metadata transactions. Any data writes that you make are not guaranteed at all, unless you make the proper sync call. As someone pointed out above, fsync is not the proper call on many OS's.
The way that we have settled on to make filesystems and databases work is to create atomic transactions and move from transaction to transaction. If a transaction fails (for any reason, but let's just assume it's because the system crashed), all of the data that was written as part of it is discarded when you restart. If the partial data was not discarded then the filesystem would be in an inconsistent state AND the data that you were writing (if you care about consistency) would be in an inconsistent state. So, forcing every write to immediately go to disk is pointless as if the transaction you're doing is interrupted you'll be discarding the data anyway. It's only when you are finishing the transaction that you need to make sure that everything is on disk. By that time it might be already, especially if that transaction was large.
Let's take a simple situation. Say that you have a filesystem that guarantees that everytime you do a write() call, when the call returns that data will be on disk and available for you the next time and that if the write() errors or does not return, the file will be as it was before the write() was called. Now, you do a write of 100MB with a single call. The filesystem may scatter that data all over the disk depending on how fragmented it is. Forcing each write to disk in order will bang the head a lot and reduce your performance. By letting the write cache do its job and reorder writes as necessary your performance will be much better (we used to do this in the driver and file system cache. However, modern disk drives provided such an abstract interface that it's nearly impossible for the OS to micromanage write ordering. In the old days the OS knew where the head is because it told the damn drive where to put it. Now, you can sort of guess and you're usually wrong). Cache on ATA drives tops out at around 16MB so you will definitely flush most of the data out of the cache in the course of writing anyway. Finally, at the end, before returning, the FS would sync the drive's cache to the disks and mark the transaction as closed. Were the system to crash in the middle of the write when the system restarts it would need to discard any data that might have been written and it wouldn't matter which data had been written or not written. (Important note: Journaling file systems and databases have a recovery process after a crash. It's just a lot less involved than running fsck or DSKCHK over the whole disk)
So, write caching is valuable and widely used. In order to avoid data corruption it's not necessary to turn off caching but it is necessary for the cache to do what it is told, when it is told (all of the write caches too, not just the disk's). Were the disks truly lying to the OS it would be bad. More likely, this guy's Perl script is just not OS specific enough to get the OS to really do what he thinks he is asking it to do. There's a reason why serious data management apps need to be ported and certified on an OS. Getting everything to do its job right is tough.
Single /.'ers are probably the only ones getting less than us married folks.
For fuck's sake:
Exactly!
He's correct, vis-a-vis Newton. This was not a Newton, though - this was a Mac Powerbook in tablet form. It would have been sold at the Mac pricepoint, not the Newton pricepoint. Probably the hand writing recognition never worked well enough and it wasn't feasible at the time to make a keyboard that you could stow out of the way in tablet mode.
Apple actually built a prototype Mac (System 7) tablet back in the mid-90's. They got as far as the "prototype" plastics being made and did a small run for internal testing (maybe a couple of dozen?). I saw some in use in the Tokyo office in '96 where they were being used to test the (Japanese language) handwriting recognition software. They were sturdy enough for day to day use and were left in the lunchroom for employees to use (the idea was to get lots of input with different people's handwriting styles). I don't recall why the project was killed then.
Laugh all you like - these people are in control of a major nuclear arsenal.
Pracically speaking, the legalities would only matter if you were threatened by the RIAA and had enough resources to fight them in court rather than paying them a settlement.
Were you to be making a copy of the records you own, the law seems to be pretty clear on that point - you're allowed to make a backup copy. Once you get beyond that, the actual legalities are pretty fuzzy. One of the problems is that "copyright" focuses on the right to "copy". Looking back a hundred years this made sense. Copying a book by hand is not really feasible. Make a single copy of a book using a printing press is not cost-effective. So, if you were copying materials you were probably doing it on a commercial scale and trying to make a profit which is pretty clearly against both the letter and spirit of copyright.
What did you buy when you bought those records? Did you buy a piece of vinyl that you can do anything with afterwards (such as resell, loan)? Or did you purchase a license to a certain song and the vinyl was merely the distribution media? I don't think there's a clear answer. Certainly records have been treated as the former ever since we've had records. The record companies have recently become schizoid in their attitudes favoring one interpretation or the other depending on the restriction they're trying to put on you to make more money. And, in all fairness, we (customers) tend to favor one or the other depending on if it matches what we want to do at the moment.
In your case, what's fair and ethical? My opinion would be that if you're downloading digitized versions of your records that would be fair. However, if you're downloading the same songs that had been ripped from CD's that doesn't seem fair. After all, they usually remaster music for CD release. That takes a fair amount of work. If you want people to do that work you have to give them an incentive somehow.
No, he said that you have a right to copy material that you borrow from someone else. There was a recent court ruling in France that made P2P sharing legal if you had bought media and paid the media tax.
I don't think it's the right system but at least in France they stuck it back to the media companies who keep trying to double and triple dip. Unfortunately these schemes are usually terrible at actually distributing money to the artists who are supposed to get it.
I think the so-called "looks over the shoulder" the Windows camp gives OS X are largely mythical. Apple's relevance is very small in the grander scheme of things, is it not?
Perhaps. However, MS' OS developers may not be watching OS X but I wouldn't be surprised if there's a lot of influence from Mac OS pre X and Copland. After the death of Copland and the takeover of Apple by Jobs and the NeXT crew, many of the Copland core OS developers wound up working for Microsoft. I know that some of the features that started showing up in Windows 2000 looked a lot like the stuff that was going into Copland.
1994 called and they want their irony back (I think that's when Apple & IBM formed the PowerPC alliance)
My kids will get all of the personal liberty and privacy they want when I am no longer responsible for their behavior (that is, after they turn 18).
They were lucky to be in a position that their OS is bundled with 95% of computers, and streamlined their office suite in behind it. They cross-subsidized their game console with the takings from their OS and office suite monopolies.
/. screen that automatically inserts this post.
There should be a button somewhere on the