"Then ask why Linus and Andrew - not to mention the distros - are allowing this, IF true."
They're doing active development on 2.6 and they don't want to fork 2.7 because apparently they're making good progress working as they are. They expect the distros to do regression testing -- something they are not equipped to do on a sufficiently large scale. Examples of major bugs allowed through are a memory leak when burning CDs (I think that was 2.6.5) and in 2.6.8 I can't have SATA and ATA devices connected to my motherboard (which supports both, and works under other versions of the Linux kernel and FreeBSD) at the same time. Those are the major ones that have affected me but there's always something.
Since each new kernel contains new bugs, upgrading isn't very useful because it just replaces bugs you know about and have worked around with ones you don't know about.
Yes, it rocks that much that we are looking for stable alternatives. Especially the 2.6 kernel has been *ahem* interesting. If the kernel hackers got their act together and released a really stable version of the 2.6 kernel we might want to use it. But they don't so we don't."
The contest with the Soviet Union was vital for propaganda reasons.
If the asteroid were going to hit somewhere like the south pacific or Africa, it's doubtful any meaningful action would be taken. If it were going to hit somewhere like NY, with a value (vague guess) in the tens of trillions of of dollars, it would be cheaper to simply ramp the space program up to spending levels similar to Apollo days.
This asteroid isn't big enough to wipe out civilization. It might destabalize things if something like NY were hit, but it won't destroy civilization as a primary effect.
I imagine it works with the MD5 and SHA1 vulnerabilities that have been found. If that's true the fix is trivial. The networks simply need to switch to a bigger/better/non-broken algorithm. There are many to choose from.
In the case of the systems running OpenOffice, I think it's a fair bet that most of them are single user systems running Windows or Linux, in which case a non-root exploit is most certainly a problem. Even on Linux, if the non-root user is in charge of the box, the attacker can probably get root pretty easily.
"I still haven't found anything that truely taxes my existing 3.2ghz P4. Games push the video card, not the CPU... I'm sure servers could benefit, but I don't see a major improvement in end user experience for these gaming systems."
Indeed. I've found that loading up on memory is far more effective at increasing system responsiveness. I've noticed that Windows is a bit worse at dealing with CPU hogs than Linux, so it probably benefits from dual cores more, but my Linux system is quite modest (P4 2.4 ghz, 1 gb memory) and it does everything I want simultaneously without responsiveness problems.
It would encode stuff faster, but my encoding needs are modest and I don't sit there watching it when it's going. I do something else because it doesn't make the computer unresponsive...
Of course... I'm not saying these things are useless. Some people do need very fast computers for whatever reason, and they're generally prepared to pay for that.
On a smaller number of CPUs, the performance penalty of a biglock kernel like OpenBSD, NetBSD and FreeBSD 4.x use isn't that bad. And given that OpenBSD and NetBSD don't generally need to run on > 2 CPUs, they can just sit back and see how the DragonFly approach to SMP works out. If it's successful, they can get similar performance to FreeBSD 5.x with a fraction of the work.
"Sorry folks, but DragonFly is really only suited for developers at the moment, IMHO."
Indeed.
I don't see anything particularly wrong with that. They're breaking a lot of new ground, and I don't see any of the developers claiming that they're production ready. I think Dillon mostly wants regular releases to keep the system stable enough to build itself.
"I think 64-bitness is only important when it improves performance."
It improves capabilities too. There's some jobs you just can't reasonably tackle (read: they're a huge PITA) on 32-bit machines no matter how fast.
"I'm not sure there's really a lot to gain there. Do you really know about algorithms that are faster in 64-bit mode, or are you guessing?"
Well encryption should benefit assuming someone optimizes the libraries (and yes I care about this as I use scp a lot), but for the most part I want a bigger address space so I can just throw everything into memory and let the OS worry about swapping it out, instead of the horrible hacks you need to do to juggle things in and out of disk yourself. That is none of the application's business.
I'm not into graphics stuff, but it's not difficult to imagine something like Photoshop benefitting (assuming they roll their own libraries, which I believe they do).
I think 64-bitness is more important, and you think performance is more imporant. I concede that a dual-core G4 would probably perform better than a single-core G5 given the power constraints of a laptop, but I disagree that that's the primary consideration.
What will determine the outcome is what Apple thinks is important, and what Apple thought the two companies could do at the time that they comitted to their next generation laptop processor, which I believe must have been some time ago.
That interpretation favors the G5, even though IBM has subsequently failed to deliver on their promises. We can infer that Apple didn't know that would happen in 2003, since the broken 3 ghz promise made Jobs look like an idiot. They had to make the decision based on what they knew. What they knew in 2003 was that Motorola had nearly killed them by consistently failing to meet performance requirements, and IBM had just saved them by meeting theirs.
"See, the G4 vs G5 question has a lot in common with the similar PIII vs P4 debate, except the G4 has had both arms tied behind its back by the crummy memory bus.
So did the P3: it had a 133 mhz bus compared to the P4 with a 400 mhz bus.
"You're being disengenuous. Tiger is primarily 32-bit, all the graphic code is still 32-bit, and any Cocoa software is 32-bit. It just has the ability to run 64-bit command-line programs, which is more than enough for most 64-bit software: for example, tthe 64-bit software I've been working on on Tru64 (which IS a native 64-bit OS) for most of the past 10 years... most of that is server code."
Software vendors can write their own graphics libraries or fork off helper processes. The sorts of software that would benefit from that kind of optimization is the sort of software that can ultimately make or break the PowerBook. Stuff like Adobe Photoshop.
"The MPC8641D is from FreeScal's System on Chip (SoC) range, and includes more or less everything except GPU (PCIe controller, memory controller, GigE controller) on die. Designing a logic board for it is going to be significantly less of a challenge than designing the existing logic boards - and they've had six months since FreeScale announced the chip to be working on it."
I knew that, but I figured Motorola would be making a version of the chip for Apple that didn't have so much of the system logic on the chip. However it's an interesting idea that Apple might be prepared to leverage the rest of the chip as it stands. They could probably get some power savings from doing that as well.
I have my doubts that they'll do it, but it's an interesting idea.
"Apple are in no hurry to move to 64-bit. Unlike x86, PowerPC was designed as a 32/64-bit ISA from the start, and so 64-bit code has no benefit at all unless you are addressing more than 4GB of RAM, or doing 64-bit integer arithmetic. In fact, it gives you a performance penalty - pointers are larger, thus taking up more cache space, and load / stores take longer. On x86-64, this is offset by making the architecture marginally less GPR-starved in 64-bit mode. Note that Carbon and Cocoa are still 32-bit, for exactly this reason - Apple don't want people complaining that their G5 is slower than a G4."
Even if the processor and the OS are 64-bit, it doesn't mean everything has to be. As you say, key parts of the OS will remain 32-bit, even though Tiger is fully 64-bit capable. However, applications can be 64-bit if they need to be, given hardware support. Things like Photoshop will be available in 64-bit versions, and PowerBooks will not be able to leverage this.
People expect PowerBooks to be powerful machines, and that is increasingly not the case. I think the expectation of 64-bitness is at least as important as performance.
"IBM have been launching a low-power G5 Real Soon Now(TM) since before the G5 was released, so don't hold your breath on that one."
Conversely, we know IBM is launching a dual-core G5, and the chances are very good that they would not have been able to do that if they had not made serious progress in keeping the power usage under control.
"A dual-core G4 would out-perform a single-core G5 (remember the dual 1.42GHz G4 Vs 1.6GHz G5 benchmarks? The dual 1.8GHz G5 was only slightly faster, and that's with the low FSB speed of the current G4s), and performance per watt is what counts in a laptop. If IBM can produce something that will beat a 1.5GHz MPC8641D at 15W, I would be very surprised - we're talking at least a 2.5GHz G5 here, and the current ones are around 45W."
If we assume that Apple is willing to take a clock speed hit (say <= 2 ghz for example) and that IBM has made progress in keeping the power usage under control (very likely for dual-core chips), then they may be a lot closer to a viable laptop chip.
The real question is: who did Apple think was the better alternative when they comitted to the chip they were going to use? They must surely have already done this, and if you look back a year or two ago, Motorola/Freescale was doing a lot worse, and IBM much better. They were convinced IBM would be delivering a 3 ghz G5. In that situation, I probably would have gone with IBM. I think Apple did too.
Re:But what about the PowerBooks!?
on
New Mac System Specs
·
· Score: 2, Insightful
The new Freescale chips aren't out yet, and except for thermal issues they're going to take as much of a redesign as G5s would. Probably more because they don't have any chipsets for them. I seriously doubt Apple is prepared to put that much work into redesigning PowerBooks when IBM will probably have a low-power G5 within the same timeframe. Particularly since much of the power saving work with a laptop chip would be shared with the dual-core chip we know they're going to release.
The question in my mind is whether or not they're going to put the new G4 chips in the other lines. And the answer to that is probably 'no' as well, IMO. Once they have a G5 suitable for laptops, Apple will be able to fit it into all the other lines, and they'll have a PowerPC 980/G6 by that time (end of 2006 or so) to maintain the separation between the lines.
Another consideration is that Apple is going to want to move to an all 64-bit lineup as soon as possible, so they can start EOLing the 32-bit stuff. The new Freescale chips will not be 64-bit (at first).
"I am not sure what you meant by this. Modern photolithography (used in production) has optics which works well at the 193nm wavelength. EUV which is lot more complicated has optics which works all the way to 13nm wavelength."
He's not talking about the ability of photolithography to produce structures. He's talking about the size of the wavelengths that would be used in the chip when it's running code. These are big.
This is my personal opinion, the biggest problem I had with other BSDs was the way they didn't fit with the way I prefer to do things. People with different preferences can easily have similar needs and come to different conclusions.
OpenBSD's goal is security, but as a side effect it's very easy to set up (eg hard to screw up and have an insecure configuration), and there are very few bugs compared to FreeBSD.
You don't tweak the kernel because the default one has almost everything that is supported. It makes the kernel bigger than it might otherwise need to be, but if you've got more than 16 mb of memory it doesn't matter.
There is a performance disadvantage (although PF performs well, and that's usually the only thing that matters), but things are easier to set up most of the time. If it's just a home gateway/router, your computer is probably bigtime overkill anyway, so you don't notice the performance disadvantage and you do notice the ease of configuration.
I probably wouldn't use it as a desktop OS because of the lack of software, but all the BSDs suffer from this. I couldn't even get by with FreeBSD as a desktop due to the lack of software. As a router, I haven't had any problems with getting software. What isn't in ports generally compiles fine. The one thing I haven't been able to get working with OpenBSD is a Haskell compiler, and the Haskell interpreter works fine so I don't care that much...
My motherboard supports both PATA and SATA drives. It supports them both on the chipset, instead of using a PCI chip soldered onto the board.
I used an IDE cable to connect the IDE CD drive to the IDE port on my motherboard. From the fact that I installed Linux by booting from that drive, and the fact that I can use the drive on other versions of the Linux kernel, and the fact that FreeBSD has no problems with it, I infer that it works in that configuration provided the OS can handle it.
On my version of the kernel (2.6.8), it detects the drive but explicitly says the drive is not supported. It works when I use a Promise IDE card for the CD drive.
Slashdot Mirror
"Then ask why Linus and Andrew - not to mention the distros - are allowing this, IF true."
They're doing active development on 2.6 and they don't want to fork 2.7 because apparently they're making good progress working as they are. They expect the distros to do regression testing -- something they are not equipped to do on a sufficiently large scale. Examples of major bugs allowed through are a memory leak when burning CDs (I think that was 2.6.5) and in 2.6.8 I can't have SATA and ATA devices connected to my motherboard (which supports both, and works under other versions of the Linux kernel and FreeBSD) at the same time. Those are the major ones that have affected me but there's always something.
Since each new kernel contains new bugs, upgrading isn't very useful because it just replaces bugs you know about and have worked around with ones you don't know about.
From the Gentoo-on-NT FAQ:
"Infidels! Linux rocks!
Yes, it rocks that much that we are looking for stable alternatives. Especially the 2.6 kernel has been *ahem* interesting. If the kernel hackers got their act together and released a really stable version of the 2.6 kernel we might want to use it. But they don't so we don't."
The people that use it generally do consider it easy to use because of the simplicity.
It's simply not targetted towards what most users looking for a desktop system would consider easy to use.
"So far I've heard nobody say the 2.6 kernel is in FACT unstable because of x, y, z drivers or subsystems."
Linux is "unstable" not because it crashes frequently but because serious bugs are allowed into each release of 2.6.x. It is a serious problem.
It's also a PITA if it's a virtual host because the webserver may not respond with the correct site if you simply enter the IP address.
It all depends on the motivation.
The contest with the Soviet Union was vital for propaganda reasons.
If the asteroid were going to hit somewhere like the south pacific or Africa, it's doubtful any meaningful action would be taken. If it were going to hit somewhere like NY, with a value (vague guess) in the tens of trillions of of dollars, it would be cheaper to simply ramp the space program up to spending levels similar to Apollo days.
This asteroid isn't big enough to wipe out civilization. It might destabalize things if something like NY were hit, but it won't destroy civilization as a primary effect.
"the full moon rising over the horizon was known to create a false signal"
How would the mood being full affect a radar signal?
I imagine it works with the MD5 and SHA1 vulnerabilities that have been found. If that's true the fix is trivial. The networks simply need to switch to a bigger/better/non-broken algorithm. There are many to choose from.
Last time I checked, space debris was in space.
In the case of the systems running OpenOffice, I think it's a fair bet that most of them are single user systems running Windows or Linux, in which case a non-root exploit is most certainly a problem. Even on Linux, if the non-root user is in charge of the box, the attacker can probably get root pretty easily.
"While running openoffice as root..."
Yes. Because they can't do any damage running as a normal user.
Except for running spyware and deleting all your files.
"I still haven't found anything that truely taxes my existing 3.2ghz P4. Games push the video card, not the CPU... I'm sure servers could benefit, but I don't see a major improvement in end user experience for these gaming systems."
Indeed. I've found that loading up on memory is far more effective at increasing system responsiveness. I've noticed that Windows is a bit worse at dealing with CPU hogs than Linux, so it probably benefits from dual cores more, but my Linux system is quite modest (P4 2.4 ghz, 1 gb memory) and it does everything I want simultaneously without responsiveness problems.
It would encode stuff faster, but my encoding needs are modest and I don't sit there watching it when it's going. I do something else because it doesn't make the computer unresponsive...
Of course... I'm not saying these things are useless. Some people do need very fast computers for whatever reason, and they're generally prepared to pay for that.
On a smaller number of CPUs, the performance penalty of a biglock kernel like OpenBSD, NetBSD and FreeBSD 4.x use isn't that bad. And given that OpenBSD and NetBSD don't generally need to run on > 2 CPUs, they can just sit back and see how the DragonFly approach to SMP works out. If it's successful, they can get similar performance to FreeBSD 5.x with a fraction of the work.
"Sorry folks, but DragonFly is really only suited for developers at the moment, IMHO."
Indeed.
I don't see anything particularly wrong with that. They're breaking a lot of new ground, and I don't see any of the developers claiming that they're production ready. I think Dillon mostly wants regular releases to keep the system stable enough to build itself.
"I think 64-bitness is only important when it improves performance."
It improves capabilities too. There's some jobs you just can't reasonably tackle (read: they're a huge PITA) on 32-bit machines no matter how fast.
"I'm not sure there's really a lot to gain there. Do you really know about algorithms that are faster in 64-bit mode, or are you guessing?"
Well encryption should benefit assuming someone optimizes the libraries (and yes I care about this as I use scp a lot), but for the most part I want a bigger address space so I can just throw everything into memory and let the OS worry about swapping it out, instead of the horrible hacks you need to do to juggle things in and out of disk yourself. That is none of the application's business.
I'm not into graphics stuff, but it's not difficult to imagine something like Photoshop benefitting (assuming they roll their own libraries, which I believe they do).
I think 64-bitness is more important, and you think performance is more imporant. I concede that a dual-core G4 would probably perform better than a single-core G5 given the power constraints of a laptop, but I disagree that that's the primary consideration.
What will determine the outcome is what Apple thinks is important, and what Apple thought the two companies could do at the time that they comitted to their next generation laptop processor, which I believe must have been some time ago.
That interpretation favors the G5, even though IBM has subsequently failed to deliver on their promises. We can infer that Apple didn't know that would happen in 2003, since the broken 3 ghz promise made Jobs look like an idiot. They had to make the decision based on what they knew. What they knew in 2003 was that Motorola had nearly killed them by consistently failing to meet performance requirements, and IBM had just saved them by meeting theirs.
"See, the G4 vs G5 question has a lot in common with the similar PIII vs P4 debate, except the G4 has had both arms tied behind its back by the crummy memory bus.
So did the P3: it had a 133 mhz bus compared to the P4 with a 400 mhz bus.
"You're being disengenuous. Tiger is primarily 32-bit, all the graphic code is still 32-bit, and any Cocoa software is 32-bit. It just has the ability to run 64-bit command-line programs, which is more than enough for most 64-bit software: for example, tthe 64-bit software I've been working on on Tru64 (which IS a native 64-bit OS) for most of the past 10 years... most of that is server code."
Software vendors can write their own graphics libraries or fork off helper processes. The sorts of software that would benefit from that kind of optimization is the sort of software that can ultimately make or break the PowerBook. Stuff like Adobe Photoshop.
"the G5 is a classic Pentium-style long-pipeline model..."
If by "Pentium-style", you mean "half as long and much wider than a Pentium", then yes. Yes it is.
"and the point of a long pipeline is to push ther clock. But, look, the G4 is catching up with the G5 on clock!"
AFAIK Freescale hopes to get G4s to 2 ghz some time next year...
"64 bit is not an unmixed win."
That's why 64-bit OSes (including Tiger) can run 32-bit code.
"The MPC8641D is from FreeScal's System on Chip (SoC) range, and includes more or less everything except GPU (PCIe controller, memory controller, GigE controller) on die. Designing a logic board for it is going to be significantly less of a challenge than designing the existing logic boards - and they've had six months since FreeScale announced the chip to be working on it."
I knew that, but I figured Motorola would be making a version of the chip for Apple that didn't have so much of the system logic on the chip. However it's an interesting idea that Apple might be prepared to leverage the rest of the chip as it stands. They could probably get some power savings from doing that as well.
I have my doubts that they'll do it, but it's an interesting idea.
"Apple are in no hurry to move to 64-bit. Unlike x86, PowerPC was designed as a 32/64-bit ISA from the start, and so 64-bit code has no benefit at all unless you are addressing more than 4GB of RAM, or doing 64-bit integer arithmetic. In fact, it gives you a performance penalty - pointers are larger, thus taking up more cache space, and load / stores take longer. On x86-64, this is offset by making the architecture marginally less GPR-starved in 64-bit mode. Note that Carbon and Cocoa are still 32-bit, for exactly this reason - Apple don't want people complaining that their G5 is slower than a G4."
Even if the processor and the OS are 64-bit, it doesn't mean everything has to be. As you say, key parts of the OS will remain 32-bit, even though Tiger is fully 64-bit capable. However, applications can be 64-bit if they need to be, given hardware support. Things like Photoshop will be available in 64-bit versions, and PowerBooks will not be able to leverage this.
People expect PowerBooks to be powerful machines, and that is increasingly not the case. I think the expectation of 64-bitness is at least as important as performance.
"IBM have been launching a low-power G5 Real Soon Now(TM) since before the G5 was released, so don't hold your breath on that one."
Conversely, we know IBM is launching a dual-core G5, and the chances are very good that they would not have been able to do that if they had not made serious progress in keeping the power usage under control.
"A dual-core G4 would out-perform a single-core G5 (remember the dual 1.42GHz G4 Vs 1.6GHz G5 benchmarks? The dual 1.8GHz G5 was only slightly faster, and that's with the low FSB speed of the current G4s), and performance per watt is what counts in a laptop. If IBM can produce something that will beat a 1.5GHz MPC8641D at 15W, I would be very surprised - we're talking at least a 2.5GHz G5 here, and the current ones are around 45W."
If we assume that Apple is willing to take a clock speed hit (say <= 2 ghz for example) and that IBM has made progress in keeping the power usage under control (very likely for dual-core chips), then they may be a lot closer to a viable laptop chip.
The real question is: who did Apple think was the better alternative when they comitted to the chip they were going to use? They must surely have already done this, and if you look back a year or two ago, Motorola/Freescale was doing a lot worse, and IBM much better. They were convinced IBM would be delivering a 3 ghz G5. In that situation, I probably would have gone with IBM. I think Apple did too.
The new Freescale chips aren't out yet, and except for thermal issues they're going to take as much of a redesign as G5s would. Probably more because they don't have any chipsets for them. I seriously doubt Apple is prepared to put that much work into redesigning PowerBooks when IBM will probably have a low-power G5 within the same timeframe. Particularly since much of the power saving work with a laptop chip would be shared with the dual-core chip we know they're going to release.
The question in my mind is whether or not they're going to put the new G4 chips in the other lines. And the answer to that is probably 'no' as well, IMO. Once they have a G5 suitable for laptops, Apple will be able to fit it into all the other lines, and they'll have a PowerPC 980/G6 by that time (end of 2006 or so) to maintain the separation between the lines.
Another consideration is that Apple is going to want to move to an all 64-bit lineup as soon as possible, so they can start EOLing the 32-bit stuff. The new Freescale chips will not be 64-bit (at first).
They won't get too excited about clock speed until they can replace the G4 chips, at least in the PowerBooks.
It's very unlikely that IBM can deliver a dual-core chip with higher clock speeds than are currently available, due to power constraints.
"I am not sure what you meant by this. Modern photolithography (used in production) has optics which works well at the 193nm wavelength. EUV which is lot more complicated has optics which works all the way to 13nm wavelength."
He's not talking about the ability of photolithography to produce structures. He's talking about the size of the wavelengths that would be used in the chip when it's running code. These are big.
This is my personal opinion, the biggest problem I had with other BSDs was the way they didn't fit with the way I prefer to do things. People with different preferences can easily have similar needs and come to different conclusions.
OpenBSD's goal is security, but as a side effect it's very easy to set up (eg hard to screw up and have an insecure configuration), and there are very few bugs compared to FreeBSD.
You don't tweak the kernel because the default one has almost everything that is supported. It makes the kernel bigger than it might otherwise need to be, but if you've got more than 16 mb of memory it doesn't matter.
There is a performance disadvantage (although PF performs well, and that's usually the only thing that matters), but things are easier to set up most of the time. If it's just a home gateway/router, your computer is probably bigtime overkill anyway, so you don't notice the performance disadvantage and you do notice the ease of configuration.
I probably wouldn't use it as a desktop OS because of the lack of software, but all the BSDs suffer from this. I couldn't even get by with FreeBSD as a desktop due to the lack of software. As a router, I haven't had any problems with getting software. What isn't in ports generally compiles fine. The one thing I haven't been able to get working with OpenBSD is a Haskell compiler, and the Haskell interpreter works fine so I don't care that much...
My motherboard supports both PATA and SATA drives. It supports them both on the chipset, instead of using a PCI chip soldered onto the board.
I used an IDE cable to connect the IDE CD drive to the IDE port on my motherboard. From the fact that I installed Linux by booting from that drive, and the fact that I can use the drive on other versions of the Linux kernel, and the fact that FreeBSD has no problems with it, I infer that it works in that configuration provided the OS can handle it.
On my version of the kernel (2.6.8), it detects the drive but explicitly says the drive is not supported. It works when I use a Promise IDE card for the CD drive.