Shells have to load programs to be useful - programs like "ls", for example. And the loading of those programs is something not handled by the shell. It's handled by the kernel's exec() call. Now, granted you could make a shell do all sorts of funky things with "fork" to deal with it's own memory, but unless you re-write the entire workings of "exec" in the kernel, you still have to drop down to the kernel's exec behavior, which will throw your fork'd program's memory away and replace it with the loaded executable, and it will not grab that memory from memory your shell owns.
Maybe you could have your shell free a bunch of memroy at the line right before the exec(), and then hope that this memory will be eaten by your exec() instead of by some other process, but that's just wishfully hoping you can predict the results of a race condition.
A third party must do the checksumming, and comparing the checksum must be part of the job of the poll worker turning the machine on at the start of the day. (Imagine if the checksum program was on a boot floppy that was not part of the software provided by the vendor - the checksummer would be programmed by the elections board or a group they contract out to. Then you use the checksummer on the code that you put under scrutiny and "bless", and publish that checksum to the polling workers. They stick the boot floppy in the machine and it tells them a checksum there too - then they just compare that to the published "blessed" checksum. If they are the same number, the machine is good. If not, the machine is "broken".
Making the checksum be calculated by a third party means the only way the vendor could trick out the checksum is to hope that they can find a change to the code that just so happens to result in the exact same checksum, while simultaneously skewing the results they way they want. That's going to be an exceedingly unlikely possibility - while there are a large number of possible binaries that yield the same checksum, the chance that one of them is actually something useful to the vendor is so close to nil as to be ignorable.
The solution is to use a checksum of the code in the following fashion:
Rule 1 - The voting hardware and OS must be rather uniform, with only a few variations for regional preferences (it wouldn't be fair to force a small precinct to be forced to buy an overpowered version intended for high-volume voting places, therefore there would be a few different configurations available, but the number of allowed combinations of hardware and software must be discrete and small in number, not something where you can just put together whatever parts you want all willy-nilly.)
Rule 2 - The entirety of the machine, including the OS and the voting software on top of it, must all be considered a single 'thing' for the sake of verification. (i.e. if you have a third party verify a setup, then that setup is verified ONLY on that exact configuration. For a second configuration of hardware, a seperate verification is needed.)
Rule 3 - When a third party verifies that the system is good, they take a checksum of *everything* including the OS. (basically, do a checksum of the root directory, recursively descending everything under it.)
Rule 4 - The list of checksums of verified systems is given to voting poll station workers. When the system turns on, the first thing you do is run an automated checksummer on it (from a boot floppy or something like that, which is external to the machine itself and removable - and therefore is not part of the system itself, and is produced by different people entirely). When it spits its number out, compare that against the list of known "good" checksums. If it's on that list, the machine is safe and can be used. If it's not, then this fact must be logged, and a call must be made to the elections board, and the machine must not be used that election day (and must be inspected later when there's time to see what the problem is and determine if something untoward was being attempted.)
I'm picturing that the list of known "good" checksums would only have 5 or so numbers on it. Basicly, it's a mechanism to allow for upgrades and improvements or to allow for a few different hardware configuration options for different sized polling precincts.
The problem with BASIC isn't BASIC. It's that people try to use it for more than it is. As a quick and dirty intro to what programming is like, it's great. But a lot of people try using it for more than that.
I can remember back in high school in the '80s. We had a cruddy class in programming basic called "Structured Basic". It was taught on Apple II's (I was used to the more powerful Commodore 64 editing system for basic and this was frustrating.) Anyway, the problem was that the teacher (and the textbook) insisted upon trying to teach students that there was one and only one right way to write a particular type of thing. What they were doing (although I didn't know it at the time) was trying to limit the students to only knowing how to write programs that mimiced the control structures of high level languages. The only "right" way to write a counting loop was to start with an initialization line, then second to have a conditional test line that GOTO's to the line following the loop body, and then the loop body, and then the last line of the loop body should increment the counter, then unconditionally GOTO to the check condition line. It looks extremely ugly in BASIC, and not the slightest bit structured, but what it was - was an exact duplication of the for( a,;b;c ) looping ability of higher level languages. It looked like this in BASIC:
10 I = 1
20 IF( I > 10) THEN GOTO 60
30...loop body...
40 I = I + 1
50 GOTO 20
60...next line after the loop...
It makes sense ONLY if you know about the "for (A;B;C)" construct and realize this is an attempt to mimic it in a language that just doesn't do things that way. Without exposure to that, it looks dumb. (And even with exposure to that it looks dumb because you've multiplied your GOTO's needlessly, and even at that young age I saw the problem in that - the more links you make from one line number to another, the harder it is to move code around.) This left a false sensation (for me) that "people who want me to write well structured code are idiots who don't know how to program". This persisted for some time because they kept trying to pigeonhole high level concepts into a language in which using that construct not only makes things take a little more time, but also makes things look ulgier. When they tried to claim this way is "easier", my reaction was "what a load of bullsh.. I can do this in a way that's simpler, and easier to understand, and faster to write." And at the time, since we were using old BASIC, this was very true. In higher level languages, it starts to become true that taking longer to write the code, with a few more lines, can make it more sensible. But with that style of old BASIC, that's just not true yet.
Nowadays, they've added a lot of high level constructs to BASIC that make it a little better, but people still have the problem of trying to do more with it than it's good for - like gluing object-oriented stuff on it.
Basically, what I'm trying to say is don't make the mistake of trying to teach a concept in a language that's too simplistic for it - it gives the student the incorrect feeling that that concept is painful and should be avoided.
Despite the brainwashing of the public that Microsoft did back in the days of their NT server and workstation distributions, you shouldn't have to buy an entirely different distribution of the OS just to change a few parameter settings.
It should be something you can change in the sysconfig, just like how many locks there are, or any of the other similar settings that are related to server versus workstation tweaking.
Rendering software doesn't really depend much on the gui interface. It does all the work "in it's head" - dumping the result to files - maybe showing something on the screen to help the user follow along and know how far its gotten, but the real results are on disk.
Now, *Modelling* software, on the other hand, does depend a lot on the GUI - but that's not really the kind of software I had in mind, and it's not what Pixar excells at - for that they can use the same sort of off-the-shelf stuff everyone else uses.
Admittedly, there are some things that can be proven non-existant, but to do it the search space has to be reasonably finite. The sharks with lasers in my bathtub are disprovable only because it is possible to make an exhaustive search of my bathtub, being that it is a reasonably finite search space. But now try proving that there are no shark-mounted lasers at all, anywhere in the universe...
That's usually the kind of question the grandparent poster was talking about - questions about what exists, without narrowing the search space to specify *where*.
Shouldn't the VM part of the kernel be able to "learn" the pattern of access to a file on the fly? Imagine if for each file there was a simple number stored in the kernel that remembers "this was the previous block that was loaded from the disk for this file", and another simple integer that represents "sequentialness". It starts at zero. Each time a new block has to be swapped in for that file, it notices if it is sequentially adjacent to the previous block (either forward or backward). If so, it increments the "sequentialness" counter by one. If not it decrements it by one. This counter then becomes a heuristic for how sequential the access to that file is. If it's a large positive number, then that means that that file has tended to be accessed in a very sequential fashion. If it's a large negative number, then that means that file has been accessed in a very random fashion.
This number could then be used to change the score when the VM's deciding which page to swap from memory. A disk block for a highly sequentially accessed file should be swapped out even if it's not that old yet - it should become a candidate much sooner than a page for a random-access file or a page for program code or program data.
That would solve the "watching a long movie file" problem, without the programmer having to do anything special. The cached disk blocks for a long movie file would end up with a very high "sequentialness" score, and thus be swapped out quickly.
It should be a globally settable thing by the admin, at runtime, but not something you have to set on a per-application, per-run basis - that gets tedious and most people won't bother, just like they don't bother with ulimits for the same reason. The admin should be able to say, "Since I want to use this machine as a file server, I'll set up the VM to score disk access high in the paging scheme. But that other computer over there is a workstation, so I'll set it up to score disk caching low in the paging scheme."
Basically, the decision on which page to evict from memory should be based on BOTH how long ago it was used, AND what it was used for, and which way to favor one over the other should be settable at runtime, not just compile time. (i.e. This is a file server so I will have the VM score disk cache pages the same way it scores program pages, giving them equal weight, but that machine over there is a workstation, so I will have it's VM score disk cache pages as "quadruple decay time" pages - meaning a disk cache gets "old" faster and is swapped out four times faster than a program's page would be.
The difference is that SMARTDRV didn't have the ability to degrade the performance of running programs by swapping their pages out. It only used memory that the apllication doesn't. The linux VM can go way overboard and use up too much of the ram for disk cache and not enough of it for programs. In my opinion (and granted, I'm not a kernel expert by any means), the VM should 'score' the use of a memory page for disk cache less than it scores the use of a memory page for program execution. So if two pages have both been used about 1 minute ago, but one was used for disk cache and one was used for program execution or data, then the disk cache page should be a candidate for swapping out first. The score shouldn't be based ONLY on the time since the last access. The score should take into account that a programmer writes a program *expecting* disk access to be slow and expecting RAM access to be fast. If the VM is making this not be the case, then the VM is doing something wrong.
Actually, what would be nice would be a way to reserve something like 1 or 2 percent of the RAM for the use of programs launched by one special rootlike user (user with uid 0, but not called 'root' - called something like "emergency" or something). This would be the safety net so that there was a way to do something about a system that was swapping like mad. The "emergency" user would always have a little sliver of actual ram guaranteed to exist for him and nobody else - for the purpose of logging in and running a shell and a few diagnostic commands. For a server environment where uptime is important, I'm sure a lot of sites would be willing to sacrifice the use of a few Mb of ram for this assurance, still leaving 98% of the system's ram for everything else.
Okay, so let's say you have X ram plus X swap. This means programs will die when you have 2*X memory used. How is this an improvement over having 2*X ram plus no swap, in which case programs will still die when you have 2*x memory used, but it will be over and done with faster, instead of being agonizingly slow while you are trying to root around finding the problem and being unable to get anywhere because it's taking over a minute to do a simple "ps aux".
People are speaking in terms of "I have X ram plus Y swap". For the sake of this question, look at it this way - you actually have X+Y amount of memory - but some of it is slow and some of it is fast. If there is a circumstance where this is an advantage over having X+Y of fast memory and none of the slow kind, then that means something is seriously wrong with the way the system is managing memory.
It's been my experience that by the time I notice a system is swapping like mad and therefore I should check to see if a process is eating too much memory, the performance is so terrible that my machine might as well have crashed altogether - at least then I could reboot, wait for fsck, and be back up and running, instead of it taking agonizingnly long to wait for the simplest of commands to finish while I try to discover the problem, and be frustrated that it's taking several minutes for a simple 'ps' command to run, and eventually I give up and reboot anyway.
The situation you speak of would only happen if a runaway process is eating memory *slowly* - slowly enough that you can start to detect a slowdown because of swap but still be able to use the system for a while before it gets really bad. That generally doesn't happen to me. Usually the onset of the memory eating is fast enough that by the time I notice, the system has already gone from usable to so slow I might as well reboot, and it only took a matter of less than 30 seconds to that state.
Re:Where many people miss the point...
on
Is Swap Necessary?
·
· Score: 1
How is it that a system with 256 M of Ram plus 256 M of swap is better than one with 512 M of Ram? This is what your argument favors, even if you don't realize it. No matter what level you set your swap to, it will always be a finite size. But the only way to solve the kinds of problems you talk of is to have infinite ram, and swap doesn't do that for you.
This is getting back to the original question in the article - if my system performed okay with X amount of Ram and X amount of swap, then it should perform just great with 2X amount of ram and no swap, assuming the usage of the machine is the same. Why use swap then if I can afford to double the RAM? I thought swap was just for the case where my usage can't fit in my RAM. And clearly it has already been proven that it fits in 2X megabytes if I was previously running with X ram plus X swap.
And the answers in the article astonished me. They seemed to be paraphrasing "the way the kernel uses ram is stupider than the way it uses swap, and therefore having some swap improves performance." If that's the case then something is really wrong with the design.
Re:they need updated docs for todays ram amounts
on
Is Swap Necessary?
·
· Score: 1
since/. still doesn't feature an edit button... ...people can't make revisionist modifications to things they said earlier in a debate. This is a good thing. Editing would only be good if it was disabled once someone says something that refers to your post. Checking for the use of the "reply" link doesn't work for this, because that still doesn't catch the case where someone replies obliquely to what you said in a post that was not a direct reply.
Basically, you can't unsay things in an in-person conversation, why do you want it in an on-line conversation? Yeah, I know in this case you just wanted to fix up some formatting, but slashcode doesn't know that, and can't know that.
If you're doing something where the formatting matters, then use the preview button.
caught the essence of the 19340s Futurists shouldn't really try to predict what things will be like 17 millenia from now. That is perhaps a bit of an overzelous attempt.
But there's a lot of people who think that a lack of existence is something that requires evidence, which is equally stupid, given that a lack of existence should be *expected* to leave behind to a lack of evidence. While it's true that a lack of evidence does not prove a lack of existence, it's also true that if you're looking for proof that nonexistant things are in fact nonexistant, then you're going about it all wrong in the first place.
The *ONLY* way you can ever say that a thing is nonexistant, is as a default starting hypothesis. Proof cannot sway you to that point if it's right, but it could sway you away from it if it's wrong.
Therefore it's a falsifiable hypothesis to state that a thing is assumed nonexistant by default until shown otherwise, and that's why it's a perfectly honest starting point to take nonexistence as the default hypothesis. In fact, it's the ONLY honest starting point.
To say otherwise is to believe in leprechauns and santa claus - which are also impossible to find evidence to prove are nonexistant.
Artists. They hire artists. Artists have an emotional attachment to Macs. Thus they'll get more familiarity with their new hires if they use Macs as opposed to linux, while at the same time retaining the ability to run all the same unixy rendering stuff they've been developing for ages.
Not too mention that the fossil records for Dinosaurs don't stop on 1 day.
As I understood it, the record doesn't have precise enough time resolution to tell. If they all died out in one day, or if they all died out in 10,000 years it would basically look about the same as far as our ability to pin down the dates of things.
Broil actually means that the heat source is above rather than below the food. The reason this is sometimes desirable is that it means the rack that the food sits on does not affect the surface of the food as much (the burn lines on the food) As hot air tends to rise more than fall, the heat setting has to be very high for a broil to work effectively. This incidental fact is why "broil" is label they put on the highest setting on the oven - it's because there's no much else you'd need that much heat for, NOT because broil just mean "hot".
And, actually, the highest setting I've seen on an oven is "clean", and "clean" does not equate to "high heat" either, in much the same way that "broil" doesn't.
Keep in mind that this isn't much of a move. It's more of a BSD move than a MacOS move. Pixar has been doing rendering on Unix since they first got started. The fact that a Unix now exists which is also an end-user consumer product is probably how they're viewing the move to OSX. Their move is really more of a "Compile our unix software to the version of BSD that's called OSX" as opposed to "Make this a Mac program."
Re:*Disney* came out ahead when they dumped Pixar
on
Welcome To Planet Pixar
·
· Score: 5, Insightful
It's a matter of if you prefer high-risk with high-yeilds or low-risk with low-yeilds. If Pixar continued its Disney deal, that would have meant Pixar wouldn't take the risk (as Disney would be doing the funding) but also Pixar would only see a tiny portion of the profits (as Disney would take most of that.)
So it's guaranteed minimal funding or risky gigantic profits. They chose the risky route. I believe the future will prove them right, as evidenced by the fact that all the talent in writing and animating these movies has been Pixar's work, not Disney's.
These days computer animations are everywhere. Pixar started it but they are no longer the only player in that market. But what they do have is better writing, and better in-jokes. They have been very successful at making movies that BOTH children and adults find entertaining (as opposed to typical Disney crap, where the adults are only bothering to go because their kids want to see it.) When Disney says "family movie" they really mean "children's movie." When Pixar says "family movie", they mean it.
Pixar will outlast Disney, precisely *because* they aren't afraid to take a risk when it's necessary (like this move was), while Disney is too conservative - preferring to follow established trends instead of starting them.
No, I'm not a Steve Jobs fan. I'm a Pixar fan, and have been since before I knew who the hell Jobs even was. I've been a fan since their animated short days, when I was using their Renderman(tm) software (a little bit) and going to animated film festivals and going ga-ga over seeing what they were doing with it. That's how I can tell they are where the creative talent was coming from, not Disney. Shorts like "Gerry's Game" and the mother-and-child desk lamps show all the same style of creative scripting as can be seen in Toy Story and Monsters Inc.
Slashdot Mirror
Shells have to load programs to be useful - programs like "ls", for example. And the loading of those programs is something not handled by the shell. It's handled by the kernel's exec() call. Now, granted you could make a shell do all sorts of funky things with "fork" to deal with it's own memory, but unless you re-write the entire workings of "exec" in the kernel, you still have to drop down to the kernel's exec behavior, which will throw your fork'd program's memory away and replace it with the loaded executable, and it will not grab that memory from memory your shell owns.
Maybe you could have your shell free a bunch of memroy at the line right before the exec(), and then hope that this memory will be eaten by your exec() instead of by some other process, but that's just wishfully hoping you can predict the results of a race condition.
A third party must do the checksumming, and comparing the checksum must be part of the job of the poll worker turning the machine on at the start of the day. (Imagine if the checksum program was on a boot floppy that was not part of the software provided by the vendor - the checksummer would be programmed by the elections board or a group they contract out to. Then you use the checksummer on the code that you put under scrutiny and "bless", and publish that checksum to the polling workers. They stick the boot floppy in the machine and it tells them a checksum there too - then they just compare that to the published "blessed" checksum. If they are the same number, the machine is good. If not, the machine is "broken".
Making the checksum be calculated by a third party means the only way the vendor could trick out the
checksum is to hope that they can find a change to the code that just so happens to result in the exact same checksum, while simultaneously skewing the results they way they want. That's going to be an exceedingly unlikely possibility - while there are a large number of possible binaries that yield the same checksum, the chance that one of them is actually something useful to the vendor is so close to nil as to be ignorable.
The solution is to use a checksum of the code in the following fashion:
Rule 1 - The voting hardware and OS must be rather uniform, with only a few variations for regional preferences (it wouldn't be fair to force a small precinct to be forced to buy an overpowered version intended for high-volume voting places, therefore there would be a few different configurations available, but the number of allowed combinations of hardware and software must be discrete and small in number, not something where you can just put together whatever parts you want all willy-nilly.)
Rule 2 - The entirety of the machine, including the OS and the voting software on top of it, must all be considered a single 'thing' for the sake of verification. (i.e. if you have a third party verify a setup, then that setup is verified ONLY on that exact configuration. For a second configuration of hardware, a seperate verification is needed.)
Rule 3 - When a third party verifies that the system is good, they take a checksum of *everything* including the OS. (basically, do a checksum of the root directory, recursively descending everything under it.)
Rule 4 - The list of checksums of verified systems is given to voting poll station workers. When the system turns on, the first thing you do is run an automated checksummer on it (from a boot floppy or something like that, which is external to the machine itself and removable - and therefore is not part of the system itself, and is produced by different people entirely). When it spits its number out, compare that against the list of known "good" checksums. If it's on that list, the machine is safe and can be used. If it's not, then this fact must be logged, and a call must be made to the elections board, and the machine must not be used that election day (and must be inspected later when there's time to see what the problem is and determine if something untoward was being attempted.)
I'm picturing that the list of known "good" checksums would only have 5 or so numbers on it. Basicly, it's a mechanism to allow for upgrades and improvements or to allow for a few different hardware configuration options for different sized polling precincts.
The problem with BASIC isn't BASIC. It's that people try to use it for more than it is. As a quick and dirty intro to what programming is like, it's great. But a lot of people try using it for more than that.
...loop body... ...next line after the loop...
I can remember back in high school in the '80s. We had a cruddy class in programming basic called "Structured Basic". It was taught on Apple II's (I was used to the more powerful Commodore 64 editing system for basic and this was frustrating.) Anyway, the problem was that the teacher (and the textbook) insisted upon trying to teach students that there was one and only one right way to write a particular type of thing. What they were doing (although I didn't know it at the time) was trying to limit the students to only knowing how to write programs that mimiced the control structures of high level languages. The only "right" way to write a counting loop was to start with an initialization line, then second to have a conditional test line that GOTO's to the line following the loop body, and then the loop body, and then the last line of the loop body should increment the counter, then unconditionally GOTO to the check condition line. It looks extremely ugly in BASIC, and not the slightest bit structured, but what it was - was an exact duplication of the for( a,;b;c ) looping ability of higher level languages. It looked like this in BASIC:
10 I = 1
20 IF( I > 10) THEN GOTO 60
30
40 I = I + 1
50 GOTO 20
60
It makes sense ONLY if you know about the "for (A;B;C)" construct and realize this is an attempt to mimic it in a language that just doesn't do things that way. Without exposure to that, it looks dumb. (And even with exposure to that it looks dumb because you've multiplied your GOTO's needlessly, and even at that young age I saw the problem in that - the more links you make from one line number to another, the harder it is to move code around.) This left a false sensation (for me) that "people who want me to write well structured code are idiots who don't know how to program". This persisted for some time because they kept trying to pigeonhole high level concepts into a language in which using that construct not only makes things take a little more time, but also makes things look ulgier. When they tried to claim this way is "easier", my reaction was "what a load of bullsh.. I can do this in a way that's simpler, and easier to understand, and faster to write." And at the time, since we were using old BASIC, this was very true. In higher level languages, it starts to become true that taking longer to write the code, with a few more lines, can make it more sensible. But with that style of old BASIC, that's just not true yet.
Nowadays, they've added a lot of high level constructs to BASIC that make it a little better, but people still have the problem of trying to do more with it than it's good for - like gluing object-oriented stuff on it.
Basically, what I'm trying to say is don't make the mistake of trying to teach a concept in a language that's too simplistic for it - it gives the student the incorrect feeling that that concept is painful and should be avoided.
Despite the brainwashing of the public that Microsoft did back in the days of their NT server and workstation distributions, you shouldn't have to buy an entirely different distribution of the OS just to change a few parameter settings.
It should be something you can change in the sysconfig, just like how many locks there are, or any of the other similar settings that are related to server versus workstation tweaking.
I invite you to prove to me you don't owe me $500.
When asking if something exists, putting the burden of proof on the party that says "no" is always wrong.
Rendering software doesn't really depend much on the gui interface. It does all the work "in it's head" - dumping the result to files - maybe showing something on the screen to help the user follow along and know how far its gotten, but the real results are on disk.
Now, *Modelling* software, on the other hand, does depend a lot on the GUI - but that's not really the kind of software I had in mind, and it's not what Pixar excells at - for that they can use the same sort of off-the-shelf stuff everyone else uses.
Admittedly, there are some things that can be proven non-existant, but to do it the search space has to be reasonably finite. The sharks with lasers in my bathtub are disprovable only because it is possible to make an exhaustive search of my bathtub, being that it is a reasonably finite search space. But now try proving that there are no shark-mounted lasers at all, anywhere in the universe...
That's usually the kind of question the grandparent poster was talking about - questions about what exists, without narrowing the search space to specify *where*.
Shouldn't the VM part of the kernel be able to "learn" the pattern of access to a file on the fly? Imagine if for each file there was a simple number stored in the kernel that remembers "this was the previous block that was loaded from the disk for this file", and another simple integer that represents "sequentialness". It starts at zero. Each time a new block has to be swapped in for that file, it notices if it is sequentially adjacent to the previous block (either forward or backward). If so, it increments the "sequentialness" counter by one. If not it decrements it by one. This counter then becomes a heuristic for how sequential the access to that file is. If it's a large positive number, then that means that that file has tended to be accessed in a very sequential fashion. If it's a large negative number, then that means that file has been accessed in a very random fashion.
This number could then be used to change the score when the VM's deciding which page to swap from memory. A disk block for a highly sequentially accessed file should be swapped out even if it's not that old yet - it should become a candidate much sooner than a page for a random-access file or a page for program code or program data.
That would solve the "watching a long movie file" problem, without the programmer having to do anything special. The cached disk blocks for a long movie file would end up with a very high "sequentialness" score, and thus be swapped out quickly.
It should be a globally settable thing by the admin, at runtime, but not something you have to set on a per-application, per-run basis - that gets tedious and most people won't bother, just like they don't bother with ulimits for the same reason. The admin should be able to say, "Since I want to use this machine as a file server, I'll set up the VM to score disk access high in the paging scheme. But that other computer over there is a workstation, so I'll set it up to score disk caching low in the paging scheme."
Basically, the decision on which page to evict from memory should be based on BOTH how long ago it was used, AND what it was used for, and which way to favor one over the other should be settable at runtime, not just compile time. (i.e. This is a file server so I will have the VM score disk cache pages the same way it scores program pages, giving them equal weight, but that machine over there is a workstation, so I will have it's VM score disk cache pages as "quadruple decay time" pages - meaning a disk cache gets "old" faster and is swapped out four times faster than a program's page would be.
The difference is that SMARTDRV didn't have the ability to degrade the performance of running programs by swapping their pages out. It only used memory that the apllication doesn't. The linux VM can go way overboard and use up too much of the ram for disk cache and not enough of it for programs. In my opinion (and granted, I'm not a kernel expert by any means), the VM should 'score' the use of a memory page for disk cache less than it scores the use of a memory page for program execution. So if two pages have both been used about 1 minute ago, but one was used for disk cache and one was used for program execution or data, then the disk cache page should be a candidate for swapping out first. The score shouldn't be based ONLY on the time since the last access. The score should take into account that a programmer writes a program *expecting* disk access to be slow and expecting RAM access to be fast. If the VM is making this not be the case, then the VM is doing something wrong.
So, basically, all those lines of code spent on checking the return value of malloc were a total waste of my time? That's disappointing.
Actually, what would be nice would be a way to reserve something like 1 or 2 percent of the RAM for the use of programs launched by one special rootlike user (user with uid 0, but not called 'root' - called something like "emergency" or something). This would be the safety net so that there was a way to do something about a system that was swapping like mad. The "emergency" user would always have a little sliver of actual ram guaranteed to exist for him and nobody else - for the purpose of logging in and running a shell and a few diagnostic commands. For a server environment where uptime is important, I'm sure a lot of sites would be willing to sacrifice the use of a few Mb of ram for this assurance, still leaving 98% of the system's ram for everything else.
Okay, so let's say you have X ram plus X swap. This means programs will die when you have 2*X memory used. How is this an improvement over having 2*X ram plus no swap, in which case programs will still die when you have 2*x memory used, but it will be over and done with faster, instead of being agonizingly slow while you are trying to root around finding the problem and being unable to get anywhere because it's taking over a minute to do a simple "ps aux".
People are speaking in terms of "I have X ram plus Y swap". For the sake of this question, look at it this way - you actually have X+Y amount of memory - but some of it is slow and some of it is fast. If there is a circumstance where this is an advantage over having X+Y of fast memory and none of the slow kind, then that means something is seriously wrong with the way the system is managing memory.
It's been my experience that by the time I notice a system is swapping like mad and therefore I should check to see if a process is eating too much memory, the performance is so terrible that my machine might as well have crashed altogether - at least then I could reboot, wait for fsck, and be back up and running, instead of it taking agonizingnly long to wait for the simplest of commands to finish while I try to discover the problem, and be frustrated that it's taking several minutes for a simple 'ps' command to run, and eventually I give up and reboot anyway.
The situation you speak of would only happen if a runaway process is eating memory *slowly* - slowly enough that you can start to detect a slowdown because of swap but still be able to use the system for a while before it gets really bad. That generally doesn't happen to me. Usually the onset of the memory eating is fast enough that by the time I notice, the system has already gone from usable to so slow I might as well reboot, and it only took a matter of less than 30 seconds to that state.
How is it that a system with 256 M of Ram plus 256 M of swap is better than one with 512 M of Ram? This is what your argument favors, even if you don't realize it. No matter what level you set your swap to, it will always be a finite size. But the only way to solve the kinds of problems you talk of is to have infinite ram, and swap doesn't do that for you.
This is getting back to the original question in the article - if my system performed okay with X amount of Ram and X amount of swap, then it should perform just great with 2X amount of ram and no swap, assuming the usage of the machine is the same. Why use swap then if I can afford to double the RAM? I thought swap was just for the case where my usage can't fit in my RAM. And clearly it has already been proven that it fits in 2X megabytes if I was previously running with X ram plus X swap.
And the answers in the article astonished me. They seemed to be paraphrasing "the way the kernel uses ram is stupider than the way it uses swap, and therefore having some swap improves performance." If that's the case then something is really wrong with the design.
since
Basically, you can't unsay things in an in-person conversation, why do you want it in an on-line conversation? Yeah, I know in this case you just wanted to fix up some formatting, but slashcode doesn't know that, and can't know that.
If you're doing something where the formatting matters, then use the preview button.
caught the essence of the 19340s
Futurists shouldn't really try to predict what things will be like 17 millenia from now. That is perhaps a bit of an overzelous attempt.
But there's a lot of people who think that a lack of existence is something that requires evidence, which is equally stupid, given that a lack of existence should be *expected* to leave behind to a lack of evidence. While it's true that a lack of evidence does not prove a lack of existence, it's also true that if you're looking for proof that nonexistant things are in fact nonexistant, then you're going about it all wrong in the first place.
The *ONLY* way you can ever say that a thing is nonexistant, is as a default starting hypothesis. Proof cannot sway you to that point if it's right, but it could sway you away from it if it's wrong.
Therefore it's a falsifiable hypothesis to state that a thing is assumed nonexistant by default until shown otherwise, and that's why it's a perfectly honest starting point to take nonexistence as the default hypothesis. In fact, it's the ONLY honest starting point.
To say otherwise is to believe in leprechauns and santa claus - which are also impossible to find evidence to prove are nonexistant.
Artists. They hire artists. Artists have an emotional attachment to Macs. Thus they'll get more familiarity with their new hires if they use Macs as opposed to linux, while at the same time retaining the ability to run all the same unixy rendering stuff they've been developing for ages.
...or just not giving a damn who the CEOs were at the time becuase I was just a student, not out in the business yet.
Reading TIME magazine doesn't put you into any "loop" I would consider relevant.
I guess even 7-digt ID's can be haughty assholes.
Not too mention that the fossil records for Dinosaurs don't stop on 1 day.
As I understood it, the record doesn't have precise enough time resolution to tell. If they all died out in one day, or if they all died out in 10,000 years it would basically look about the same as far as our ability to pin down the dates of things.
The only good way to survive that type of meteor impact is to not HAVE the impact in the first place.
And that means better space technology.
As Carl Sagan said, the dinasaurs died because they didn't have a space program.
Broil actually means that the heat source is above rather than below the food. The reason this is sometimes desirable is that it means the rack that the food sits on does not affect the surface of the food as much (the burn lines on the food) As hot air tends to rise more than fall, the heat setting has to be very high for a broil to work effectively. This incidental fact is why "broil" is label they put on the highest setting on the oven - it's because there's no much else you'd need that much heat for, NOT because broil just mean "hot".
And, actually, the highest setting I've seen on an oven is "clean", and "clean" does not equate to "high heat" either, in much the same way that "broil" doesn't.
Keep in mind that this isn't much of a move. It's more of a BSD move than a MacOS move. Pixar has been doing rendering on Unix since they first got started. The fact that a Unix now exists which is also an end-user consumer product is probably how they're viewing the move to OSX. Their move is really more of a "Compile our unix software to the version of BSD that's called OSX" as opposed to "Make this a Mac program."
It's a matter of if you prefer high-risk with high-yeilds or low-risk with low-yeilds. If Pixar continued its Disney deal, that would have meant Pixar wouldn't take the risk (as Disney would be doing the funding) but also Pixar would only see a tiny portion of the profits (as Disney would take most of that.)
So it's guaranteed minimal funding or risky gigantic profits. They chose the risky route. I believe the future will prove them right, as evidenced by the fact that all the talent in writing and animating these movies has been Pixar's work, not Disney's.
These days computer animations are everywhere. Pixar started it but they are no longer the only player in that market. But what they do have is better writing, and better in-jokes. They have been very successful at making movies that BOTH children and adults find entertaining (as opposed to typical Disney crap, where the adults are only bothering to go because their kids want to see it.) When Disney says "family movie" they really mean "children's movie." When Pixar says "family movie", they mean it.
Pixar will outlast Disney, precisely *because* they aren't afraid to take a risk when it's necessary (like this move was), while Disney is too conservative - preferring to follow established trends instead of starting them.
No, I'm not a Steve Jobs fan. I'm a Pixar fan, and have been since before I knew who the hell Jobs even was. I've been a fan since their animated short days, when I was using their Renderman(tm) software (a little bit) and going to animated film festivals and going ga-ga over seeing what they were doing with it. That's how I can tell they are where the creative talent was coming from, not Disney. Shorts like "Gerry's Game" and the mother-and-child desk lamps show all the same style of creative scripting as can be seen in Toy Story and Monsters Inc.