The operating system should be fault tolerant and not fail when a foreign(read: third party) application does some unexpected behavior.
For the most part, modern windows does not crash and burn when a third party userland application does stuff. There are certainly the occasional bug and wierd corner cases, but those are to be expected in any software system that was not designed to be proven correct.
However, if a driver has bugs there really isn't much the OS can do. A driver is sitting there in kernel space, and if it starts writing to random locations in memory or other funkiness it will bring down the box; this is true in most every operating system. Microsoft can not really be blamed for bad third party drivers when they misbehave.
If you don't want to upgrade every year, you could have sources.list point to woody (or whatever current stable is) rather than 'stable', then only upgrade every other release, or otherwise at your leisure; whereas 'stable' changes when there is a new release, 'woody' will always point at 3.0. I'm almost certain that one release back still gets decent security updates.
of course, if whatever machine you're using lets you execute off of a USB drive, it probably lets you write to and execute arbitrary programs on disk...
Just google putty and download the main executable.:) It's small enough
Also, the old OSS modules are still in the kernel. I haven't tried them in 2.5, and they are marked with a big DEPRECATED, but they're still there.
Note, of course, as I've said elsewhere, you do need the new module-init-tools; I'd imagine that would be the most likey reason you'd have trouble getting a 2.5 kernel working, followed closely by an out of date/broken driver.
Will this be simply a kernel upgrade and I'm running 2.6? Or... will I have to wait for a distro to release their 2.6 version?
Kinda-sorta. Unless your system is wierd, you should be able to take a 2.5/2.6 kernel, drop it in along with the new modutils (sys-apps/module-init-tools for the gentoo people) and it should work... for the most part, the kernel doesn't break old userspace programs.
You might need new libraries to take advantage of some new features, of course.
In fact, 2.5 isn't that bad right now... certainly, it would be crazy to use it on a production system unless you really know what you're doing[1], but it's quite usable, and the scheduling has really improved.
[1] in which case you probably wouldn't use it on said production system...;)
Well if its totally non competitive why don't they charge twice what they do, and make twice as much?
Because then they would probably sell less than half as many copies. There are probably a lot of people who purchase photoshop who don't REALLY need it, or don't REALLY need a newer version.
I'll point out at this stage that room temperature superconductors would make electricity almost free. As to the rest - well *shrugs*
Huh? I was under the impression that the loss in transmission at this point was on the order of 10%, if that; room temperature superconductors might help significantly with local surges in demand, because electricity could be transmitted farther (the bottleneck would be capacity of the lines and not loss to resistance) but at some point any joule of electrical energy has to be produced somewhere, and that costs significant cash.
I can only speak of my own experience with Gentoo Linux(which is supposed to be pretty fast if done right), and the speed I get in UT2k3 or NWN is nowhere near what I get in Windows. Sorry.
Although you should note that, in the case of the first, UT2k3's linux port is fairly unoptimized. (IIRC, the entire openGL rendering path is not optimized) Also, NWN is still in beta... although if you are getting framerates significantly lower in it, you probably have something setting broken. (color depth?)
In any case, neither of those are very fair comparisons. (although NWN is more fair than UT2k3)
So null pointer references *should* be disallowed. But I've encountered bad valid uses of null pointers. I've seen code where location 0 was used to store a value that needed to be globally accessible.
They are. Or, at the very least, what happens is not well defined. It is certainly not remotely portable to be writing or even reading from null.
Well, yeah, we all know that. The only time when the whole value of a null pointer not necessarily being zero would ever become an issue is if you assume that a pointer that has been zeroed another way, such as calloc(), would evaluate to NULL. That's beside the point, though.
The point is that the poster I was replying to was clearly completely ignorant as to what a null pointer actually was, and the comment came off as something like "winderz sux because programs crash when they dereference null" complete with a haughty "RTFL" tone.
It only says the code is mapped to the bottom 15MB. Each program has its own address space. It still exists in any part of physical memory it wants to, but the beginning virtuial address is put in the lower 16MB instead of the current default, which I believe relocates programs to 0x08048000 or something like that.
Sigh... second person in the past 24 hours that I've felt compelled to take the cluebat to. (This is slashdot... why am I surprised?) Parent was asking about the question of what happens if one tries to run a single program with more than 15MB worth of object code+libraries.
At least it is clear both parent and grandparent understand what parent just said-- parent was answering the wrong question. Certainly it shouldn't be at 5 (at least in reply to grandparent)
That said, I am quite interested to know how they handle the issue of programs over 15M. (presumably by letting some of the code out of this 'ascii armor'?)
It's a null-dereference bug. That means something tried to access memory location zero. Apparently under Winderz, location zero is not mapped to anything and causes a crash from an invalid memory access.
You don't know what you're talking about. I'll bet $5 that you have never done serious C programming before...
This is a decent explanation of what a null pointer is.
(Oh yeah, this is slashdot... why am I surprised?)
According to this blind listening test conducted by c't magazine, AAC at 128kbps was ranked the lowest of all codecs sampled at that bitrate (WAV, OGG, WMA, RA, MP3Pro and MP3)...
That was the ORIGINAL wav, not a 128kbps wav. A 128kbps wav would suck compared to a 128kbps compressed anything.
X is a lot better nine years on, and I can't help wondering if everyone who writes "X sucks" is still using a 3.x version or lower.... (and I use X 4.3.0 with a Pentium 120 and a 500 MHz Celeron so if there were speed issues I think I'd be aware of them!)
XFree86 != X. There is a plethora of other X implementations. Saying "X 4.3.0" is akin to saying "Linux 9.0", and sounds almost as bad.
Actually, they only have a velocity of zero relative to you because you're looking at it in terms of a non-inertial reference frame.
Let's reduce this to two dimensions. Imagine you're on a huge carousel, one that has a 100000 mile radius. You are standing at, say, 5000 miles from the center. Label this point ground. Now, a friend of yours stands 30000 miles from the center. The merry go round rotates at one rotation per day.
Relative to an observer not attached to the carousel, how much more quickly is your friend moving than you are?
In the original system, there is a 'force', gravity, that counteracts the centrifugal [1] force you would feel outward in the example. In the case of your friend, the geosynchronous sattelite, the two forces exactly cancel (that is an equivalent definition to what the geosynchronous orbit is) Whereas, in your case, the outward force is much smaller; the extra force from gravity is counteracted by the ground below you physically stopping you.
If you tried to just move up to where the geosynchronous sattelite is at, it would be moving far more quickly than you are. Furthermore, the ground would be moving quite quickly eastward with respect to you, as the ground is a lot closer to the center of the earth than you would be. Thirdly, you would fall back to the ground quite rapidly (without your own counteracting rocket or something) due to lack of a force keeping you at your height. If you added the extra velocity to match speeds with the sattelite, you would be in orbit and the other two problems would then disappear.:)
[1] note that the argument can be made that the centrifugal force isn't a 'force', it is inertia. At this point, I would make the same statement about gravity (inertia on a curved spacetime); treating both as forces is a nice simplification. Looking from the outside, gravity doesn't counteract a centrifugal force: the satellite is moving so quickly with respect to the ground that the gravity inwards just counteracts the outward component of the satellite's velocity. There might be a similar insight looking at gravity as inertia; my head hurts trying to do so, though. (probably from inexperience)
Slashdot Mirror
The operating system should be fault tolerant and not fail when a foreign(read: third party) application does some unexpected behavior.
For the most part, modern windows does not crash and burn when a third party userland application does stuff. There are certainly the occasional bug and wierd corner cases, but those are to be expected in any software system that was not designed to be proven correct.
However, if a driver has bugs there really isn't much the OS can do. A driver is sitting there in kernel space, and if it starts writing to random locations in memory or other funkiness it will bring down the box; this is true in most every operating system. Microsoft can not really be blamed for bad third party drivers when they misbehave.
If you don't want to upgrade every year, you could have sources.list point to woody (or whatever current stable is) rather than 'stable', then only upgrade every other release, or otherwise at your leisure; whereas 'stable' changes when there is a new release, 'woody' will always point at 3.0. I'm almost certain that one release back still gets decent security updates.
But you probably knew this already.
of course, if whatever machine you're using lets you execute off of a USB drive, it probably lets you write to and execute arbitrary programs on disk...
:) It's small enough
Just google putty and download the main executable.
Of course, that doesn't solve the key issue...
$1 per user per month would cover that user listening to 14 songs
1400.
There is no such thing as centfugal force. The two forces in effect with orbit are momentum, and gravity.
If you want to get pedantic about it, there's no such thing as gravity. It's just inertia/momentum acting on a curved space-time.
(at least if you buy general relativity)
Looks like they're trying to have Slashdot readers write their book for them.
(unless I'm mistaken here) they weren't at all inolved in the posting of a link to slashdot.
Also, the old OSS modules are still in the kernel. I haven't tried them in 2.5, and they are marked with a big DEPRECATED, but they're still there.
Note, of course, as I've said elsewhere, you do need the new module-init-tools; I'd imagine that would be the most likey reason you'd have trouble getting a 2.5 kernel working, followed closely by an out of date/broken driver.
Will this be simply a kernel upgrade and I'm running 2.6? Or... will I have to wait for a distro to release their 2.6 version?
Kinda-sorta. Unless your system is wierd, you should be able to take a 2.5/2.6 kernel, drop it in along with the new modutils (sys-apps/module-init-tools for the gentoo people) and it should work... for the most part, the kernel doesn't break old userspace programs.
You might need new libraries to take advantage of some new features, of course.
In fact, 2.5 isn't that bad right now... certainly, it would be crazy to use it on a production system unless you really know what you're doing[1], but it's quite usable, and the scheduling has really improved.
;)
[1] in which case you probably wouldn't use it on said production system...
It's fucking funny cuz you used a $ to indicate their greed and evil!!! ... I like OSS, too!
Don't you mean O$$?
and the kernel, and reiserfs, and...
redhat's 2.96 was crap until 7.3, when they fixed most of the bugs.
Whatever you say, troll. Maybe you can also tell me which way the egg rolls off the henhouse when the rooster sitting on top of it lays an egg.
diamond egg square down
Well if its totally non competitive why don't they charge twice what they do, and make twice as much?
Because then they would probably sell less than half as many copies. There are probably a lot of people who purchase photoshop who don't REALLY need it, or don't REALLY need a newer version.
I thought that the NVidia drivers were closed? How can that work?
They're basically a wrapper around a binary driver... patching the wrapper is sufficient.
I'll point out at this stage that room temperature superconductors would make electricity almost free. As to the rest - well *shrugs*
Huh? I was under the impression that the loss in transmission at this point was on the order of 10%, if that; room temperature superconductors might help significantly with local surges in demand, because electricity could be transmitted farther (the bottleneck would be capacity of the lines and not loss to resistance) but at some point any joule of electrical energy has to be produced somewhere, and that costs significant cash.
nah, the'yre just counting internal purchases now.
They probably use redhat internally.
I can only speak of my own experience with Gentoo Linux(which is supposed to be pretty fast if done right), and the speed I get in UT2k3 or NWN is nowhere near what I get in Windows. Sorry.
Although you should note that, in the case of the first, UT2k3's linux port is fairly unoptimized. (IIRC, the entire openGL rendering path is not optimized) Also, NWN is still in beta... although if you are getting framerates significantly lower in it, you probably have something setting broken. (color depth?)
In any case, neither of those are very fair comparisons. (although NWN is more fair than UT2k3)
So null pointer references *should* be disallowed. But I've encountered bad valid uses of null pointers. I've seen code where location 0 was used to store a value that needed to be globally accessible.
They are. Or, at the very least, what happens is not well defined. It is certainly not remotely portable to be writing or even reading from null.
Well, yeah, we all know that. The only time when the whole value of a null pointer not necessarily being zero would ever become an issue is if you assume that a pointer that has been zeroed another way, such as calloc(), would evaluate to NULL. That's beside the point, though.
The point is that the poster I was replying to was clearly completely ignorant as to what a null pointer actually was, and the comment came off as something like "winderz sux because programs crash when they dereference null" complete with a haughty "RTFL" tone.
It only says the code is mapped to the bottom 15MB. Each program has its own address space. It still exists in any part of physical memory it wants to, but the beginning virtuial address is put in the lower 16MB instead of the current default, which I believe relocates programs to 0x08048000 or something like that.
Sigh... second person in the past 24 hours that I've felt compelled to take the cluebat to. (This is slashdot... why am I surprised?) Parent was asking about the question of what happens if one tries to run a single program with more than 15MB worth of object code+libraries.
At least it is clear both parent and grandparent understand what parent just said-- parent was answering the wrong question. Certainly it shouldn't be at 5 (at least in reply to grandparent)
That said, I am quite interested to know how they handle the issue of programs over 15M. (presumably by letting some of the code out of this 'ascii armor'?)
It's a null-dereference bug. That means something tried to access memory location zero. Apparently under Winderz, location zero is not mapped to anything and causes a crash from an invalid memory access.
You don't know what you're talking about. I'll bet $5 that you have never done serious C programming before...
This is a decent explanation of what a null pointer is.
(Oh yeah, this is slashdot... why am I surprised?)
According to this blind listening test conducted by c't magazine, AAC at 128kbps was ranked the lowest of all codecs sampled at that bitrate (WAV, OGG, WMA, RA, MP3Pro and MP3)...
That was the ORIGINAL wav, not a 128kbps wav. A 128kbps wav would suck compared to a 128kbps compressed anything.
X is a lot better nine years on, and I can't help wondering if everyone who writes "X sucks" is still using a 3.x version or lower. ... (and I use X 4.3.0 with a Pentium 120 and a 500 MHz Celeron so if there were speed issues I think I'd be aware of them!)
XFree86 != X. There is a plethora of other X implementations. Saying "X 4.3.0" is akin to saying "Linux 9.0", and sounds almost as bad.
So the solution is two accounts, alternating between each on a monthly basis?
in which case you are paying twice as much, of course. They wouldn't mind.
Actually, they only have a velocity of zero relative to you because you're looking at it in terms of a non-inertial reference frame.
:)
Let's reduce this to two dimensions. Imagine you're on a huge carousel, one that has a 100000 mile radius. You are standing at, say, 5000 miles from the center. Label this point ground. Now, a friend of yours stands 30000 miles from the center. The merry go round rotates at one rotation per day.
Relative to an observer not attached to the carousel, how much more quickly is your friend moving than you are?
In the original system, there is a 'force', gravity, that counteracts the centrifugal [1] force you would feel outward in the example. In the case of your friend, the geosynchronous sattelite, the two forces exactly cancel (that is an equivalent definition to what the geosynchronous orbit is) Whereas, in your case, the outward force is much smaller; the extra force from gravity is counteracted by the ground below you physically stopping you.
If you tried to just move up to where the geosynchronous sattelite is at, it would be moving far more quickly than you are. Furthermore, the ground would be moving quite quickly eastward with respect to you, as the ground is a lot closer to the center of the earth than you would be. Thirdly, you would fall back to the ground quite rapidly (without your own counteracting rocket or something) due to lack of a force keeping you at your height. If you added the extra velocity to match speeds with the sattelite, you would be in orbit and the other two problems would then disappear.
[1] note that the argument can be made that the centrifugal force isn't a 'force', it is inertia. At this point, I would make the same statement about gravity (inertia on a curved spacetime); treating both as forces is a nice simplification. Looking from the outside, gravity doesn't counteract a centrifugal force: the satellite is moving so quickly with respect to the ground that the gravity inwards just counteracts the outward component of the satellite's velocity. There might be a similar insight looking at gravity as inertia; my head hurts trying to do so, though. (probably from inexperience)