Exactly. Unix is built around the process model, where forking is common. People do things with the command line a ton, piping output between programs, so process creation time is more important there than under a typical Windows workload, where programs tend to do more. (I'm not trying to place a value judgment on this; each approach has advantages and disadvantages. I tend to think that the Unix approach is better for command line manipulation, and the Windows approach of monolithic processes are better if you're using a GUI.) This means that different tasks are more tightly bound on Windows than they are on Unix, and a shared-memory approach is perhaps more natural for such things if the interaction is higher.
I would have been very interested to see the Windows thread creation time on there as well. I thought the same thing when I first saw the numbers.
Besides, XP and Server 2003 have the same architecture and use almost the same kernel. Server 2003 could start processes four times faster than XP (what I suspect is a very liberal assumption) and it would still be almost twice as slow as Linux.
It's a lot more expensive. Some numbers MSR came up with while working on their research OS Singularity put process creation on Linux at ~700,000 cycles, just over 1 million on FreeBSD, and just under 5.4 million cycles on XP. Here's one source; slide 23.
I'm not arguing against your main point; I'm just pointing out that there is actually a huge difference between process creation time on the different systems.
Appeals aren't decided by juries. In fact, they are almost entirely to decide legal questions and procedural questions; an appeals court more or less doesn't redecide a jury's finding of fact.
If the appeals court decides, for instance, that the trial judge was wrong in the instructions to the jury in a material way, the case could be retried, but the retrial itself isn't the appeal.
If you rear-end someone, 99% of the time it's your fault.
You can be sitting at a stoplight behind someone, get rear-ended, and pushed into the person in front of you, and I think that the law still says that it's your fault.
The system it's running on. When on Windows, it should use Windows controls. When on OS X, it should use OS X controls. When on Unix... well, that's a sticky case. Ideally it would use either Gnome or KDE controls, but this isn't really realistic to expect, so pick one.
There are frameworks that will do this for the most part.
Should they use MFC?
Who cares? The comments about widgets is from the end user perspective. Windows API, MFC,.Net; they all boil down to the same things in the end.
And don't SATA drives typically have better than 100MB/s write speeds?
That seems fast to me (copying one drive to another maxed out at about 40 MB/s, but I had an older SATA drive so maybe newer ones are faster), but that's for sustained transfer. If you're doing stuff like metadata operations, which are all journaled, it looks more like "write a journal block saying you're updating this bit of metadata, seek to the inode or indirect block you're modifying and write it, seek back to the journal and write a commit message". IRL these are batched, so the overhead isn't horrible, but there is still plenty of seeking involved.
In fact, ideally the drives would ensure that streaming writes don't push out the metadata from the flash cache.
That said, letting the drive run slower and stuff for longer life and better power consumption is very attractive. I don't actually know what exactly their goal is.
What if the band isn't interested in making all the money that it can, but wants to give everyone a chance to go to a concert even if they can't afford a $150 ticket?
Should they not do that? (or have to put on enough other concerts to bring the supply way up)
So instead of the public paying exorbitant prices to the scalpers, the band/distributors become the "scalpers" and the public pays exorbitant prices to them!
(Okay, so this is being deliberately inflammatory. At least some of the money is going to the band, which is far better than scalpers, so this is a good thing. But if you ask most people, the biggest issue with scalping isn't who gets the money, it's that it makes tickets extremely expensive. And auctions do nothing to help, and even some to hurt, that.)
Hey, wait your saying that Microsoft is not only fixing their own problems, but are also fixing crappy products other companies make?
MS doing this the main reason for a lot of Windows's problems.
They have so much crap to deal with from crummy programs that it'd blow your mind. And for the most part, they all still work, right down to most old DOS programs.
Raymond Chen talks about this a lot in his blog. Example. Or did you know that Windows 95 -- what should have been 4.0 -- reported it was 3.95, because saying 4.0 would have broken hundreds of programs?
MS is no stranger to fixing other people's broken code... in fact, they are probably the best in the business at it. It's only unfortunate that they are less good at fixing their own.
I don't have anything meaningful to add to this conversation, but I would just like to say that I find the juxtaposition of your post and signature amusing: Perhaps it's your grammar? -- You'll have that sometimes.
Except that it's perfectly reasonable to assume that someone on Vista might be using DX9. (Maybe they only have a DX9 capable graphics card for instance.) It's not reasonable to assume that you would drive a car on railroad tracks.
Since you seem to know something about ZFS, here's a question:
One of the issues with extended attributes is that they are easily destroyed on a Unixish system. (This isn't a problem on Windows perhaps somewhat by accident and through a big hack that happens to help a lot.) If you modify a file and save it in, for instance, either Vi or Emacs, at least under ext3 it will kill any extended attributes associated with the file.
The reason it does this is because the system calls made by Emacs are something along the lines of "move(foo.txt, foo.txt~)", "open(foo.txt, O_CREAT)". In other words, after you save foo.txt, the foo.txt that now exists is a/different/ foo.txt from what existed before.
Does ZFS do anything to address this problem?
(FWIW, on Windows, if you make a series of API calls similar to that so a new file is created with the same name as one that was just deleted, if it happens within 15 seconds the metadata is kept from the old file. This was essential in the land of Win95's long file names back when people still used DOS programs. Imagine editing "c:\some file with long name.txt" in a non-LFN-aware application, saving it, and now having your file called "c:\somefi~1.txt". Ewww! So they needed a way to keep the file name past that save. I said it was a hack.;-))
Resource forks are far better than the idiotic "everything is a folder" model.
Want to upload that Keynote project to your friendly CMS via a web browser? Can't, because it's not a file, it's a #@$!ing FOLDER. You have to zip it first
Personally, I'm not a MacOS user so don't know excatly what you're talking about, but from what I've heard about this I think the "everything is a folder" model is a really good idea. I said in another post a couple up that I wish that we were free to innovate without worrying about backwards compatibility and that one of the things I would like to see change is better metadata support, and this is at least very similar to the best model I've come up with for how to handle it. (Reiser4 does something fairly similiar.)
It just sounds like it's implemented wrong on MacOS. For instance, you could have "file-folder aware" applications and "file-folder unaware" applications, distinguished by the API they use or a flag they pass to open or something like that, and if your web browser doesn't explicitly say "I want the folder view" it will automatically zip it during the read calls. Keynote can then use open_folder and get the contents as a directory.
(Of course, there may be consequences of this that I haven't thought of.)
Even NTFS have these features but MS seems to ignore them due to backwards compatability issues with FAT filsystems and Windows APIs They are starting to do some stuff with them. The first major use I know of was with XP SP2. With that, when you downloaded a file from the internet, IE would mark it as such in an alternate stream. When the program was run, someone (I don't know who) would check for the presence of the stream and if it was there, would display a "this program came from an untrusted source, would you like to run it?" dialog.
I would expect more uses as we move into the future, as Vista is pushing even heavier for NTFS (for instance, IIRC the installer didn't ask which file system I wanted to use and just formatted NTFS), and MS doesn't have to worry about, for instance, some 98 or ME user who upgraded to XP but is still running FAT so he didn't have to reformat. For my large partitions (~100 GB), I can't format as anything but NTFS. (I don't know about smaller ones; I have a 24 GB system partition but if I try to bring up the format dialog there it complains that I'm trying to reformat the drive with the OS and I don't want to do that.)
Personally, I think that there's a lot of awesome stuff that you could use extended attributes and alternate streams (WHY are these separate concepts on some file systems?!) if only they would be preserved when you move stuff around systems, upload them, etc., and am somewhat resentful at Unix and POSIX for the fact that for ages they didn't do this stuff and hence it's really hard to move to using them because no one supports them because there's no demand because people haven't thought of what to do with them because they haven't seen what can be done with them because no one uses them because no one supports them because...:-) I've often wondered what operating systems would be like if we kept the knowledge of the last decades, but threw out everything that we had now and started from scratch without worry of backwards compatibility, and this is one of the things I would like to see change.
Oh, and there's a huge error in the test methodology. Both DirectX-es were tested on Vista. Try repeating the test with DX9 on XP and measure the performance...
I disagree that this is a huge error in methodology. I think that XP+DX9 would have made useful supplements to the results they gave, but their goal was to measure DX9 vs DX10, and you don't do that by changing two variables.
Vista + DX10 vs. XP + DX9 would have been an appropriate test for serious gamers who make their choice of OS based upon the version of DX10, but I suspect these people are a small minority even of those reading the review.
If you raise the image window, you're usually going to want the tools window, the layers window, etc. This may be less true for photo manipulation where you're doing levels and such, but it's still way more true than it is for Epiphany.
Remember, I'm not complaining about the fact that the window manager doesn't raise the windows, I'm complaining about the fact that there are separate windows.
It's even worse... at least the last time I tried it, raising one window doesn't raise them all. So if you switch to a web browser or something and go back to the Gimp, you have to manually raise all the windows (or minimize the web browser and anything else).
(The same is true on KDE or Gnome, but there it's easier to compensate because they all support multiple desktops well. It's still obnoxious and I feel I shouldn't have to devote a whole virtual desktop to one program to make it usable, but it's at least a workaround.)
Slashdot Mirror
Exactly. Unix is built around the process model, where forking is common. People do things with the command line a ton, piping output between programs, so process creation time is more important there than under a typical Windows workload, where programs tend to do more. (I'm not trying to place a value judgment on this; each approach has advantages and disadvantages. I tend to think that the Unix approach is better for command line manipulation, and the Windows approach of monolithic processes are better if you're using a GUI.) This means that different tasks are more tightly bound on Windows than they are on Unix, and a shared-memory approach is perhaps more natural for such things if the interaction is higher.
I would have been very interested to see the Windows thread creation time on there as well. I thought the same thing when I first saw the numbers.
I didn't do the comparison, m'kay?
Besides, XP and Server 2003 have the same architecture and use almost the same kernel. Server 2003 could start processes four times faster than XP (what I suspect is a very liberal assumption) and it would still be almost twice as slow as Linux.
I think it is somewhat more expensive...
It's a lot more expensive. Some numbers MSR came up with while working on their research OS Singularity put process creation on Linux at ~700,000 cycles, just over 1 million on FreeBSD, and just under 5.4 million cycles on XP. Here's one source; slide 23.
I'm not arguing against your main point; I'm just pointing out that there is actually a huge difference between process creation time on the different systems.
Appeals aren't decided by juries. In fact, they are almost entirely to decide legal questions and procedural questions; an appeals court more or less doesn't redecide a jury's finding of fact.
If the appeals court decides, for instance, that the trial judge was wrong in the instructions to the jury in a material way, the case could be retried, but the retrial itself isn't the appeal.
If you rear-end someone, 99% of the time it's your fault.
You can be sitting at a stoplight behind someone, get rear-ended, and pushed into the person in front of you, and I think that the law still says that it's your fault.
Native to what?
.Net; they all boil down to the same things in the end.
The system it's running on. When on Windows, it should use Windows controls. When on OS X, it should use OS X controls. When on Unix... well, that's a sticky case. Ideally it would use either Gnome or KDE controls, but this isn't really realistic to expect, so pick one.
There are frameworks that will do this for the most part.
Should they use MFC?
Who cares? The comments about widgets is from the end user perspective. Windows API, MFC,
You so deserve both funny mods and karma for that
You can't use DRAM for write caching; you can use flash for write caching.
The wearing out of flash is greatly overstated.
And don't SATA drives typically have better than 100MB/s write speeds?
That seems fast to me (copying one drive to another maxed out at about 40 MB/s, but I had an older SATA drive so maybe newer ones are faster), but that's for sustained transfer. If you're doing stuff like metadata operations, which are all journaled, it looks more like "write a journal block saying you're updating this bit of metadata, seek to the inode or indirect block you're modifying and write it, seek back to the journal and write a commit message". IRL these are batched, so the overhead isn't horrible, but there is still plenty of seeking involved.
In fact, ideally the drives would ensure that streaming writes don't push out the metadata from the flash cache.
That said, letting the drive run slower and stuff for longer life and better power consumption is very attractive. I don't actually know what exactly their goal is.
What if the band isn't interested in making all the money that it can, but wants to give everyone a chance to go to a concert even if they can't afford a $150 ticket?
Should they not do that? (or have to put on enough other concerts to bring the supply way up)
If they lose, sanity prevails.
But if they win, it provides precedent to sue anyone driving by with their car stereo too loud, so at least we get something out of the mess.
You wouldn't have to make sure the poor are first in line, just that they have an equal shot. For instance, a lottery system.
Besides, I think you're taking way too narrow a view of "help" than you should.
Great idea!
So instead of the public paying exorbitant prices to the scalpers, the band/distributors become the "scalpers" and the public pays exorbitant prices to them!
(Okay, so this is being deliberately inflammatory. At least some of the money is going to the band, which is far better than scalpers, so this is a good thing. But if you ask most people, the biggest issue with scalping isn't who gets the money, it's that it makes tickets extremely expensive. And auctions do nothing to help, and even some to hurt, that.)
Keeping prices below market rate is bad for everyone.
It's good for the people who get tickets who couldn't afford them if they were at "market rate".
Hey, wait your saying that Microsoft is not only fixing their own problems, but are also fixing crappy products other companies make?
MS doing this the main reason for a lot of Windows's problems.
They have so much crap to deal with from crummy programs that it'd blow your mind. And for the most part, they all still work, right down to most old DOS programs.
Raymond Chen talks about this a lot in his blog. Example. Or did you know that Windows 95 -- what should have been 4.0 -- reported it was 3.95, because saying 4.0 would have broken hundreds of programs?
MS is no stranger to fixing other people's broken code... in fact, they are probably the best in the business at it. It's only unfortunate that they are less good at fixing their own.
I don't have anything meaningful to add to this conversation, but I would just like to say that I find the juxtaposition of your post and signature amusing:
Perhaps it's your grammar?
--
You'll have that sometimes.
Except that it's perfectly reasonable to assume that someone on Vista might be using DX9. (Maybe they only have a DX9 capable graphics card for instance.) It's not reasonable to assume that you would drive a car on railroad tracks.
Since you seem to know something about ZFS, here's a question:
/different/ foo.txt from what existed before.
;-))
One of the issues with extended attributes is that they are easily destroyed on a Unixish system. (This isn't a problem on Windows perhaps somewhat by accident and through a big hack that happens to help a lot.) If you modify a file and save it in, for instance, either Vi or Emacs, at least under ext3 it will kill any extended attributes associated with the file.
The reason it does this is because the system calls made by Emacs are something along the lines of "move(foo.txt, foo.txt~)", "open(foo.txt, O_CREAT)". In other words, after you save foo.txt, the foo.txt that now exists is a
Does ZFS do anything to address this problem?
(FWIW, on Windows, if you make a series of API calls similar to that so a new file is created with the same name as one that was just deleted, if it happens within 15 seconds the metadata is kept from the old file. This was essential in the land of Win95's long file names back when people still used DOS programs. Imagine editing "c:\some file with long name.txt" in a non-LFN-aware application, saving it, and now having your file called "c:\somefi~1.txt". Ewww! So they needed a way to keep the file name past that save. I said it was a hack.
Resource forks are far better than the idiotic "everything is a folder" model.
Want to upload that Keynote project to your friendly CMS via a web browser? Can't, because it's not a file, it's a #@$!ing FOLDER. You have to zip it first
Personally, I'm not a MacOS user so don't know excatly what you're talking about, but from what I've heard about this I think the "everything is a folder" model is a really good idea. I said in another post a couple up that I wish that we were free to innovate without worrying about backwards compatibility and that one of the things I would like to see change is better metadata support, and this is at least very similar to the best model I've come up with for how to handle it. (Reiser4 does something fairly similiar.)
It just sounds like it's implemented wrong on MacOS. For instance, you could have "file-folder aware" applications and "file-folder unaware" applications, distinguished by the API they use or a flag they pass to open or something like that, and if your web browser doesn't explicitly say "I want the folder view" it will automatically zip it during the read calls. Keynote can then use open_folder and get the contents as a directory.
(Of course, there may be consequences of this that I haven't thought of.)
Even NTFS have these features but MS seems to ignore them due to backwards compatability issues with FAT filsystems and Windows APIs
:-) I've often wondered what operating systems would be like if we kept the knowledge of the last decades, but threw out everything that we had now and started from scratch without worry of backwards compatibility, and this is one of the things I would like to see change.
They are starting to do some stuff with them. The first major use I know of was with XP SP2. With that, when you downloaded a file from the internet, IE would mark it as such in an alternate stream. When the program was run, someone (I don't know who) would check for the presence of the stream and if it was there, would display a "this program came from an untrusted source, would you like to run it?" dialog.
I would expect more uses as we move into the future, as Vista is pushing even heavier for NTFS (for instance, IIRC the installer didn't ask which file system I wanted to use and just formatted NTFS), and MS doesn't have to worry about, for instance, some 98 or ME user who upgraded to XP but is still running FAT so he didn't have to reformat. For my large partitions (~100 GB), I can't format as anything but NTFS. (I don't know about smaller ones; I have a 24 GB system partition but if I try to bring up the format dialog there it complains that I'm trying to reformat the drive with the OS and I don't want to do that.)
Personally, I think that there's a lot of awesome stuff that you could use extended attributes and alternate streams (WHY are these separate concepts on some file systems?!) if only they would be preserved when you move stuff around systems, upload them, etc., and am somewhat resentful at Unix and POSIX for the fact that for ages they didn't do this stuff and hence it's really hard to move to using them because no one supports them because there's no demand because people haven't thought of what to do with them because they haven't seen what can be done with them because no one uses them because no one supports them because...
except for "Call of Juarez" which uses a completely different set of textures and settings, so it's an apples-to-oranges comparison.
No, this is an apples-to-oranges comparison.
(Sorry.)
Oh, and there's a huge error in the test methodology. Both DirectX-es were tested on Vista. Try repeating the test with DX9 on XP and measure the performance...
I disagree that this is a huge error in methodology. I think that XP+DX9 would have made useful supplements to the results they gave, but their goal was to measure DX9 vs DX10, and you don't do that by changing two variables.
Vista + DX10 vs. XP + DX9 would have been an appropriate test for serious gamers who make their choice of OS based upon the version of DX10, but I suspect these people are a small minority even of those reading the review.
Yes, but how often do you want that to happen?
If you raise the image window, you're usually going to want the tools window, the layers window, etc. This may be less true for photo manipulation where you're doing levels and such, but it's still way more true than it is for Epiphany.
Remember, I'm not complaining about the fact that the window manager doesn't raise the windows, I'm complaining about the fact that there are separate windows.
I've watched the videos that go with the SICP book, and learned quite a bit from them.
I'm sure I would have gotten more out of actually taking the class, but the videos alone were still helpful.
It's even worse... at least the last time I tried it, raising one window doesn't raise them all. So if you switch to a web browser or something and go back to the Gimp, you have to manually raise all the windows (or minimize the web browser and anything else).
(The same is true on KDE or Gnome, but there it's easier to compensate because they all support multiple desktops well. It's still obnoxious and I feel I shouldn't have to devote a whole virtual desktop to one program to make it usable, but it's at least a workaround.)
How 'bout... "shared source"?
Oh hey, that's what they're actually calling it. What a coincidence.