"(Ironically, many users and distributions are likely to actually not mind slightly slower development for a while. One of the most common worries for users is just the fact that 2.6.x has continued to be developed at a very high rate thanks to just how smoothly it's been working, so I bet some people are both upset and gratified by this all.;)"
I just have one thing to say: About fucking time.
I'm on an out of date 2.6 kernel right now because every 2.6 kernel I've used has replaced one set of show-stopping bugs with another. I'd rather just stick with the show-stoppers that I've worked around (in this case, I use a Promise IDE card because the kernel doesn't support an SATA hard drive and a CD drive on the same chipset) than get a whole new set of show-stoppers that I may not be able compensate for.
I do not deny that Linux is annoying, but that's beside the point. My point is that Linux and MacOS are not source compatible.
These various APIs are just random examples I can talk about because I'm already aware of them. If I looked I'm sure I'd find many other examples of differences. That's not a value judgement on either OS, it's just something developers have to be aware of, and have had to be aware of since before MacOS or Linux existed.
You cannot assume non-trivial Linux code will compile or run properly on MacOS. You cannot assume non-trivial MacOS code will compile or run properly on Linux.
It would be irresponsible to send a program to the customer without doing your testing on the architechture and with the OS that they are going to use.
Some programs work, some programs don't. For example:
#include <stdio.h>
int main (int argc, char *argv[]) {
printf("Hello, world!\n"); }
That will work on just about any OS anyone has ever heard of, including Windows.
Some programs use library routines that are not implemented everywhere, and some OSes have differences in behaviour and bugs in their library routines. You can not simply ship software written and tested on MacOS after recompiling it for Linux. Even though 99.5% of the code is the same, it's your ass if a subtle difference turns into a bug on the customer's system.
The only way to be sure is to compile it on the target architechture and OS, and do your tests there.
"And having more bus doesn't automatically make a processor faster either."
That's true, Pentium 4's didn't improve much with the step to 1066 mhz. However, a fast bus is necessary for a fast processor. Unless the code you're running is optimized to fit in cache, which is essentially impossible on a desktop machine. Things like codecs get highly tuned, so they stay fast, but most software is highly resistant to tuning for cache size, and almost never worth the effort.
"The Motorola G4 (and PowerPC in general), gives me more performance per CPU cycle, than _any_ x86 CPU."
That's not true with the current chips. At the higher clock speeds G4s are now being sold at, the slow bus speed is crippling.
"Oh, and above all, their quality and efficiency is something you will never find on any x86 processor..."
They compare pretty unfavorably to Pentium M chips, which get better performance and have lower power usage. Note the Centrino (Pentium M + Intel chipset) laptops that have an 8 hour battery life, as compared to the best PowerBook's 5.
As for the quality... Intel chips and chipsets have a very good reputation for quality, and in my experience it is well deserved.
iBooks and minis are okay because people don't buy them for performance. The G5 computers are okay because they are obviously much faster. It's the PowerBooks that are hurting. One only has to look at the features that Apple is adding to the PowerBooks to see that they are aware of this.
I'm waiting for Java 1.5 on MacOS. The persistent lack of up to date Java on MacOS has long prevented me from even considering using a Mac as a workstation.
Also, MacOS and Linux are not source compatible. They're compatible enough that porting software isn't that hard, but you can't test on MacOS if you need to deliver to Linux.
Linux and MacOS are not source compatible. You can write portable software that knows how to adjust to the OS it's running on, but you can't deliver it to the customer if without testing the code paths they're going to use.
If the customer is going to use Linux PowerPC you have to test on Linux PowerPC. The mini is a cheap way of doing this.
"In all seriousness, there is not//one// Linux-created piece of software (that I wanted to run) which I couldn't compile for myself under Mac OS X. With or without Fink."
You downloaded software that had already been ported to MacOS. That's why you had to run the./configure script, so it could figure out what the local OS looked like. The developer has already made provisions for the way code needs to work on MacOS.
Linux and MacOS are not source compatible. Linux x86 and Linux PowerPC aren't even fully compatible (byte order issues and such). As an example, MacOS lacks the aio API, while Linux lacks the kqueue API. This is a problem because they're both APIs that allow asynchronous I/O. Portable software should take this into account, using aio on Linux and kqueue on MacOS, but because you're doing something different on MacOS, you can't test on MacOS if you need to run on Linux. And you can't test on Linux x86 if you need to run on Linux PowerPC.
For example, imagine that your software needs to run on one of those big IBM POWER systems that runs lots of Linux partitions. You can't afford one (that's not difficult to imagine), but you still want to do testing so you don't have the customer running into bugs. A Mac mini running Linux is a pretty damn cheap way to get that done, assuming the software isn't 64-bit. If you needed it to be 64-bit a G5 running Linux system would still probably be cheaper than the IBM alternative.
It takes a lot of effort to make the portable software that you use. Don't assume MacOS and Linux are fully compatible just because you're lucky enough to use software that was ported by someone that knew what they were doing.
Except this guy gives specifics, and the specifics are terrible.
Also dialogue, which was (as the reviewer points out) always the best part.
An example he gives:
"I eventually had to go down to the cellar to find them."
"That's the Display Department." "With a torch." "The lights had probably gone." "So had the stairs." "But you found the plans, didn't you?" "Oh yes, they were 'on display' in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the leopard.'"
Or, as the movie version has it:
"I eventually had to go down to the cellar to find them." "But you found the plans, didn't you?"
He gives other examples but I think you get the point. The things that made the story so much fun have been ruthelessly truncated.
Re:What provides the orbital speed of the cargo?
on
Space Elevator Update
·
· Score: 1
The cable is under tension as there's a counterweight at the top, above synchronous orbit. When the cargo takes kinetic energy away from the cable, the cable takes kinetic energy away from the Earth.
"If you're stuck high and above, you might have the space shuttle come and rescue you."
No.
At altitudes the shuttle can reach, the relative velocity between the shuttle and the elevator would be too great for a transfer.
Also, the shuttle can reach a few hundred kilometers. Not sure specifically what the limit is, but it's under a thousand kilometers. A space elevator has to go all the way up to geosynchronous orbit, which is 35786 km. You're out of reach for most of the journey.
It wouldn't be that hard (relative to the cost of the project anyway) to have an escape pod in elevator cars that have to carry humans. That could carry passangers back to earth, as they'd be in free fall for the most part.
I think there's a good chance that servers that users don't even notice directly (firewalls, fileservers, etc) are Linux and management doesn't know. A $250 million company is going to have enough people that the management doesn't necessarily know what everyone is doing.
Imagine the following: "Jim, we need you to set up a fileserver." "The budget for this quarter is gone, we can't afford the Windows license." "Okay."
The next day: "Jim, is the fileserver set up yet?" "Um... no. I'm going to do it this afternoon." "Great. Drop me an e-mail when it's ready."
Intel and AMD chips have completely different designs. In general, Intel chips are designed to blast through simple code very quickly (as Intel thought that's all chips would be doing by now), and AMD chips are designed to be able to handle branches and conditional code better. Also, current AMD chips have a memory controller on the chip itself rather than on a helper chip on the motherboard, which makes their memory access faster.
Before Intel hit the gHz wall, the strategy was actually working out pretty well. They were at a bit of a disandvantage in some areas, but for the most part the clock speeds were so high it didn't matter.
With the new Prescott core in Intel chips, they increased the penalty for branching in anticipation of still higher clock speeds. Those speeds never came, so they're at a disadvantage now.
At more or less the same time, AMD upgraded the memory interface of their chips, which improves performance in most areas in addition to helping them catch up with media stuff. At the same time they kept and in some cases improved their performance on branchy code. They avoided the gHz wall by improving performance without pumping clock speed.
I think Intel assumed Itanium would take over in areas that needed branchy code back when they comitted to the Pentium 4 design in the 90s. It arrived very late, and it turns out regular desktop users still need to deal with branchy code.
If it's just a first pass to cut down on CPU time used by SpamAssassin, shouldn't it take a more conservative approach? For example, instead of blacklisting an entire netblock, perhaps they should blacklist the source IP and then greylist the netblock (eg add a few points to the SpamAssassin score).
It really depends on what sort of work is happening. People that need fast computers for work (developers, graphics people, etc) generally stand to benefit. The apps tend to be optimized for it, and getting faster results increases their productivity a lot.
I won't buy a major part until I've specifically found some problems with it. Nothing is perfect, and until I feel I've got a reasonable sample of the sorts of problems a part has, I'm not comfortable buying it.
Besides, the stuff I do is generally improved by throwing gobs of RAM at the problem. That's generally easy to do no matter which parts you're buying.
I don't have any games either, I have a Matrox G550 that I got because it was cheap for dual-outputs, and it has a reputation for reliability. For those who don't know about its 3D performance, let's just say "it doesn't have a fan" and leave it at that.
However, the TFA has a point -- the selective application of benchmarks can make a chip look better or worse. Even if there aren't any games tested, gamers will look at the review and say "look how awesome that is!". They might not be right, but they do it anyway.
"If your trying to goto a site via SSL that has a valid and authorized certificate signed by a very public CA like Verisign or Thawte, then when your browser negotiates SSL, it will attempt to valdiate that the sites SSL certificate was propelry signed by a CA in your browser certificate store."
What part of "unless you use SSL" did you not understand?
Great. Except when the DNS server sends you somewhere where you can give up your credit card numbers, passwords, and other personal information. Unless SSL is employed, there's no practical way to know that you're going to the right site.
Re:Why does this scam get so much coverage?
on
CherryOS On Hold
·
· Score: 1
No; people that agreed simply didn't feel the need to contradict you.
Re:Why does this scam get so much coverage?
on
CherryOS On Hold
·
· Score: 2, Informative
"which IIRC due to the alvitec unit makes pretty much impossible"
It's mostly because PowerPC has more registers.
An x86 emulating PowerPC must supplement its limited supply of registers with memory, which is really slow even though it happens mostly in L1 cache. Emulating x86 on PowerPC is easier because PowerPC has enough registers to emulate all of the x86 registers without touching memory.
Altivec emulation sucks, but it's not the primary suckage.
Games are nice, and I'm somewhat surprised helmet displays aren't more popular for them, but that's not really VR and there's no content outside of that that would make VR more popular.
Of course it's slow, but it was always intended to by a hybrid with C. Since a significant fraction of the libraries are written in C, it's not actually that hard to write reasonably fast Python code.
For example, a project I worked on last year was only 20% faster in C than in Python. It relied heavily on the regex library, which is written in C.
Slashdot Mirror
"(Ironically, many users and distributions are likely to actually not mind slightly slower development for a while. One of the most common worries for users is just the fact that 2.6.x has continued to be developed at a very high rate thanks to just how smoothly it's been working, so I bet some people are both upset and gratified by this all. ;)"
I just have one thing to say: About fucking time.
I'm on an out of date 2.6 kernel right now because every 2.6 kernel I've used has replaced one set of show-stopping bugs with another. I'd rather just stick with the show-stoppers that I've worked around (in this case, I use a Promise IDE card because the kernel doesn't support an SATA hard drive and a CD drive on the same chipset) than get a whole new set of show-stoppers that I may not be able compensate for.
I do not deny that Linux is annoying, but that's beside the point. My point is that Linux and MacOS are not source compatible.
These various APIs are just random examples I can talk about because I'm already aware of them. If I looked I'm sure I'd find many other examples of differences. That's not a value judgement on either OS, it's just something developers have to be aware of, and have had to be aware of since before MacOS or Linux existed.
You cannot assume non-trivial Linux code will compile or run properly on MacOS.
You cannot assume non-trivial MacOS code will compile or run properly on Linux.
It would be irresponsible to send a program to the customer without doing your testing on the architechture and with the OS that they are going to use.
Some programs use library routines that are not implemented everywhere, and some OSes have differences in behaviour and bugs in their library routines. You can not simply ship software written and tested on MacOS after recompiling it for Linux. Even though 99.5% of the code is the same, it's your ass if a subtle difference turns into a bug on the customer's system.
The only way to be sure is to compile it on the target architechture and OS, and do your tests there.
"And having more bus doesn't automatically make a processor faster either."
That's true, Pentium 4's didn't improve much with the step to 1066 mhz. However, a fast bus is necessary for a fast processor. Unless the code you're running is optimized to fit in cache, which is essentially impossible on a desktop machine. Things like codecs get highly tuned, so they stay fast, but most software is highly resistant to tuning for cache size, and almost never worth the effort.
"The Motorola G4 (and PowerPC in general), gives me more performance per CPU cycle, than _any_ x86 CPU."
That's not true with the current chips. At the higher clock speeds G4s are now being sold at, the slow bus speed is crippling.
"Oh, and above all, their quality and efficiency is something you will never find on any x86 processor..."
They compare pretty unfavorably to Pentium M chips, which get better performance and have lower power usage. Note the Centrino (Pentium M + Intel chipset) laptops that have an 8 hour battery life, as compared to the best PowerBook's 5.
As for the quality... Intel chips and chipsets have a very good reputation for quality, and in my experience it is well deserved.
iBooks and minis are okay because people don't buy them for performance. The G5 computers are okay because they are obviously much faster. It's the PowerBooks that are hurting. One only has to look at the features that Apple is adding to the PowerBooks to see that they are aware of this.
huh. That's interesting. You appear to be correct. It's annoying that they left out the documentation but it is indeed present.
However, aio is just an example. epoll doesn't appear in MacOS either.
The PowerPC 970 is POWER4 based.
Being RISC doesn't automagically make a processor faster. G4s have a slower bus than Athlons had in 1999.
I'm waiting for Java 1.5 on MacOS. The persistent lack of up to date Java on MacOS has long prevented me from even considering using a Mac as a workstation.
Also, MacOS and Linux are not source compatible. They're compatible enough that porting software isn't that hard, but you can't test on MacOS if you need to deliver to Linux.
Linux and MacOS are not source compatible. You can write portable software that knows how to adjust to the OS it's running on, but you can't deliver it to the customer if without testing the code paths they're going to use.
If the customer is going to use Linux PowerPC you have to test on Linux PowerPC. The mini is a cheap way of doing this.
"In all seriousness, there is not //one// Linux-created piece of software (that I wanted to run) which I couldn't compile for myself under Mac OS X. With or without Fink."
./configure script, so it could figure out what the local OS looked like. The developer has already made provisions for the way code needs to work on MacOS.
You downloaded software that had already been ported to MacOS. That's why you had to run the
Linux and MacOS are not source compatible. Linux x86 and Linux PowerPC aren't even fully compatible (byte order issues and such). As an example, MacOS lacks the aio API, while Linux lacks the kqueue API. This is a problem because they're both APIs that allow asynchronous I/O. Portable software should take this into account, using aio on Linux and kqueue on MacOS, but because you're doing something different on MacOS, you can't test on MacOS if you need to run on Linux. And you can't test on Linux x86 if you need to run on Linux PowerPC.
For example, imagine that your software needs to run on one of those big IBM POWER systems that runs lots of Linux partitions. You can't afford one (that's not difficult to imagine), but you still want to do testing so you don't have the customer running into bugs. A Mac mini running Linux is a pretty damn cheap way to get that done, assuming the software isn't 64-bit. If you needed it to be 64-bit a G5 running Linux system would still probably be cheaper than the IBM alternative.
It takes a lot of effort to make the portable software that you use. Don't assume MacOS and Linux are fully compatible just because you're lucky enough to use software that was ported by someone that knew what they were doing.
Also dialogue, which was (as the reviewer points out) always the best part.
An example he gives:
He gives other examples but I think you get the point. The things that made the story so much fun have been ruthelessly truncated.
The cable is under tension as there's a counterweight at the top, above synchronous orbit. When the cargo takes kinetic energy away from the cable, the cable takes kinetic energy away from the Earth.
"If you're stuck high and above, you might have the space shuttle come and rescue you."
No.
At altitudes the shuttle can reach, the relative velocity between the shuttle and the elevator would be too great for a transfer.
Also, the shuttle can reach a few hundred kilometers. Not sure specifically what the limit is, but it's under a thousand kilometers. A space elevator has to go all the way up to geosynchronous orbit, which is 35786 km. You're out of reach for most of the journey.
It wouldn't be that hard (relative to the cost of the project anyway) to have an escape pod in elevator cars that have to carry humans. That could carry passangers back to earth, as they'd be in free fall for the most part.
I think there's a good chance that servers that users don't even notice directly (firewalls, fileservers, etc) are Linux and management doesn't know. A $250 million company is going to have enough people that the management doesn't necessarily know what everyone is doing.
Imagine the following:
"Jim, we need you to set up a fileserver."
"The budget for this quarter is gone, we can't afford the Windows license."
"Okay."
The next day:
"Jim, is the fileserver set up yet?"
"Um... no. I'm going to do it this afternoon."
"Great. Drop me an e-mail when it's ready."
Nobody knows. Nobody cares. But it's there.
Intel and AMD chips have completely different designs. In general, Intel chips are designed to blast through simple code very quickly (as Intel thought that's all chips would be doing by now), and AMD chips are designed to be able to handle branches and conditional code better. Also, current AMD chips have a memory controller on the chip itself rather than on a helper chip on the motherboard, which makes their memory access faster.
Before Intel hit the gHz wall, the strategy was actually working out pretty well. They were at a bit of a disandvantage in some areas, but for the most part the clock speeds were so high it didn't matter.
With the new Prescott core in Intel chips, they increased the penalty for branching in anticipation of still higher clock speeds. Those speeds never came, so they're at a disadvantage now.
At more or less the same time, AMD upgraded the memory interface of their chips, which improves performance in most areas in addition to helping them catch up with media stuff. At the same time they kept and in some cases improved their performance on branchy code. They avoided the gHz wall by improving performance without pumping clock speed.
I think Intel assumed Itanium would take over in areas that needed branchy code back when they comitted to the Pentium 4 design in the 90s. It arrived very late, and it turns out regular desktop users still need to deal with branchy code.
If it's just a first pass to cut down on CPU time used by SpamAssassin, shouldn't it take a more conservative approach? For example, instead of blacklisting an entire netblock, perhaps they should blacklist the source IP and then greylist the netblock (eg add a few points to the SpamAssassin score).
It really depends on what sort of work is happening. People that need fast computers for work (developers, graphics people, etc) generally stand to benefit. The apps tend to be optimized for it, and getting faster results increases their productivity a lot.
Take that a step further...
I won't buy a major part until I've specifically found some problems with it. Nothing is perfect, and until I feel I've got a reasonable sample of the sorts of problems a part has, I'm not comfortable buying it.
Besides, the stuff I do is generally improved by throwing gobs of RAM at the problem. That's generally easy to do no matter which parts you're buying.
I don't have any games either, I have a Matrox G550 that I got because it was cheap for dual-outputs, and it has a reputation for reliability. For those who don't know about its 3D performance, let's just say "it doesn't have a fan" and leave it at that.
However, the TFA has a point -- the selective application of benchmarks can make a chip look better or worse. Even if there aren't any games tested, gamers will look at the review and say "look how awesome that is!". They might not be right, but they do it anyway.
"If your trying to goto a site via SSL that has a valid and authorized certificate signed by a very public CA like Verisign or Thawte, then when your browser negotiates SSL, it will attempt to valdiate that the sites SSL certificate was propelry signed by a CA in your browser certificate store."
What part of "unless you use SSL" did you not understand?
Great. Except when the DNS server sends you somewhere where you can give up your credit card numbers, passwords, and other personal information. Unless SSL is employed, there's no practical way to know that you're going to the right site.
No; people that agreed simply didn't feel the need to contradict you.
"which IIRC due to the alvitec unit makes pretty much impossible"
It's mostly because PowerPC has more registers.
An x86 emulating PowerPC must supplement its limited supply of registers with memory, which is really slow even though it happens mostly in L1 cache. Emulating x86 on PowerPC is easier because PowerPC has enough registers to emulate all of the x86 registers without touching memory.
Altivec emulation sucks, but it's not the primary suckage.
Short answer: total lack of worthwhile content.
Games are nice, and I'm somewhat surprised helmet displays aren't more popular for them, but that's not really VR and there's no content outside of that that would make VR more popular.
Of course it's slow, but it was always intended to by a hybrid with C. Since a significant fraction of the libraries are written in C, it's not actually that hard to write reasonably fast Python code.
For example, a project I worked on last year was only 20% faster in C than in Python. It relied heavily on the regex library, which is written in C.