It matters a lot in thin client scenarios. You want as many users as possible on the same server. Importantly, you want idle sessions to be friendly to the system by releasing as much memory as possible.
The best way to get a promotion is to make your job redundant, or to get ready to start training your replacement. You employer will be grateful and should reward, but even if they don't then your prospects on the job market will be much improved.
Oh, and the next best tip is to learn a Unix (or Linux) some other poster said above.
FWIW, official Catholic Church doctrine is not Genesis-style creationism. Also, most Catholics I know take "official doctrine" to mean "food for thought".
Ya can't just pick and choose the bits that make sense to you and then get surprised when people paint you with the same brush as your insane fellow cultists.
You should know better than to make such broad generalisations to such a large number of people. You just called me an insane cultist. I'm offended to say the least. I am neither insane, nor a cultist.
I'm sure you're quick to point out prejudice in other people, but in this matter you fail to see your own.
Christianity is just as wacky and weird.. it's just that we all know that stuff.. if Scientology lasts 100 years we'll all be able to recite their theology too.
The amount of ignorance to be found amongst supposed nerds is astounding. What is so weird and whacky about the fundamental tenet of "love thy neighbour as you love yourself"? This is what Christianity is about to me. I don't deny there are a whole bunch of whack jobs (especially amongst the evangelical types), but by and large, for most Christians, it is about the virtues of compassion and sacrifice.
Scientology isn't about a mysterious god. It isn't about trying to put the unknown in a spiritual context. It is all about weird and whacky space stories and defrauding vulnerable people of wads of cash.
Whilst technically not very interesting, it was good to watch nonetheless and no doubt would have been a quite a sight in person. What is more interesting though is just how much content they were able to squeeze into 12x10 4-colour pixels.
If the code works, and you can show empirically that the code works, that is proven beyond a reasonable doubt it my opinion. Not beyond any doubt, but that isn't the standard that our justice system is based upon.
If you could test the code against all possible inputs then you would have no need to write the code in the first place as a solution would already exist. This applies to all types of software.
(In fact, just watch, I'm going to rub my crystal ball and predict that someone will promptly post a reply as to how wrong I am, and how homeopathy works and is proven and cures everything from hypochondria to cancer;)
Heat death is basically where the universe becomes void of heat and motion and there is nothing left but immobile objects.
The way I understand this scenario is that even immobile objects will have dissipated and there will be no energy left at all even in the form of mass.
Completely OT now, but I hope I live to see the day when we can manipulate gravity like we can electromagnetism. Imagine you could build a box that on the flick of an electrical switch, it would suddenly gain or lose weight. This is what a theory of everything might just lead to.
Going back on-topic now, I honestly don't get this whole creationism/ID thing. I consider myself a spiritual person, yet I find no conflict between logical reasoning (science) and spirituality.
All jokes aside. The version without Vista Ultimate would certainly not be reduced by the ticket price, even the standard OEM ticket price of Vista Ultimate.
It continues to astound me that this anti-competitive behaviour gets overlooked by the world's competition watchdogs.
They are referring to the case when the system isn't shut down cleanly. This means a kernel crash or a power outage. What is your point exactly? Seriously, and I really am doing my best to hold back on the personal insults (even when you something as annoying as "And calm down !!"), what is so difficult that you fail to comprehend what the real issue being discussed here is?
I assure you it is you who has mis-understood the situation. From the bug report referenced in the summary:
Today, I was experimenting with some BIOS settings that made the system crash right after loading the desktop. After a clean reboot pretty much any file written to by any application (during the previous boot) was 0 bytes.
For example Plasma and some of the KDE core config files were reset. Also some of my MySQL databases were killed...
My EXT4 partitions all use the default settings with no performance tweaks. Barriers on, extents on, ordered data mode..
I used Ext3 for 2 years and I never had any problems after power losses or system crashes.
The crash was not caused by ext4 but by something else. The file system was in a consistent state because of the journal. Some data had not yet been written to disk, because of the delayed write and was thus lost.
Maybe you need to take a break, or have a coffee, or get some sleep or something. But you really are way off and posting way too much on this topic that you are not well informed of.
This is not a bug, not a flaw, not a limitation. You can write and then read regardless of whether or not actual disk commits take place. The file system takes care of that for you. If you're doing file I/O, and you want to call yourself half-way competent, then you should have some clue about the possibility that the underlying file-system will be doing delayed writes. If you a writing critical applications for which this may cause issue then you might decide to throw in some fsync calls (or there equivalent in whatever platform you are using).
I know you have learnt something today. Glad to help out.
Who modded this up? Jane Q. Public is completely clueless on this topic, but she manages to sound like she has an idea to fellow clueless moderators. She should be called out for the karma whoring ignoramus she is.
Some choice quotes from her on this thread.
Delayed allocation is like leading a moving target when shooting.
BadAnalogyGuy would be proud. Probably also worth mentioning that without delayed allocation, the system would be unbearably slow.
The longer you delay allocation after writing the journal (and Ext4 seems to take this to extremes), the more chance there is of something -- almost anything really -- going wrong
A kernel crash or power outage is certainly something that could go wrong. Modern journalling file-systems handle this gracefully by making sure the file-system is in a consistent state when it comes back up.
The filesystem is flawed, plain and simple.
You'll realize why that one is a gem when you read her next quote. As the discussion continues, she begins to realize how far off the mark she is and begins to correct...
It most definitely is a filesystem limitation. That is different from saying that it's the filesystem's fault.
Still off the mark, but perhaps she is beginning to figure out what a file system should offer and what the issue being discussed is.
If an application that reads and writes lots of small files fails under Ext4, then it is Ext4's fault, not the application. An application should be able to read and write lots of small files if it wants... I can think of a great many practical examples.
Go ahead and do that. But if you want to make sure you're data is written, in case of a kernel crash or power outage, then you had better understand what is going on at the FS level.
As a user of a high-level language, I should not be expected to know the disk I/O API in a given OS. That is for the authors of the compiler or interpreter.
No, but you should understand the API of the language you are dealing with. Since when does a compiler handle disk I/O anyway? As for your interpreter, it is free to call fsync whenever it wants, but what has that got to do with the FS again?
Excuse the heck out of me, but the issue being discussed was a failure that was NOT due to a power loss or other such system problem. It was a crash caused by this very issue. If it were simply missing data due to power loss or some such, there would be no point in this discussion at all.
The purpose of this quote is to demonstrate that she both has no regard for TFA and also has no idea what this issue being discussed is. I encourage anyone looking to give her mod points actually RTFA and also do a bit of background reading on file systems and in particular delayed writes.
My point was and still is: if the data is not flushed to disk yet, it should either be accessible from the buffer, or not at all.
This sentence alone deserves a -1 Huh? If you do a write, and it is successful, then you can do a read on the same file and it will return what you wrote, whether or not it had been flushed to disk. This is the way it is supposed to work. Think about it for like 10 seconds and you'll begin to get it.
not supposed to have to worry about OS-specific details
WE ARE TALKING ABOUT UNEXPECTED KERNEL CRASHED AND POWER OUTAGES. If you care about that situation then you should get a clue before you start coding. If not, then what is the problem, or was it fault... er, sorry limitation?
One should not have to know about syncing to do something like a few simple file writes
And one doesn't need to if she is not concerned with the rare possibility that the system CRASHES OR LOSES POWER in the next few minutes.
Anyway, I've never called out another poster like this before and now I feel dirty.
The KDE and GNOME desktop applications often read and write a large number of small files (for example, the configuration files for your personal settings). If the system crashes there may not be enough time for the data to be allocated and written to the hard drive â" under ext4, the files may be truncated.
Clearly you must have read TFA if you were advising me to do so. So I can only conclude that you are in fact entirely clueless on the subject matter if you did RTFA but completely failed to grasp what is going on.
Of course, I mean you no personal offence, and you don't have to take my word for it, but you really don't know what you're talking about. You should not be posting so much about this topic. If you spend a few hours, reading up on and perhaps even implementing a basic file-system, you will personally gain far more than this incessant spam-posting.
You are a very prolific poster but you still have no point. What high-level language are you referring to?
Java? See java.io.FileDescriptor.sync(). You might also want to read about java.io.Writer.flush() and how that doesn't mean data is written to the underlying device.
Python? See os.fsync.
No one is asking you to learn assembly, but at least understand the API of the language you are dealing with.
If you're not to worried about the rare event of a crash or power-loss, then you don't even need to bother with any of that. Just write as you normally would and know that the system will deal with it in an efficient manner.
So please get a clue before making a thousand posts on a subject you have clearly failed to comprehend.
Not an expert on quantum crypto, but from the sounds of it you will need an all optical link. This does not preclude the possibility of switching and routing though. Many networking functions are already being implemented optically, for example wavelength based switching devices that are all optical, and optical regenerative repeaters. Many of the basic building blocks are already available or being perfected.
It matters a lot in thin client scenarios. You want as many users as possible on the same server. Importantly, you want idle sessions to be friendly to the system by releasing as much memory as possible.
Oh, and the next best tip is to learn a Unix (or Linux) some other poster said above.
Whoosh
[...] Lighting manufactures can create good lights that allow the light to shine down and not up into the sky. [...]
People keep saying this but I always thought reflected light would be the bigger problem.
and God invented the universe in 6 days too.
FWIW, official Catholic Church doctrine is not Genesis-style creationism. Also, most Catholics I know take "official doctrine" to mean "food for thought".
Ya can't just pick and choose the bits that make sense to you and then get surprised when people paint you with the same brush as your insane fellow cultists.
You should know better than to make such broad generalisations to such a large number of people. You just called me an insane cultist. I'm offended to say the least. I am neither insane, nor a cultist.
I'm sure you're quick to point out prejudice in other people, but in this matter you fail to see your own.
Christianity is just as wacky and weird.. it's just that we all know that stuff.. if Scientology lasts 100 years we'll all be able to recite their theology too.
The amount of ignorance to be found amongst supposed nerds is astounding. What is so weird and whacky about the fundamental tenet of "love thy neighbour as you love yourself"? This is what Christianity is about to me. I don't deny there are a whole bunch of whack jobs (especially amongst the evangelical types), but by and large, for most Christians, it is about the virtues of compassion and sacrifice.
Scientology isn't about a mysterious god. It isn't about trying to put the unknown in a spiritual context. It is all about weird and whacky space stories and defrauding vulnerable people of wads of cash.
Whilst technically not very interesting, it was good to watch nonetheless and no doubt would have been a quite a sight in person. What is more interesting though is just how much content they were able to squeeze into 12x10 4-colour pixels.
If the code works, and you can show empirically that the code works, that is proven beyond a reasonable doubt it my opinion. Not beyond any doubt, but that isn't the standard that our justice system is based upon.
If you could test the code against all possible inputs then you would have no need to write the code in the first place as a solution would already exist. This applies to all types of software.
replying to remove wrong mod
(In fact, just watch, I'm going to rub my crystal ball and predict that someone will promptly post a reply as to how wrong I am, and how homeopathy works and is proven and cures everything from hypochondria to cancer;)
WRONG! This is /.. Everybody here is smart.
Heat death is basically where the universe becomes void of heat and motion and there is nothing left but immobile objects.
The way I understand this scenario is that even immobile objects will have dissipated and there will be no energy left at all even in the form of mass.
Yep, that's where Symantec comes in to save the day.
Some do, some don't. I prefer stable and well tested and that is why I use CentOS.
Completely OT now, but I hope I live to see the day when we can manipulate gravity like we can electromagnetism. Imagine you could build a box that on the flick of an electrical switch, it would suddenly gain or lose weight. This is what a theory of everything might just lead to.
Going back on-topic now, I honestly don't get this whole creationism/ID thing. I consider myself a spiritual person, yet I find no conflict between logical reasoning (science) and spirituality.
Would be interesting to find out what IBMs plans for Sun Ray are. Desktop virtualisation is an area that Sun excels in at the moment.
+1 Meta-Funny.
You mean:
kill 0 -1
All jokes aside. The version without Vista Ultimate would certainly not be reduced by the ticket price, even the standard OEM ticket price of Vista Ultimate.
It continues to astound me that this anti-competitive behaviour gets overlooked by the world's competition watchdogs.
They are referring to the case when the system isn't shut down cleanly. This means a kernel crash or a power outage. What is your point exactly? Seriously, and I really am doing my best to hold back on the personal insults (even when you something as annoying as "And calm down !!"), what is so difficult that you fail to comprehend what the real issue being discussed here is?
Today, I was experimenting with some BIOS settings that made the system crash right after loading the desktop. After a clean reboot pretty much any file written to by any application (during the previous boot) was 0 bytes. For example Plasma and some of the KDE core config files were reset. Also some of my MySQL databases were killed...
My EXT4 partitions all use the default settings with no performance tweaks. Barriers on, extents on, ordered data mode..
I used Ext3 for 2 years and I never had any problems after power losses or system crashes.
The crash was not caused by ext4 but by something else. The file system was in a consistent state because of the journal. Some data had not yet been written to disk, because of the delayed write and was thus lost.
Maybe you need to take a break, or have a coffee, or get some sleep or something. But you really are way off and posting way too much on this topic that you are not well informed of.
This is not a bug, not a flaw, not a limitation. You can write and then read regardless of whether or not actual disk commits take place. The file system takes care of that for you. If you're doing file I/O, and you want to call yourself half-way competent, then you should have some clue about the possibility that the underlying file-system will be doing delayed writes. If you a writing critical applications for which this may cause issue then you might decide to throw in some fsync calls (or there equivalent in whatever platform you are using).
I know you have learnt something today. Glad to help out.
Who modded this up? Jane Q. Public is completely clueless on this topic, but she manages to sound like she has an idea to fellow clueless moderators. She should be called out for the karma whoring ignoramus she is.
Some choice quotes from her on this thread.
Delayed allocation is like leading a moving target when shooting.
BadAnalogyGuy would be proud. Probably also worth mentioning that without delayed allocation, the system would be unbearably slow.
The longer you delay allocation after writing the journal (and Ext4 seems to take this to extremes), the more chance there is of something -- almost anything really -- going wrong
A kernel crash or power outage is certainly something that could go wrong. Modern journalling file-systems handle this gracefully by making sure the file-system is in a consistent state when it comes back up.
The filesystem is flawed, plain and simple.
You'll realize why that one is a gem when you read her next quote. As the discussion continues, she begins to realize how far off the mark she is and begins to correct...
It most definitely is a filesystem limitation. That is different from saying that it's the filesystem's fault.
Still off the mark, but perhaps she is beginning to figure out what a file system should offer and what the issue being discussed is.
If an application that reads and writes lots of small files fails under Ext4, then it is Ext4's fault, not the application. An application should be able to read and write lots of small files if it wants... I can think of a great many practical examples.
Go ahead and do that. But if you want to make sure you're data is written, in case of a kernel crash or power outage, then you had better understand what is going on at the FS level.
As a user of a high-level language, I should not be expected to know the disk I/O API in a given OS. That is for the authors of the compiler or interpreter.
No, but you should understand the API of the language you are dealing with. Since when does a compiler handle disk I/O anyway? As for your interpreter, it is free to call fsync whenever it wants, but what has that got to do with the FS again?
Excuse the heck out of me, but the issue being discussed was a failure that was NOT due to a power loss or other such system problem. It was a crash caused by this very issue. If it were simply missing data due to power loss or some such, there would be no point in this discussion at all.
The purpose of this quote is to demonstrate that she both has no regard for TFA and also has no idea what this issue being discussed is. I encourage anyone looking to give her mod points actually RTFA and also do a bit of background reading on file systems and in particular delayed writes.
My point was and still is: if the data is not flushed to disk yet, it should either be accessible from the buffer, or not at all.
This sentence alone deserves a -1 Huh? If you do a write, and it is successful, then you can do a read on the same file and it will return what you wrote, whether or not it had been flushed to disk. This is the way it is supposed to work. Think about it for like 10 seconds and you'll begin to get it.
not supposed to have to worry about OS-specific details
WE ARE TALKING ABOUT UNEXPECTED KERNEL CRASHED AND POWER OUTAGES. If you care about that situation then you should get a clue before you start coding. If not, then what is the problem, or was it fault... er, sorry limitation?
One should not have to know about syncing to do something like a few simple file writes
And one doesn't need to if she is not concerned with the rare possibility that the system CRASHES OR LOSES POWER in the next few minutes.
Anyway, I've never called out another poster like this before and now I feel dirty.
The KDE and GNOME desktop applications often read and write a large number of small files (for example, the configuration files for your personal settings). If the system crashes there may not be enough time for the data to be allocated and written to the hard drive â" under ext4, the files may be truncated.
Clearly you must have read TFA if you were advising me to do so. So I can only conclude that you are in fact entirely clueless on the subject matter if you did RTFA but completely failed to grasp what is going on.
Of course, I mean you no personal offence, and you don't have to take my word for it, but you really don't know what you're talking about. You should not be posting so much about this topic. If you spend a few hours, reading up on and perhaps even implementing a basic file-system, you will personally gain far more than this incessant spam-posting.
Java? See java.io.FileDescriptor.sync(). You might also want to read about java.io.Writer.flush() and how that doesn't mean data is written to the underlying device.
Python? See os.fsync.
No one is asking you to learn assembly, but at least understand the API of the language you are dealing with.
If you're not to worried about the rare event of a crash or power-loss, then you don't even need to bother with any of that. Just write as you normally would and know that the system will deal with it in an efficient manner.
So please get a clue before making a thousand posts on a subject you have clearly failed to comprehend.
Google gets the joke.
Not an expert on quantum crypto, but from the sounds of it you will need an all optical link. This does not preclude the possibility of switching and routing though. Many networking functions are already being implemented optically, for example wavelength based switching devices that are all optical, and optical regenerative repeaters. Many of the basic building blocks are already available or being perfected.