The next gen consoles have a substantial advantage over PCs because all their hardware is optimized specifically for games in ways that are mutually exclusive with good PC performance.
However, I wouldn't be all that surprised if graphics cards started getting console subsystems entirely on the card.
It makes you read the docs. It forces you to use a standard API when byte order is important. It keeps you from hardcoding values (eg sizeof(void*)). It keeps you from making platform dependant optimizations that might not even be supported by the next version of the platform you're on, or if you do it forces you to make them modular.
It forces you to figure out what behavior you can rely on. Bug compatability with older versions relies on the magnanimity of the maintainer, and cannot be assumed even if you're staying on Linux.
"IMO the most notorious case is how the gcc development is held hostage by Edelsohn and maybe IBM as a whole by requesting that everything always works perfectly well on AIX. How often has one seen "this patch breaks AIX, back it out". It cannot reasonably be expected that everybody tests on AIX. It is an proprietary OS running on proprietary and expensive hardware which not many people have access to. The overall development speed could be significantly improved by dropping the AIX requirement which, in some form or another, has been agreed upon by the steering committee. AIX is irrelevant in general today, i.e., the situation changed. And the people in the steering committee are too nice to just tell the very small minority causing the problem to take a hike."
GCC is the de facto standard because it runs on more platforms than anybody else.
If it ceases to run on all these platforms, it will either: a) fork a project that will support them b) another compiler will take its place as the de facto standard c) people will be forced to use whatever the default cc is on their OS.
In any of these cases, the portability concerns will get an order of magnitude worse.
Isn't it easier to produce methane directly from algae? That might not be quite as dense as other hydrocarbons, but it's not that bad and it's a lot better than hydrogen. It's also useful for producing oil from resources like the tar sands in Alberta (that requires a lot of natural gas eg methane).
"The huge number of problems that keep cropping up in all C-based software systems that would have been avoided automatically by most other languages is evidence for that."
Just because Linux is buggy does not mean C isn't up to the task. The BSDs seem to be doing a much better job and when they have trouble it's usually with drivers that a higher level language wouldn't help.
a) IBM makes a LOT of chips. G5 fabrication is subsidized by all the other chips they make, many of them in larger numbers. G5 design work is subsidized by the POWER line of processors.
b) Intel processors are often left in the dust by AMD as well, which also have a smaller share of the market. Intel chips are indeed the suck, but x86 seems to be doing okay. Hell, Intel chips are left in the dust by other Intel chips. Pentium Ms give Pentium 4s a run for their money in some areas, and they can do it at 25 watts.
"This isn't theoretical: numerous operating systems have been implemented in safe, garbage collected languages, including Modula-3, Lisp, and Smalltalk."
They cannot match OSes like Solaris, Linux, and FreeBSD in terms of performance any more than microkernels can.
"Safety doesn't mean that you can't do unsafe things, it just means that you won't do unsafe things accidentally. C#, for example, has the same pointer manipulation primitives built-in as C."
Interesting. I didn't know that. I knew you could control allocations but I didn't know you could do pointer arithmetic.
"while C memory managers make no guarantees and are actually quite unpredictable in practice."
It's just a library. Kernel memory management routines meet the needs of the kernel.
"(Sun Java and Microsoft.NET are unsuitable implementations for writing a kernel, but with a good native code compiler, Java and C# are perfectly fine languages for implementing a kernel.)"
Conversely, good programming practices can keep security problems in the kernel to a minimum (eg OpenBSD), while some problems are universal to both. A dedication to security will meet with success with any language.
"...but Intel processors are the suck. If processors weren't a prime example of market lock-in there would be no reason to use any x86 (even AMD) over Power, or over 68k back in the day."
No reason? Not even when they're way faster?
Things are more even now, but a few years ago a dual-G4 could barely keep up with a single Pentium 4 or Athlon XP that cost about a third as much.
The disadvantage was so huge that people went through the expense and trouble of switching to an inferior OS just so they could get fast computers.
As I said, things have evened out now, but it's hardly a clear cut advantage. Apple cannot match the Centrino platform (Pentium M + Intel chipset) in laptops, on desktops x86 power usage has improved dramatically while G5s are approaching historical x86 heat levels. It has reached a point where G5s are sometimes the warmer chip, and Opterons have the edge in small servers (4 or less CPUs).
For the most part things are pretty even and the decision comes down to other things, like what OS you prefer, what software you have to run, etc. But there are certainly valid reasons to use x86.
"Check sandpile.org and see if you can made any sense in the instruction set."
"It's not the virtual machines that make Java and C# applications more secure, it's the fact that the languages are better designed than C and C++."
The fact that the VM can run applications in a sandbox helps.
"Until kernel designers kick the C/C++ habit, we are not going to get a decent kernel.
It's unfortunate that Java and C# (pretty decent language designs) happen to be implemented with such bloated runtimes by their main proponents. But that's not necessary: Java and C#-like languages can be implemented natively with pretty much the same efficiency as C and C++."
Well it depends what you're doing. They kernel has to do heavily architechture dependant things. It has to manage page tables and do I/O directly. You just can't do that in a managed language. The whole point of a managed language is that you don't do pointer manipulation directly. That makes C/C++ less safe, but it's also a necessary part of the kernel. In fact, kernels are one of the few places where it will never and can never go away.
You're also stuck with garbage collection even if you compile to native code. The kernel has to be as deterministic as possible, for stability as much as for speed. Garbage collection by definition is not deterministic. Ever wonder why the Java EULA requires that you agree not to use it in a nuclear reactor? That's why. They can't guarantee that it won't lock up when you're trying to click the "AVERT MELTDOWN" button.
Java and C# might be able to compete with C++ in terms of speed, but they can't touch hand-tuned C mixed with assembly, not for the sorts of thing that goes on in the kernel. Even C++ is of questionable merit in a kernel.
I love those guys. Their message isn't catching on fast enough to overcome the selection pressure against an idea that stupid, so all they're doing is reducing the number of people that care about the environment.
I've used Linux as my primary desktop OS for several years. I've gone through most of the mainstream distros (Suse, Mandrake, Slackware, Gentoo, Fedora, Debian, Ubuntu) and one thing has been universal: it wasn't that hard for me to set up, but I had to use the command line and I had to know things I couldn't reasonably expect an inexperienced user to know.
Getting a basic install on basic hardware is generally no problem, but whenever I try to do something fancy I have to do things manually. "Fancy" can mean dual monitors, playing videos with newer codecs, any number of things, generally different for the different distros.
I'm fine with that because I know those things and it meets my needs, but there's no way I'd recomend it to an inexperienced user. Some of them want dual monitors and new codecs too.
"Its secure and stable."
2.6 is not so much "secure and stable" as it is "a minefield of regressions". Too bad 2.4 won't boot on my hardware...
"You can use what ever hardware you want."
If by "use whatever hardware you want", you mean "carefully research the hardware before you buy it" then you are correct.
"So the difference between OpenBSD and FreeBSD (besides the maintainers of course) is more along the lines of politics (OpenBSD only allowing software in which meets their definition of free)."
No. There are many technical differences in addition to the political differences.
In general, FreeBSD picks features, compatability and performance first, while OpenBSD picks security and robustness first. Over time, that drift has left them in completely different positions.
The freedom of 3rd party software is somewhat a secondary issue. There are plenty of other problems with Apache, they have refused many security patches. It would basically be a fork either way.
"Do these two share between each other?"
Yes. All the BSDs use OpenSSH and PF from OpenBSD, OpenBSD got much of its SMP code from NetBSD, NetBSD got UFS2 from FreeBSD, and so on.
"Is there a common BSD kernel or anything like that?"
No. All the BSDs maintain their own kernel.
The closest two are probably OpenBSD and NetBSD. NetBSD performance optimizations make their way into OpenBSD pretty frequently, and security enhancements flow the other way just as often.
FreeBSD and NetBSD's common ancestor is way too far into the past for code to move that freely between their kernels. OpenBSD is a fork of NetBSD so it's in the same position.
DragonFlyBSD is a fork of FreeBSD, but it has drifted very quickly because the they've been making huge changes. AFAIK they can still port stuff from the FreeBSD kernel, but after a certain point "porting" becomes "using the other code as a guide for a rewrite" and I think they'll get there sooner rather than later.
If anything, I think it's more likely that Intel will start making PowerPC processors. IA-64 is relegated to a few profitable but limited areas. PowerPC is everywhere, and Intel could certainly keep up with IBM and Motorola if they were making compatible chips.
Slashdot Mirror
The next gen consoles have a substantial advantage over PCs because all their hardware is optimized specifically for games in ways that are mutually exclusive with good PC performance.
However, I wouldn't be all that surprised if graphics cards started getting console subsystems entirely on the card.
"AFAIK, it's not OpenBSD people who do the porting to Linux."
OpenBSD people do both OpenSSH and the portability goop.
"But is it good for the market? What is graphically feasible in a PC game isn't feasible in a game designed for a Palm OS device or a GBA system."
OTOH, the vast majority of Linux software is easily portable to all UNIXes.
For example, I strongly suspect most machines big enough to run AIX can handle GCC.
He's referring to FreeBSD.
Writing portable code is good for the soul.
It makes you read the docs. It forces you to use a standard API when byte order is important. It keeps you from hardcoding values (eg sizeof(void*)). It keeps you from making platform dependant optimizations that might not even be supported by the next version of the platform you're on, or if you do it forces you to make them modular.
It forces you to figure out what behavior you can rely on. Bug compatability with older versions relies on the magnanimity of the maintainer, and cannot be assumed even if you're staying on Linux.
There's nothing stopping them from doing that now.
I suppose the OpenBSD crowd should stop supporting those "other" platforms like Linux with OpenSSH.
"IMO the most notorious case is how the gcc development is held hostage by Edelsohn and maybe IBM as a whole by requesting that everything always works perfectly well on AIX. How often has one seen "this patch breaks AIX, back it out". It cannot reasonably be expected that everybody tests on AIX. It is an proprietary OS running on proprietary and expensive hardware which not many people have access to. The overall development speed could be significantly improved by dropping the AIX requirement which, in some form or another, has been agreed upon by the steering committee. AIX is irrelevant in general today, i.e., the situation changed. And the people in the steering committee are too nice to just tell the very small minority causing the problem to take a hike."
GCC is the de facto standard because it runs on more platforms than anybody else.
If it ceases to run on all these platforms, it will either:
a) fork a project that will support them
b) another compiler will take its place as the de facto standard
c) people will be forced to use whatever the default cc is on their OS.
In any of these cases, the portability concerns will get an order of magnitude worse.
That's very interesting. I didn't know they actually produced oil directly.
If it ever becomes comercially viable, I imagine the algae could be genetically engineered to produce even more oil.
Isn't it easier to produce methane directly from algae? That might not be quite as dense as other hydrocarbons, but it's not that bad and it's a lot better than hydrogen. It's also useful for producing oil from resources like the tar sands in Alberta (that requires a lot of natural gas eg methane).
"phonecrastinate"
You've got to be fucking kidding me. This is the first time I've ever seen that.
"The huge number of problems that keep cropping up in all C-based software systems that would have been avoided automatically by most other languages is evidence for that."
Just because Linux is buggy does not mean C isn't up to the task. The BSDs seem to be doing a much better job and when they have trouble it's usually with drivers that a higher level language wouldn't help.
a) IBM makes a LOT of chips. G5 fabrication is subsidized by all the other chips they make, many of them in larger numbers. G5 design work is subsidized by the POWER line of processors.
b) Intel processors are often left in the dust by AMD as well, which also have a smaller share of the market. Intel chips are indeed the suck, but x86 seems to be doing okay. Hell, Intel chips are left in the dust by other Intel chips. Pentium Ms give Pentium 4s a run for their money in some areas, and they can do it at 25 watts.
"This isn't theoretical: numerous operating systems have been implemented in safe, garbage collected languages, including Modula-3, Lisp, and Smalltalk."
.NET are unsuitable implementations for writing a kernel, but with a good native code compiler, Java and C# are perfectly fine languages for implementing a kernel.)"
They cannot match OSes like Solaris, Linux, and FreeBSD in terms of performance any more than microkernels can.
"Safety doesn't mean that you can't do unsafe things, it just means that you won't do unsafe things accidentally. C#, for example, has the same pointer manipulation primitives built-in as C."
Interesting. I didn't know that. I knew you could control allocations but I didn't know you could do pointer arithmetic.
"while C memory managers make no guarantees and are actually quite unpredictable in practice."
It's just a library. Kernel memory management routines meet the needs of the kernel.
"(Sun Java and Microsoft
Conversely, good programming practices can keep security problems in the kernel to a minimum (eg OpenBSD), while some problems are universal to both. A dedication to security will meet with success with any language.
"...but Intel processors are the suck. If processors weren't a prime example of market lock-in there would be no reason to use any x86 (even AMD) over Power, or over 68k back in the day."
No reason? Not even when they're way faster?
Things are more even now, but a few years ago a dual-G4 could barely keep up with a single Pentium 4 or Athlon XP that cost about a third as much.
The disadvantage was so huge that people went through the expense and trouble of switching to an inferior OS just so they could get fast computers.
As I said, things have evened out now, but it's hardly a clear cut advantage. Apple cannot match the Centrino platform (Pentium M + Intel chipset) in laptops, on desktops x86 power usage has improved dramatically while G5s are approaching historical x86 heat levels. It has reached a point where G5s are sometimes the warmer chip, and Opterons have the edge in small servers (4 or less CPUs).
For the most part things are pretty even and the decision comes down to other things, like what OS you prefer, what software you have to run, etc. But there are certainly valid reasons to use x86.
"Check sandpile.org and see if you can made any sense in the instruction set."
We've got these things called compilers...
Being right does not make a zealot any less annoying.
"It's not the virtual machines that make Java and C# applications more secure, it's the fact that the languages are better designed than C and C++."
The fact that the VM can run applications in a sandbox helps.
"Until kernel designers kick the C/C++ habit, we are not going to get a decent kernel.
It's unfortunate that Java and C# (pretty decent language designs) happen to be implemented with such bloated runtimes by their main proponents. But that's not necessary: Java and C#-like languages can be implemented natively with pretty much the same efficiency as C and C++."
Well it depends what you're doing. They kernel has to do heavily architechture dependant things. It has to manage page tables and do I/O directly. You just can't do that in a managed language. The whole point of a managed language is that you don't do pointer manipulation directly. That makes C/C++ less safe, but it's also a necessary part of the kernel. In fact, kernels are one of the few places where it will never and can never go away.
You're also stuck with garbage collection even if you compile to native code. The kernel has to be as deterministic as possible, for stability as much as for speed. Garbage collection by definition is not deterministic. Ever wonder why the Java EULA requires that you agree not to use it in a nuclear reactor? That's why. They can't guarantee that it won't lock up when you're trying to click the "AVERT MELTDOWN" button.
Java and C# might be able to compete with C++ in terms of speed, but they can't touch hand-tuned C mixed with assembly, not for the sorts of thing that goes on in the kernel. Even C++ is of questionable merit in a kernel.
"What kind of servers *ARE* these??"
I think Pixar may want one or two.
IBM together with Motorola and Apple created PowerPC. They've deserved an Apple fan's love for a while.
I love those guys. Their message isn't catching on fast enough to overcome the selection pressure against an idea that stupid, so all they're doing is reducing the number of people that care about the environment.
You could use heat exchangers at the surface to cool surface water.
I've used Linux as my primary desktop OS for several years. I've gone through most of the mainstream distros (Suse, Mandrake, Slackware, Gentoo, Fedora, Debian, Ubuntu) and one thing has been universal: it wasn't that hard for me to set up, but I had to use the command line and I had to know things I couldn't reasonably expect an inexperienced user to know.
Getting a basic install on basic hardware is generally no problem, but whenever I try to do something fancy I have to do things manually. "Fancy" can mean dual monitors, playing videos with newer codecs, any number of things, generally different for the different distros.
I'm fine with that because I know those things and it meets my needs, but there's no way I'd recomend it to an inexperienced user. Some of them want dual monitors and new codecs too.
"Its secure and stable."
2.6 is not so much "secure and stable" as it is "a minefield of regressions". Too bad 2.4 won't boot on my hardware...
"You can use what ever hardware you want."
If by "use whatever hardware you want", you mean "carefully research the hardware before you buy it" then you are correct.
"So the difference between OpenBSD and FreeBSD (besides the maintainers of course) is more along the lines of politics (OpenBSD only allowing software in which meets their definition of free)."
No. There are many technical differences in addition to the political differences.
In general, FreeBSD picks features, compatability and performance first, while OpenBSD picks security and robustness first. Over time, that drift has left them in completely different positions.
The freedom of 3rd party software is somewhat a secondary issue. There are plenty of other problems with Apache, they have refused many security patches. It would basically be a fork either way.
"Do these two share between each other?"
Yes. All the BSDs use OpenSSH and PF from OpenBSD, OpenBSD got much of its SMP code from NetBSD, NetBSD got UFS2 from FreeBSD, and so on.
"Is there a common BSD kernel or anything like that?"
No. All the BSDs maintain their own kernel.
The closest two are probably OpenBSD and NetBSD. NetBSD performance optimizations make their way into OpenBSD pretty frequently, and security enhancements flow the other way just as often.
FreeBSD and NetBSD's common ancestor is way too far into the past for code to move that freely between their kernels. OpenBSD is a fork of NetBSD so it's in the same position.
DragonFlyBSD is a fork of FreeBSD, but it has drifted very quickly because the they've been making huge changes. AFAIK they can still port stuff from the FreeBSD kernel, but after a certain point "porting" becomes "using the other code as a guide for a rewrite" and I think they'll get there sooner rather than later.
"two different C compiler installs because of kernel problems"
OpenBSD had GCC 2.9 and 3.x for a while. I think 3.7 is the first release in a while with just one C compiler.
"There are no large architecture changes"
What, like the IPF to PF transition? Or the a.out to ELF transition that broke all the old binaries?
OpenBSD is my OS of choice, but let's not kid ourselves. It has uphevals from time to time.
If anything, I think it's more likely that Intel will start making PowerPC processors. IA-64 is relegated to a few profitable but limited areas. PowerPC is everywhere, and Intel could certainly keep up with IBM and Motorola if they were making compatible chips.