The parent poster is right. Just suspend processes which require more memory than can be made available. Use a preallocated pool of memory to store the suspended process information. Then wait for memory to become available again, perhaps writing messages to syslog so the sysadmin can take action to expediate this process. In the worst case nothing ever happens, which is better than the alternative, namely having processes killed basically at random (when the heuristics become complex enough, the result becomes indistinguishable from chance).
If you still do not agree, think long and hard about the scenario sketched by the poster above:
If there are other processes waiting for the one that's suspended, then eventually they'll go to sleep, their pages will be released, and the suspended process will wake up - which won't happen if you killed it.)
The idea of a modular VM stinks. It would just be another circle jerk to postpone having to work at actually getting a decent (mind you, decent, not perfect) VM subsystem.
Plug-ins, snap-ins, modular design; just different words for "procrastination".
I don't think you have to suffer a loss. Exactly what is keeping you from broadcasting movies over your wireless lan? And which CD requires that you listen it with your head under water?
Hyperbole is not helping our case, and neither does your (rather spoiled brattish IMHO) implied assertion that man has some kind of innate right to procure entertainment.
Selfcentered arguments such as yours will never win the public debate. Instead, it would be better to show people how copyright law is being used to suppress historical material that reflects negatively on the authors (e.g. Disney) (of course the same goes for matters of "security").
This is not true. Software may become faster as it evolves to exploit more powerful hardware. It may also become faster because of increased efficiency in the code.
But this does not mean that software gets faster with age. Because with age also come features and increased expectations. Imagine you had written a strcmp() routine ten years ago. You have had a decade to tweak your code and by now it is almost twice as fast as then.
However, now people expect Unicode support. If nothing else, this means your strcmp() has to compare twice as much data (not even counting character set translations and the like). So did your strcmp() actually become faster? Well, yes, it did -- but for any actual workload, no, it didn't.
I agree with your statement that we do not need a 2.2 GHz machine just to open a couple of applications. But people might require the ease of use (in the sense that the system has comprehensive knowledge about real world things such as character sets, physical dimensions, monetary values, etcetera) that a 2.2 GHz machine affords.
No, he's probably serious, and really thinks that all of the Internet's troubles can be solved by ditching the abject hippie Unix text protocols in favor of FuzzWuzz XML with Component Technology or something.
Dutch railways are blocking out non-IE users
on
The Tick to be Cancelled
·
· Score: -1, Offtopic
This warrants the brief attention of/.; if not in a story, then in this fashion.
The Dutch railway company is blocking non-IE users. Check it out, pass it on, and send a complaint. Thanks.
Why does anybody even care about all these USB toys? WTF would you want to connect your audio, which doesn't tolerate any lossage at all, to anything on this undercapacitated, misconceived jumble of adapters and hubs and cables that sort of hang together to form a protocol. I bet none of this junk will work in ten years time and nobody will know or care how to make it work.
Bah. USB is where Microsoft and Intel lord over a loserly pack of industry windbags who produce aftermarket throwaway junk devices to go with throwaway junk entertainment systems.
Sorry to attack you. But what should I care that you are stuck on Windows? Most of us saw that coming a decade ago. And what exactly is your beef with Windows? It seems to run the apps you need and has the GUI you like.
You might want a "modeller" and "Bryce" for your work. That's great. But I prefer to simply use the computer to realize an idea, whether that's processing text or synthesizing sound or manipulating graphics. Then I just write a little program in shell or Perl or C to do just what I need. For that you don't need a team of people, just good ideas.
Allright. If you will recall, what I am contending is the latter part of your claim that The only real approach to security is a pure capability system, and ofcourse the combination of pure capbility systems with safe languages.
In this latest reply of yours, you seem to almost agree with me, when you say: "VBS *is* safe (not secure, SAFE).". My point being, of course, that the only real approach to security is to, well, really approach security issues. Safe languages help to that end in so far as they can help prevent buffer overflow attacks or lock up the compute. But they do not "cause security".
This safety, however, comes at a cost. Sometimes, perhaps even often, this cost may be so small as to be insignificant. But when it is not, then you must weigh the costs of (e.g.) buffer overflows against the cost of safety. And when you do that, as the market has done, it turns out that for arguably the most popular classes of software, the cost of safety far exceeds the cost of an occasional buffer overflow.
One of the reasons for this is undoubtedly that many of the problems that a safe language fixes are easy to fix in the first place: i.e. a buffer overflow is easy to fix. Maybe hard to spot, but easy to fix. Now if you are in a situation where even a single failure due to a buffer overflow is unacceptable, or where the program's scope is so specialized that it makes no sense to worry about memory and pointers, then you should be using a safe lanuage. What popularity tells you however is that for the overwhelming majority of software, this is not the case.
Now you might argue, well, the costs of using a safe language are negligible, and as I said above, often this may actually be the case. But such is not the more general or popular case. So what are the costs?
Well, we could mention execution speed -- and in fact it was you (yourself a safe language advocate if you don't mind) who brought that up in the first place. It's not a surprise: proving that safe languages are not necessarily slow and may even be faster than C (yow!) is what safe language advocates have been doing ever since USCD p-code and Smalltalk ganged up on beefy hardware to bring it to its knees. So your claims are nothing new. Anyway, let's agree that speed is a cost. I'm even willing to accept that, yes, finally, Common Lisp can be just a fast as C. The problem is, that would make it, at best, not taking a step back. And then I'm not even talking about all the other performance related costs: startup times, garbage collection delays and the performance cost associated with a large memory footprint.
Which brings us to another cost, which is memory. Again, you have to ask yourselves, is it worth sacrificing 10 megabytes of memory to a buffer overflow? And again, looking at the majority of popular software today, well, no, often the additional memory usage does not seem to afford the extra safety. You might argue that computers of today have more memory than yesterday, but again, then the best you can say is that it is not taking a step back. Now I'm being a little disingenuous, because those 10 megabytes are not used just to prevent buffer overflows. They also buy you a lot of other stuff. Are they worth it? Well, sometimes. However, the market predominantly seems to think not.
Then other costs include a shortage of tools, a shortage of overall maturity and a shortage of skilled developers, all of which translates (or perhaps it's the other way around) into a smaller distribution, which in turn reinforces all of the above. It's a chicken-and-egg problem, but that doesn't negate the costs.
Then, I won't deny it, I have a personal bias against safe languages, and the broader practice of "wrapping things up". Every time you make programming easier by e.g. wrapping something inside an object, what you are really doing is making the code easier to write and understand at the cost of not having to know exactly what the code does. If this leads to unseen defects, or unforeseen delays ("we will replace that with a real X later" when you don't really know what X is) at a late stage in development, it can kill the project. IMHO, right next to premature optimization as the root of all evil, is premature wrapperization as the fruit of an overactive imagination.
Re:What good is it, if nobody adopts it?
on
GNOME 3.16 Released
·
· Score: 1
And another. The problem here isn't GNOME or KDE or Linux or the foot. It's users who really do not belong on the platform trying at every twist in the road to tell the drivers where the car should be going.
One word of advice: get out while you still can. Take the bus or something. Linux will never be for you. Thanks. Bye.
Slashdot Mirror
If you still do not agree, think long and hard about the scenario sketched by the poster above:
We don't need two different VM's. What is the use? Do you also want your car to have two steering wheels and three gas pedals?
What's the use? We would just end up with 2 different VM's and 3 subvariants of each, none of them actually working.
Plug-ins, snap-ins, modular design; just different words for "procrastination".
Hyperbole is not helping our case, and neither does your (rather spoiled brattish IMHO) implied assertion that man has some kind of innate right to procure entertainment.
Selfcentered arguments such as yours will never win the public debate. Instead, it would be better to show people how copyright law is being used to suppress historical material that reflects negatively on the authors (e.g. Disney) (of course the same goes for matters of "security").
The difference is digital, which means no generational loss between copies.
With a laptop you have the same problem. Who cares?
If you are so dissatisfied then nothing you are doing right now is giving you satisfaction.
But this does not mean that software gets faster with age. Because with age also come features and increased expectations. Imagine you had written a strcmp() routine ten years ago. You have had a decade to tweak your code and by now it is almost twice as fast as then.
However, now people expect Unicode support. If nothing else, this means your strcmp() has to compare twice as much data (not even counting character set translations and the like). So did your strcmp() actually become faster? Well, yes, it did -- but for any actual workload, no, it didn't.
I agree with your statement that we do not need a 2.2 GHz machine just to open a couple of applications. But people might require the ease of use (in the sense that the system has comprehensive knowledge about real world things such as character sets, physical dimensions, monetary values, etcetera) that a 2.2 GHz machine affords.
No, he's probably serious, and really thinks that all of the Internet's troubles can be solved by ditching the abject hippie Unix text protocols in favor of FuzzWuzz XML with Component Technology or something.
This warrants the brief attention of /.; if not in a story, then in this fashion.
The Dutch railway company is blocking non-IE users. Check it out, pass it on, and send a complaint. Thanks.
The Dutch railway company is blocking non-IE users. Check it out, pass it on, and send a complaint. Thanks.
The Dutch railway company is blocking non-IE users. Check it out, pass it on, and send a complaint. Thanks.
The Dutch railway company is blocking non-IE users. Check it out, pass it on, and send a complaint. Thanks.
The Dutch railway company is blocking non-IE users. Pass it on and submit a complaint. Thanks.
The Dutch railway company is blocking non-IE users. Pass it on and submit a complaint. Thanks.
The Dutch railway company is blocking non-IE users. Check it out, pass it on and submit a complaint. Thanks.
The Dutch railway company is blocking non-IE users. Pass it on and submit a complaint. Thanks.
Bah. USB is where Microsoft and Intel lord over a loserly pack of industry windbags who produce aftermarket throwaway junk devices to go with throwaway junk entertainment systems.
n/t
You might want a "modeller" and "Bryce" for your work. That's great. But I prefer to simply use the computer to realize an idea, whether that's processing text or synthesizing sound or manipulating graphics. Then I just write a little program in shell or Perl or C to do just what I need. For that you don't need a team of people, just good ideas.
Enjoy your stay in all those big apps.
In this latest reply of yours, you seem to almost agree with me, when you say: "VBS *is* safe (not secure, SAFE).". My point being, of course, that the only real approach to security is to, well, really approach security issues. Safe languages help to that end in so far as they can help prevent buffer overflow attacks or lock up the compute. But they do not "cause security".
This safety, however, comes at a cost. Sometimes, perhaps even often, this cost may be so small as to be insignificant. But when it is not, then you must weigh the costs of (e.g.) buffer overflows against the cost of safety. And when you do that, as the market has done, it turns out that for arguably the most popular classes of software, the cost of safety far exceeds the cost of an occasional buffer overflow.
One of the reasons for this is undoubtedly that many of the problems that a safe language fixes are easy to fix in the first place: i.e. a buffer overflow is easy to fix. Maybe hard to spot, but easy to fix. Now if you are in a situation where even a single failure due to a buffer overflow is unacceptable, or where the program's scope is so specialized that it makes no sense to worry about memory and pointers, then you should be using a safe lanuage. What popularity tells you however is that for the overwhelming majority of software, this is not the case.
Now you might argue, well, the costs of using a safe language are negligible, and as I said above, often this may actually be the case. But such is not the more general or popular case. So what are the costs?
Well, we could mention execution speed -- and in fact it was you (yourself a safe language advocate if you don't mind) who brought that up in the first place. It's not a surprise: proving that safe languages are not necessarily slow and may even be faster than C (yow!) is what safe language advocates have been doing ever since USCD p-code and Smalltalk ganged up on beefy hardware to bring it to its knees. So your claims are nothing new. Anyway, let's agree that speed is a cost. I'm even willing to accept that, yes, finally, Common Lisp can be just a fast as C. The problem is, that would make it, at best, not taking a step back. And then I'm not even talking about all the other performance related costs: startup times, garbage collection delays and the performance cost associated with a large memory footprint.
Which brings us to another cost, which is memory. Again, you have to ask yourselves, is it worth sacrificing 10 megabytes of memory to a buffer overflow? And again, looking at the majority of popular software today, well, no, often the additional memory usage does not seem to afford the extra safety. You might argue that computers of today have more memory than yesterday, but again, then the best you can say is that it is not taking a step back. Now I'm being a little disingenuous, because those 10 megabytes are not used just to prevent buffer overflows. They also buy you a lot of other stuff. Are they worth it? Well, sometimes. However, the market predominantly seems to think not.
Then other costs include a shortage of tools, a shortage of overall maturity and a shortage of skilled developers, all of which translates (or perhaps it's the other way around) into a smaller distribution, which in turn reinforces all of the above. It's a chicken-and-egg problem, but that doesn't negate the costs.
Then, I won't deny it, I have a personal bias against safe languages, and the broader practice of "wrapping things up". Every time you make programming easier by e.g. wrapping something inside an object, what you are really doing is making the code easier to write and understand at the cost of not having to know exactly what the code does. If this leads to unseen defects, or unforeseen delays ("we will replace that with a real X later" when you don't really know what X is) at a late stage in development, it can kill the project. IMHO, right next to premature optimization as the root of all evil, is premature wrapperization as the fruit of an overactive imagination.
One word of advice: get out while you still can. Take the bus or something. Linux will never be for you. Thanks. Bye.
Linux is not for you. Use Windows. Be happy. Stop whining.