Since when do Macs ship with software on par with Microsoft Office or Nero?
I'm not familiar with Premiere or Cakewalk (or their Apple equivilants), but since you exagerated things I am familiar with, I strongly suspect you exagerated those as well.
"It seems silly to be kitting these out with Gb cards when most of these will just be used for home surfing."
Gigabit ethernet doesn't cost that much more for a vendor to include, and it's basically mandatory for anyone that does anything serious with network drives.
"Professionals should get a PowerMac" is no excuse for artificially castrating a computer.
"I think the #1 problem AMD must overcome is the relationship Intel has with Microsoft. AMD makes clone chips, Intel makes chips that fit into Microsofts OS. Intel and Microsoft share information about how the chip will work with the software."
AMD came up with x86-64. Microsoft was only willing to support one 64-bit extension to x86, so that's what Intel chips use; they are the clones now. And Intel is the one with compatability problems (eg DMA is broken with Intel x86-64 chip, which seriously hurts performance).
I don't support one over the other. They trade performance and price/performance crowns regularly and I'll buy whoever's ahead this quarter. Just sayin' that AMD not "just a clone" anymore.
Well the fuel for D-T fusion is plentiful, and the radioactives left behind are short lived compared to fission. It'll be a better solution when it becomes economical.
It's just that I'm not sure anyone around today will live to see it become economical. It's generations away.
On UNIX, there's a lot of different processes that are responsible for launching other processes in certain situations. That kind of fragmentation leads to overlapping areas of responsibility.
For example, when something like cron or at doesn't do what we want (say mount a disk when it's inserted), we have to create a new daemon to do that. But that daemon starts to get feature creep, maybe we want a service to be running when that disk is mounted, and that service has dependencies, etc.
Also, there's no reason something like launchd can't read cron config files and perform the same duties that cron otherwise would.
I'm not the early adopter type, but if Apple wants to pour resources into something that may benefit me when people have tested it a bit, then hey, go for it.
I believe this won't be directly used as cache (as the limited write cycles of flash memory would make this impossible), but it will provide an area where relatively static information (like the kernel, libraries, etc) can be stored and accessed without spinning the drive up. Obviously the OS needs to get involved because only it is in a position to know what files should be placed in this cache.
If MRAM ever becomes economical, it might be useful as a non-volatile general-purpose cache. That would be handy because it would reduce the risk of corruption on power loss.
"And no Linux distribution allows you to make use of your own compiler flags?"
Of course you can set your own compile flags. That would be why I said "Stack protections like propolice are a compile-time option and can be used on any OS on any architechture.". You clipped that part of my sentence in your quote.
The other features I mentioned require OS support, as they involve small but significant changes to the internals of the OS.
The stack behaviour of PowerPC is just as predictable as x86, and it's just as easy to perform a buffer overflow attack on vulnerable code.
PowerPC doesn't offer more per-page protection than x86, and it offers less than x86-64, as x86-64 can disable execution on a per-page basis.
It's possible to do things on both architechtures like add a random offset to the stack or load libraries at random locations. This makes attacks much more difficult, and OSes like OpenBSD do them on both architechtures. OSes like Linux or MacOS don't do them on any architechtures. Stack protections like propolice are a compile-time option and can be used on any OS on any architechture.
The mainstream architechtures of today do very little to distinguish themselves from each other security wise. One of the the few features that is different from one architechture to another, per-page execute protection, is not available on PowerPC.
This is why Microsoft didn't have proper piracy protection until XP. Up until XP came out, they felt the competition was still a threat. Linux wasn't quite on the horizon (for Microsoft as a desktop threat), and Motorola had nearly killed Apple.
Of course, the competition is more of a threat now than any time since the early 90s, but that's a pretty new development.
IBM can't add more registers. The PowerPC instruction format provides 5 bits to specify a register, which means it's only possible to use 32 different (2 ^ 5) registers. To add more, they would have to make instructions bigger than 32 bits, which would not be worth the increase in registers.
Not exactly... symlinks on a *nix system have an out-of-band (eg unrelated to either the file name and its contents) way to notify you that they are a symlink, with the file mode. Also, userspace code that doesn't care if a file is a symlink will have it handled transparently. AFAIK on Windows it just looks at the.lnk extension, and it only does that if it's written to be aware of shortcuts.
"Also, with regards to testing, those of us who use it daily are testing all the time. I know it's not structured QA, but still, it's a lot of testing."
When having users stumble into bugs is your primary method of finding them, your QA has already failed.
Because they do active development on the 2.6 branch, new bugs are introduced all the time. Even if they're only there for one version, there's always more bugs in the next version, which is a big disincentive for upgrades. And not minor stuff, big things like the ability to burn CDs.
Without proper regression testing stuff like that will continue to haunt users. The assumption is that distros will do it, but the simple fact is that they aren't. The kernel developers must take responsibility for it.
just when OpenBSD i386 started to move to 3.x
on
GCC 4.0.0 Released
·
· Score: 2, Interesting
The OpenBSD crowd had a lot of concerns about bugs in 3.x and performance regressions (in compiling, not in the resulting binaries). I believe Linus shared some of these concerns (don't have a link handy).
OpenBSD i386 is finally moving towards gcc 3.x, as the bugs have been cleared up even if the performance regressions haven't. I'm wondering if 4.x will be even worse, and if it will be justified by producing better binaries. From TFA, it looks like they've added a few features that may improve optimizations. If it's noticeably better they may move to the new version faster.
I will have to play with it to see what it can do.
"How is this different from any other system? So you're expecting a bug-free kernel someday? LOL!"
I expect a monotonically decreasing number of bugs in the stable branch. 2.4 got very close to that, FreeBSD 4.x gets close to that. 2.6 doesn't get anywhere near it, despite the fact that it is the "stable" branch.
"Also, reread what you just wrote - they're fixing one bug and replacing it with another. So you admit they're fixing the bugs."
To benefit from the fix, I must expose myself to other bugs that I won't necessarily know about until I install the new kernel.
"I think the issues - if significant - have to do more with the PACE of new additions to the kernel than the TYPE of new additions, which appeared to be CA's complaint."
This is my complaint exactly. Instead of forking 2.7 and stabalizing 2.6, they continue to do active development on the stable kernel while 2.4 becomes increasingly obsolete. This leaves me without an recent kernel that I can keep up to date (eg security patches).
"2.6 is under heavy development, as you state. While from a server operator's view, this might be unfortunate"
The stream of new bugs is, as you say, a natural consequence of the active development being done on 2.6. However, my complaint is with the active development itself because it creates the bugs. It's prevents the up to date kernel from being used for important things.
Is this different than other OSes? Yes. OpenBSD and FreeBSD almost never break when updating to a stable branch. Linux 2.6 would be preferable if all else were equal, but the probability of a 2.6 kernel working is low enough that it's not worth the effort to even try, and it's usually worth the effort to migrate a machine away from Linux to FreeBSD if an update becomes unavoidable. I've been doing this because while it lacks features I'd like, I can keep a FreeBSD machine up to date without a high probability of breaking things.
"What are they doing that is so affected by X specific bugs that the system is "unstable" to them?"
My use of "unstable" in this case refers to the frequency of regressions in new versions, not machines that crash once in a while.
Slashdot Mirror
Since when do Macs ship with software on par with Microsoft Office or Nero?
I'm not familiar with Premiere or Cakewalk (or their Apple equivilants), but since you exagerated things I am familiar with, I strongly suspect you exagerated those as well.
"It seems silly to be kitting these out with Gb cards when most of these will just be used for home surfing."
Gigabit ethernet doesn't cost that much more for a vendor to include, and it's basically mandatory for anyone that does anything serious with network drives.
"Professionals should get a PowerMac" is no excuse for artificially castrating a computer.
"I think the #1 problem AMD must overcome is the relationship Intel has with Microsoft. AMD makes clone chips, Intel makes chips that fit into Microsofts OS. Intel and Microsoft share information about how the chip will work with the software."
AMD came up with x86-64. Microsoft was only willing to support one 64-bit extension to x86, so that's what Intel chips use; they are the clones now. And Intel is the one with compatability problems (eg DMA is broken with Intel x86-64 chip, which seriously hurts performance).
I don't support one over the other. They trade performance and price/performance crowns regularly and I'll buy whoever's ahead this quarter. Just sayin' that AMD not "just a clone" anymore.
Well the fuel for D-T fusion is plentiful, and the radioactives left behind are short lived compared to fission. It'll be a better solution when it becomes economical.
It's just that I'm not sure anyone around today will live to see it become economical. It's generations away.
Peak oil will happen, but fusion isn't going to help us. We're generations away from commercial fusion power.
Fission is the only thing that is ready and available to step up, along with a few other things like coal gassification.
Excellent. I shall seed overnight at least.
If we don't have anyone that can handle mirroring it can we set up a torrent? I don't think gmail will allow > 10 mb files.
The upcomming election is going to be very close, and I doubt a majority government is going to result no matter who wins.
Nobody here is going to do more than say "we're examining the issue" or words to that effect.
The US is not in a position to use NAFTA to demand concessions from us at the moment.
On UNIX, there's a lot of different processes that are responsible for launching other processes in certain situations. That kind of fragmentation leads to overlapping areas of responsibility.
For example, when something like cron or at doesn't do what we want (say mount a disk when it's inserted), we have to create a new daemon to do that. But that daemon starts to get feature creep, maybe we want a service to be running when that disk is mounted, and that service has dependencies, etc.
Also, there's no reason something like launchd can't read cron config files and perform the same duties that cron otherwise would.
I'm not the early adopter type, but if Apple wants to pour resources into something that may benefit me when people have tested it a bit, then hey, go for it.
I believe this won't be directly used as cache (as the limited write cycles of flash memory would make this impossible), but it will provide an area where relatively static information (like the kernel, libraries, etc) can be stored and accessed without spinning the drive up. Obviously the OS needs to get involved because only it is in a position to know what files should be placed in this cache.
If MRAM ever becomes economical, it might be useful as a non-volatile general-purpose cache. That would be handy because it would reduce the risk of corruption on power loss.
"And no Linux distribution allows you to make use of your own compiler flags?"
Of course you can set your own compile flags. That would be why I said "Stack protections like propolice are a compile-time option and can be used on any OS on any architechture.". You clipped that part of my sentence in your quote.
The other features I mentioned require OS support, as they involve small but significant changes to the internals of the OS.
Exactly.
The security advantage of MacOS X is a lack of braindead design decisions, it has nothing to do with PowerPC.
Interestingly, PowerPC lacks a per-page execute disable as well. It has nothing to do with whether an architechture is RISC or not.
For starters, Windows does run on RISC.
The stack behaviour of PowerPC is just as predictable as x86, and it's just as easy to perform a buffer overflow attack on vulnerable code.
PowerPC doesn't offer more per-page protection than x86, and it offers less than x86-64, as x86-64 can disable execution on a per-page basis.
It's possible to do things on both architechtures like add a random offset to the stack or load libraries at random locations. This makes attacks much more difficult, and OSes like OpenBSD do them on both architechtures. OSes like Linux or MacOS don't do them on any architechtures. Stack protections like propolice are a compile-time option and can be used on any OS on any architechture.
The mainstream architechtures of today do very little to distinguish themselves from each other security wise. One of the the few features that is different from one architechture to another, per-page execute protection, is not available on PowerPC.
This guy doesn't know what he's talking about.
I looks like "Mozilla Firefox" is really an umbrella term for all Mozilla browsers.
This is why Microsoft didn't have proper piracy protection until XP. Up until XP came out, they felt the competition was still a threat. Linux wasn't quite on the horizon (for Microsoft as a desktop threat), and Motorola had nearly killed Apple.
Of course, the competition is more of a threat now than any time since the early 90s, but that's a pretty new development.
IBM can't add more registers. The PowerPC instruction format provides 5 bits to specify a register, which means it's only possible to use 32 different (2 ^ 5) registers. To add more, they would have to make instructions bigger than 32 bits, which would not be worth the increase in registers.
I will ask him at the CUUG (Calgary UNIX Users Group) meeting on the 18th.
""Roughly a third of the lines in the episode are either spoken by the Dalek or Rose," says Briggs. "It never shuts up!""
I'm having trouble imagining a Dalek having that much dialogue. They barely know words other than "Exterminate!".
Not exactly... symlinks on a *nix system have an out-of-band (eg unrelated to either the file name and its contents) way to notify you that they are a symlink, with the file mode. Also, userspace code that doesn't care if a file is a symlink will have it handled transparently. AFAIK on Windows it just looks at the .lnk extension, and it only does that if it's written to be aware of shortcuts.
This is why it's a good idea to a) fork 2.7 so 2.6 can stabalize, and b) to automate the testing as much as possible.
"Also, with regards to testing, those of us who use it daily are testing all the time. I know it's not structured QA, but still, it's a lot of testing."
When having users stumble into bugs is your primary method of finding them, your QA has already failed.
Because they do active development on the 2.6 branch, new bugs are introduced all the time. Even if they're only there for one version, there's always more bugs in the next version, which is a big disincentive for upgrades. And not minor stuff, big things like the ability to burn CDs.
Without proper regression testing stuff like that will continue to haunt users. The assumption is that distros will do it, but the simple fact is that they aren't. The kernel developers must take responsibility for it.
The OpenBSD crowd had a lot of concerns about bugs in 3.x and performance regressions (in compiling, not in the resulting binaries). I believe Linus shared some of these concerns (don't have a link handy).
OpenBSD i386 is finally moving towards gcc 3.x, as the bugs have been cleared up even if the performance regressions haven't. I'm wondering if 4.x will be even worse, and if it will be justified by producing better binaries. From TFA, it looks like they've added a few features that may improve optimizations. If it's noticeably better they may move to the new version faster.
I will have to play with it to see what it can do.
"How is this different from any other system?
So you're expecting a bug-free kernel someday?
LOL!"
I expect a monotonically decreasing number of bugs in the stable branch. 2.4 got very close to that, FreeBSD 4.x gets close to that. 2.6 doesn't get anywhere near it, despite the fact that it is the "stable" branch.
"Also, reread what you just wrote - they're fixing one bug and replacing it with another. So you admit they're fixing the bugs."
To benefit from the fix, I must expose myself to other bugs that I won't necessarily know about until I install the new kernel.
"I think the issues - if significant - have to do more with the PACE of new additions to the kernel than the TYPE of new additions, which appeared to be CA's complaint."
This is my complaint exactly. Instead of forking 2.7 and stabalizing 2.6, they continue to do active development on the stable kernel while 2.4 becomes increasingly obsolete. This leaves me without an recent kernel that I can keep up to date (eg security patches).
"2.6 is under heavy development, as you state. While from a server operator's view, this might be unfortunate"
The stream of new bugs is, as you say, a natural consequence of the active development being done on 2.6. However, my complaint is with the active development itself because it creates the bugs. It's prevents the up to date kernel from being used for important things.
Is this different than other OSes? Yes. OpenBSD and FreeBSD almost never break when updating to a stable branch. Linux 2.6 would be preferable if all else were equal, but the probability of a 2.6 kernel working is low enough that it's not worth the effort to even try, and it's usually worth the effort to migrate a machine away from Linux to FreeBSD if an update becomes unavoidable. I've been doing this because while it lacks features I'd like, I can keep a FreeBSD machine up to date without a high probability of breaking things.
"What are they doing that is so affected by X specific bugs that the system is "unstable" to them?"
My use of "unstable" in this case refers to the frequency of regressions in new versions, not machines that crash once in a while.