I think you're proving my points for me. The statement was that the kernel/user space boundary is required for security reasons. The effectiveness of any specific implementation is moot. Its not moot. You can have protection in two ways. You can have a hardware-enforced boundry between userspace and kernelspace, or a compiler-enforced boundry between programs. I'd argue that the failure possibilities of the former are no less (and perhaps even greater than) the failure possibilities of the former. There are a lot of failure modes in the former (mainly, memory-related exploits in priveledged code) that do not exist in the latter.
Code signing is not a valid solution since you are assuming the signer is not malicious. The code would be signed by the compiler. It is assumed that the compiler is trusted, just as, in a traditional model, it is assumed that the kernel in trusted. There would be a guarantee that no matter what input there was to the compiler, the output would be safe. Now, one could exploit bugs in the implementation of the compiler, but that'd be no different from exploiting a bug in a system-call implementation in a kernel. The advantage of this model is that memory-related security is in a limited portion of the compiler. As long as that is correct, security is guaranteed.
Finally, if your implementation of lisp allows you to break out to assembly, then you're already out of the sandbox, meaning that is possible to run unsafe code. Nobody says the same dialect of Lisp needs to be used for all code. It would be entirely sensible to have a seperate "unsafe" dialect for (rare) code that requires it. Given practical realities, an implementation of such a machine would have to have a hardware-level sandboxes for not just for unsafe Lisp programs, but for programs written in languages (like C) that cannot efficiently be made safe. Such sandboxes would behave identically to protected memory spaces in current machines.
This arrangement works out quite nicely. Programs these days rarely need to drop down into ASM, and can thus be run in the "safe-code" region, benefiting from the attendant performance improvement. For GUI and server apps, this improvement can be very significant, since a lot of communication overhead is eliminated. Unsafe code would have the additional overhead of communication out of its protected domain, but that is what *every* program has to do on current machines.
It may be correct in theory but in practice it is not true. Sandboxes can be circumvented. So can the kernel userspace boundary. There have been 3 such exploits just in the 2.6 release of Linux!
Compiled code, whether from lisp source or C, can be modified such that it compromises the system. Such a system would necessarily disallow direct manipulation of binaries, probably through some form of code-signing. Its not an insurmountable problem at all.
C will always win because it is always possible to take C to the next level - ultimately to assembly itself - if necessary. With lisp, the point of diminishing returns is reached sooner and is unbreachable. Any code you can write in C, you can write in a Lisp (perhaps not Common Lisp, but with extensions). You can disable GC in critical regions, you can get at the raw bytes of buffers, etc. And you can always break out the assembly when writing C code, but you can do that for Lisp code too!
Lisp code is real pretty, once you get used to the parens. Certainly, parens are a lot more pretty than curly-braces:-/ And since every Lisp IDE worth using auto-completes parens, it really doesn't bother you. Since Lisp programmers use indentation to show structure, the perens don't really hurt readability. In any case, they are good reason. Its makes procedural macros much easier and more powerful to use.
And Lisp and Scheme are the only prefix languages in my Lisp. ML and Dylan are infix languages.
heh.. reading time generally means going out on the bus (The south bridge in PCI architecture) and hitting a timer chip. Not on anything more recent than a Pentium. They've got a time-stamp counter that can be read from in a few clock-cycles.
Not a function of your C compiler, try again. No, a function of the fact that there is a kernel userspace boundry, necessitated by the fact that C code can, by error or maliciousness, corrupt memory. Switching from userspace to kernel space costs 500-600 clock cycles on my P4. The fastest its ever been on recent x86 processors is about 150 clock cycles on the P6 series. A single system call negates the advantage of a whole bunch of saved array checks!
As for a safe language, that is a nice utopian ideal, but thank goodness that MS didn't write windows in it. Can you imagine all the Virus and trojan horses? Don't you think there would be fewer viruses and trojan horses given a language in which buffer-overflows cannot occur? Where array-overflows cannot occur? Its much easier to get the compiler's range-checking code correct than to write tons of C programs free of memory-related security errors.
Memory management is a must. What about the case where a removable device failes to work because of a bad contact? With an MMU this is fairly trivial to kill the whole process and cleanup the bus. I don't get this example. There is no difference here between the MMU and safe-language case. Hardware devices are not protected via the MMU, so a misbehaving hardware device would corrupt random memory, and thus require a restart of the system. If, instead, it just confused a process talking to it, you could still kill it in a safe language, and the GC would clean up all the resources used by the killed process.
This is precisely the kind of thing that separates computer science, that division of mathematics that deals with algorithms and computational theory, from engineering which deals with real-world solutions to real-world implementation problems. I don't see how that applies here. Hardware-level page protection isn't a theoretical technique, its an implementation technique. We're talking about two engineering problems here. One does protection in hardware, the other does it in software. The former is vulnerable to bugs, just as the latter if vulnerable to bugs.
If you think that implementing a program in lisp is going to be so inherently secure that there is no need for hardware-level page protection, you are sorely mistaken. Malicious code exists, even in Lisp. Its not a matter of Lisp code being inherently secure. Its a matter of Lisp having no pointers, and having type and array bounds checks. Assuming no bugs in these parts of the compiler (just as we assume no bugs in the implementation of the hardware MMU!) a Lisp runtime should provide protection equivilent to a hardware MMU. Now, malicious code can exploit bugs in the runtime, but are you claiming that no C kernels have such exploitable bugs?
Outside of C and assembly, nothing is comparable for speed. If you're seeing similar execution times from lisp and Java, then you're doing something so trivial as to be uninteresting or something is wrong with your C implementation. Or you just have a really smart compiler. And Lisp compilers are really smart. If you write low-level code in Lisp (as you would in C), you'll can get equivilent performance. Since most Lisp compilers compile to native code, there is no reason to expect that they'd be any slower than other native-code compilers. And it must be noted that Lisp code can be faster than C code in practical situations. Often, where C code is generic (eg: qsort() in the standard library), Lisp compilers can emit specialized-functions for a given type. Since Lisp code has more high-level semantic information than C code, it is possible for a Lisp compiler to perform better high-level optimizations.
Unsafe pointers are for the kernel to use, not userspace apps. Its okay if the kernel can crash the system, not if userspace apps can do so. Userspace apps cannot use unsafe pointers.
You don't switch between static and dynamic typing. Rather, you have dynamic typing, and optionally add type declarations in places where you want to tighten the interface or improve performance. There will be some runtime type checks, but modern compiler analysis can eliminate most of those checks. And what's wrong with type inferencing in your kernel? Type inferencing all happens at compile-time!
And the "raw core" they're talking about is not a low-level, close-to-hardware core, but a conceptually primitive core. The idea is that there is a simple base language to which both high and low level features can be added.
Strictly, Crush will have more overhead than C. However, given a good compiler, and well-written, straight-forward code, it is possible to achieve close to C performance for high-level languages like Crush. In some cases (things like generic data structures, where specializations can be used) performance can be even better.
Also note that while a kernel written in Crush might be 10-20% slower in raw performance, it makes up for it in other ways. For example, system calls won't have a huge overhead (hundreds of clock cycles on most modern kernels). Data doesn't keep having to be copied around. You don't have to put things like the X server in a seperate process to provide protection.
Well, there are a lot of performance-related things you can do in C++ that you cannot do in C. For example, you can have well-optimized generic containers. Generic containers in C are usually slow, because they're based on void-pointers and use function pointers as predicates. In contrast, templated containers compile to code specialized for each type, with predicates inlined. Unless you are willing to maintain seperate containers for each type in your code, it ends up being faster to use the templated containers in C++.
You could complain about C all day, the problem is, it's the best thing we have right now. Hardly.
One of the problem with modern languages is, you can't write an operating system in them. Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project for an OS written in a safe language.
One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code. I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.
We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.
No we won't. Even by your own arguments, "lower skilled" stuff will go abroad. Its a matter of our workers having the necessary "low skills" and their workers not having the relevent skills at all. It can be expensive even to train a relatively lower-skilled worker.
They DO have the money. If they had the money, they wouldn't be so cheap to outsource to!
You keep hanging onto a myth that universities in this country are more advanced that in other countries. It is simply not true (first hand observation). It is widely acknowledged that we have the best University system in the world. More importantly, they are the richest universities in the world, and have a lot more money to spend on expensive training of this sort than universities in India or China. Developing nations just can't get together the type of cash necessary to not only train workers in fields requiring high capital investment, but to train enough of them to have an impact on our job market.
Maybe not tommorow, maybe not next year, but soon. For them to have enough money to invest in training programs for advanced technologies, at a scale large enough to produce enough graduates to make a significant impact on the US market, their GDP must increase significantly. If that happens, most of their cost advantages are lost. You are basically assuming that "soon" India will be able to afford to spend as much money as we do on education, and that is just not the case.
(in part thanks to all the cash we send over there - heard anything about a little trade deficit problem we have?) We have a trade deficit, but its not widely acknowledged as a problem among economists. The thing that most people fail to remember when talking about "trade deficits" is that they are not deficits in the traditional sense. Each transaction is even. If they get $100 in cash, we get $100 worth of goods. So the fact that we maintain a trade deficit does not mean we are pumping value into their economy. This is especially true considering the types of things we buy from these countries. They are not high-margin, high-profit items.
Advanced research may indeed stay in this country for the time being. I'm not just talking about advanced research. I'm talking about all the professions that require expensive equipment for training. Consider for a moment why India has been so successful at churning out computer programmers. Because computers are cheap! It is not at all capital-intensive to train a computer programmer. But consider other types of engineers: materials engineers, polymers engineers, industrial engineers, chemical engineers, etc. The market has been wide open for those jobs to be shipped overseas for awhile now. Why haven't they? Because those types of engineers require lots of capital resources to train, and India and China do not have lots of capital resources.
I am talking about the jobs for the "average american". As technology changes, the jobs for which "average Americans" are suitable for will change. Consider what will happen if nanotech really takes off in the next few decades. We will have lots of jobs available for lower-skilled people in nanotech. After all, not everybody who works on a plane is an aerospace engineer! Do you think Indian schools will be churning out skilled nanotech workers when they haven't the resources to invest in nanotechnology infrastructure? Hell no!
What you're seeing here with programmers and support techs cannot be easily generalized to other fields. The fact that many people *are* generalizing this phenomena and saying "oh, all the white-collar jobs are going away" is why I tend to think of the whole lot of them as "Chicken Little" types. Consider what programmers and techs do: they are knowledge workers. Knowledge work is something India and China can do very well. They've got lots of available labor (human capital), and good educational systems for the traditional (math, science, etc) disciplines. What they don't have is a lot of physical capital. Programmers and techs don't require a lot of physical capital to train --- just human capital. Ergo, China and India can take advantage of their low cost of living to compete in these markets. But most markets are not like this. Most markets *do* require significant investments of physical capital for training. And India and China will not be able to compete effectively in those markets.
People in India, by and large, don't have advanced skills in biotech/nanotech. Why? Because its expensive to acquire those skills. That's why "any and all desk jobs" are not leaving the US. Programming left because the equipment required to teach programmers is relatively cheap. Thus, India was able to churn out programmers like there was no tomorrow. In contrast, equipment required to train other types of white-coller workers (eg: computer-controlled mills, wind-tunnels, DNA synthesizers, etc) are expensive. Even if they send students to the US to learn, they cannot pump out the sheer volume of workers like they've been able to do in the programming market. Eventually, these jobs too will become commoditized, but there will always be jobs that require too much capital investment in training for countries like India to compete for, and thus rich countries like the US will always be able to specialize in them.
"Companies in this country keep forgetting that the people they are taking the jobs away from ARE their customers." Well, the people they are giving jobs too are also their customers. And the fact that they can lower prices by saving on labor means that all of their customers will have more money, potentially to spend on buying more of their products.
Re:Linux Has Travelled Far... In The Wrong Directi
on
Linus on Linux in 1994
·
· Score: 2, Informative
Actually, in some 3D design niches (the really high-end) Linux is better than Windows. That's why a lot of movie studios (eg. ILM) are using it.
1) Education has everything to do with it. You can't outsource biotech/nanotech jobs to India if nobody has the requisite skills. Training biotech/nanotech people takes lots of expensive equipment, which India cannot afford to buy. If/when they do, they won't be so much cheaper than us, will they? There will always be capital-intensive things to do, and in those things, we will always have an edge.
2) It has nothing to do with having "a soul." Saving one person's job here in the US means taking a lot of money out of everyone elses pockets. Its more efficient to just raise taxes and put the guy on welfare! So how does "saving" a job here in the US indicate having more of a soul than sending it overseas? In the end, you're giving the job to *someone*, but in the latter case, you're not robbing your customers in the process.
I go to school in Atlanta, and Georgia reminds me a lot of Bangladesh. The first summer I was there, it rained every day that week. Like fricking monsoon season. And during the summer, every building with an AC has it cranked up as high as it'll go, even though that makes the inside ridiculously cold. The only other place I've ever seen that is Bangladesh. And don't get me started on all the homeless people. Eh, at least the power is reliable:)
You also have to take into account that not only do drives differ in areal density, but the number of platters. Hitachi did not achieve this huge size by upping the areal density. It achieved the 400GB mark by shoving 5 80GB platters onto the drive. You cannot put 5 platters onto a laptop drive. Thus, you have two types of gains: increases in areal density, and increases in # of platters. The increases in # of platters is cyclical. When the areal density jumps up, the number of platters will go down. While areal density stays fixed, manufacturing processes improve, and drive makers compete, the number of platters will increase. The laptop drive market will only reflect increases in areal density, not the number of platters. So you'll see laptop drives jump up in capacity sporadically, because they can't do gradual increases by increasing the number of platters.
I use an Inspiron 8200 as my main desktop, for the following reasons:
1) I love laptop keyboards. Nice, compact, with a soft touch. I've got girly hands so it suits me just fine.
2) The 1600x1200 15" flat panel rocks for coding. Text is ridiculously sharp, clear, and well-formed.
3) Its reasonably powerful (2GHz, 640MB of RAM).
4) I have my Klipsch 4.1's hooked up to my iPod, not the terrible, noisy audio-out on the laptop. The built-in speakers are ok for Kopete yelling "beep" at me when I get an IM.
The LCD, in particular is a god-send. Its small, but in the two years I've had the laptop, I haven't gotten a headache as a result of using the computer a single time. I can stare at it for half the day without any ill-effects.
I know unrestrained cynicism is the "in-thing" among nerds these days, but this statement is silly:
"In all of this it is clear that the Government can lose track of a lot of money easily and even large companies are not above a little fraud now and then."
They can't both be at fault here! I mean, its not physically possible. The Canadian government could not have lost products if HP never gave them any!
I'm not saying that the ATI drivers aren't solid and usable. I'm saying that they're not good *3D* drivers. The whole point of a 3D card is to run 3D code, fast. The DRI drivers do not do that. Thus, the DRI people have not proven they could do better drivers than ATI.
In my experience, the NVIDIA drivers, though they may be binary-only, *do* do that. I've used the NVIDIA drivers variously on a Riva TNT, GeForce2 MX, and GeForce4 Go, and I've never had a stability issue with any of them. In the benchmarks, they are every bit as fast as the Windows drivers. Certainly, ILM thinks highly enough of them to run them on their 3D workstations! They do what a 3D driver is supposed to do --- run 3D code fast.
That argument makes no sense. Since the drivers would be open source, they could roll back those changes. Driver quality plays a big role in the 3D card market, and having faster drivers would then help them sell *more* hardware, and it would be a net win for them.
The simple fact of the matter is that the DRI folks have been given the specs to ATI hardware (R100 and R200) and have not been able to come up with drivers that are any more than drastically inferior to the ATI or XiG ones. That's especially sad considering that ATI's Linux binary drivers are quite a bit worse than their Windows binary drivers!
As far as I'm concerned, there are two good channels on the basic lineup: Food Network (Iron Chef, Good Eats) and Comedy Central (Daily Show, Chapelle's Show). By the looks of it, Dish Network is removing half of the good programming on their lineup!
And to reiterate --- an OpenGL driver is an order of magnitude more complex than a network driver! NVIDIA open-sourcing their OpenGL driver would be the equivilent of Microsoft open-sourcing Direct3D!
That'd suck. I *hate* file browsers. Currently, opening a file involves:
File -> Open -> Select File
With a file browser system, it would be:
Un-maximize word processor -> open browser app -> find folder -> position windows for drag & drop -> drag & drop
There are additional problems. From my experience with Windows users:
1) They don't understand drag & drop 2) They don't understand hierarchical filesystems
They think in terms of applications, not files. They want to open a Word document? They open Word, then open the document from the dialog.
Drag & drop based file selectors is just one of those inefficient holdbacks from when computers needed to model the "real world" by making everything appear to be physical manipulation.
The FD.O X server runs existing X apps just fine. Since it was based on the already-working kdrive server, it should be working (varying degrees of "working") through most of its development cycle.
You're the one who isn't reading it right. The quote you cite is referring to *2D* performance, not 3D performance. Yes, it makes sense that the DRI folks would know XAA better than ATI. Also, its well-known that modern GUIs don't take advantage of a fraction of the acceleration primitives offered by X (mostly because they're obsolete). If you take a look at how ATI does in the important benchmarks (bitblits, fills, line drawing) they don't fare so bad.
More importantly, take a look at the 3D numbers. In many cases, especially in high-detail scenes in SpecViewPerf or high-resolution scenes in the gaming benchmarks, the ATI drivers are twice as fast as the DRI drivers. The DRI drivers also had the most rendering errors of any of the drivers.
Slashdot Mirror
I think you're proving my points for me. The statement was that the kernel/user space boundary is required for security reasons. The effectiveness of any specific implementation is moot.
Its not moot. You can have protection in two ways. You can have a hardware-enforced boundry between userspace and kernelspace, or a compiler-enforced boundry between programs. I'd argue that the failure possibilities of the former are no less (and perhaps even greater than) the failure possibilities of the former. There are a lot of failure modes in the former (mainly, memory-related exploits in priveledged code) that do not exist in the latter.
Code signing is not a valid solution since you are assuming the signer is not malicious.
The code would be signed by the compiler. It is assumed that the compiler is trusted, just as, in a traditional model, it is assumed that the kernel in trusted. There would be a guarantee that no matter what input there was to the compiler, the output would be safe. Now, one could exploit bugs in the implementation of the compiler, but that'd be no different from exploiting a bug in a system-call implementation in a kernel. The advantage of this model is that memory-related security is in a limited portion of the compiler. As long as that is correct, security is guaranteed.
Finally, if your implementation of lisp allows you to break out to assembly, then you're already out of the sandbox, meaning that is possible to run unsafe code.
Nobody says the same dialect of Lisp needs to be used for all code. It would be entirely sensible to have a seperate "unsafe" dialect for (rare) code that requires it. Given practical realities, an implementation of such a machine would have to have a hardware-level sandboxes for not just for unsafe Lisp programs, but for programs written in languages (like C) that cannot efficiently be made safe. Such sandboxes would behave identically to protected memory spaces in current machines.
This arrangement works out quite nicely. Programs these days rarely need to drop down into ASM, and can thus be run in the "safe-code" region, benefiting from the attendant performance improvement. For GUI and server apps, this improvement can be very significant, since a lot of communication overhead is eliminated. Unsafe code would have the additional overhead of communication out of its protected domain, but that is what *every* program has to do on current machines.
It may be correct in theory but in practice it is not true. Sandboxes can be circumvented.
So can the kernel userspace boundary. There have been 3 such exploits just in the 2.6 release of Linux!
Compiled code, whether from lisp source or C, can be modified such that it compromises the system.
Such a system would necessarily disallow direct manipulation of binaries, probably through some form of code-signing. Its not an insurmountable problem at all.
C will always win because it is always possible to take C to the next level - ultimately to assembly itself - if necessary. With lisp, the point of diminishing returns is reached sooner and is unbreachable.
Any code you can write in C, you can write in a Lisp (perhaps not Common Lisp, but with extensions). You can disable GC in critical regions, you can get at the raw bytes of buffers, etc. And you can always break out the assembly when writing C code, but you can do that for Lisp code too!
Lisp code is real pretty, once you get used to the parens. Certainly, parens are a lot more pretty than curly-braces :-/ And since every Lisp IDE worth using auto-completes parens, it really doesn't bother you. Since Lisp programmers use indentation to show structure, the perens don't really hurt readability. In any case, they are good reason. Its makes procedural macros much easier and more powerful to use.
And Lisp and Scheme are the only prefix languages in my Lisp. ML and Dylan are infix languages.
heh.. reading time generally means going out on the bus (The south bridge in PCI architecture) and hitting a timer chip.
Not on anything more recent than a Pentium. They've got a time-stamp counter that can be read from in a few clock-cycles.
Not a function of your C compiler, try again.
No, a function of the fact that there is a kernel userspace boundry, necessitated by the fact that C code can, by error or maliciousness, corrupt memory. Switching from userspace to kernel space costs 500-600 clock cycles on my P4. The fastest its ever been on recent x86 processors is about 150 clock cycles on the P6 series. A single system call negates the advantage of a whole bunch of saved array checks!
As for a safe language, that is a nice utopian ideal, but thank goodness that MS didn't write windows in it. Can you imagine all the Virus and trojan horses?
Don't you think there would be fewer viruses and trojan horses given a language in which buffer-overflows cannot occur? Where array-overflows cannot occur? Its much easier to get the compiler's range-checking code correct than to write tons of C programs free of memory-related security errors.
Memory management is a must. What about the case where a removable device failes to work because of a bad contact? With an MMU this is fairly trivial to kill the whole process and cleanup the bus.
I don't get this example. There is no difference here between the MMU and safe-language case. Hardware devices are not protected via the MMU, so a misbehaving hardware device would corrupt random memory, and thus require a restart of the system. If, instead, it just confused a process talking to it, you could still kill it in a safe language, and the GC would clean up all the resources used by the killed process.
This is precisely the kind of thing that separates computer science, that division of mathematics that deals with algorithms and computational theory, from engineering which deals with real-world solutions to real-world implementation problems.
I don't see how that applies here. Hardware-level page protection isn't a theoretical technique, its an implementation technique. We're talking about two engineering problems here. One does protection in hardware, the other does it in software. The former is vulnerable to bugs, just as the latter if vulnerable to bugs.
If you think that implementing a program in lisp is going to be so inherently secure that there is no need for hardware-level page protection, you are sorely mistaken. Malicious code exists, even in Lisp.
Its not a matter of Lisp code being inherently secure. Its a matter of Lisp having no pointers, and having type and array bounds checks. Assuming no bugs in these parts of the compiler (just as we assume no bugs in the implementation of the hardware MMU!) a Lisp runtime should provide protection equivilent to a hardware MMU. Now, malicious code can exploit bugs in the runtime, but are you claiming that no C kernels have such exploitable bugs?
Outside of C and assembly, nothing is comparable for speed. If you're seeing similar execution times from lisp and Java, then you're doing something so trivial as to be uninteresting or something is wrong with your C implementation.
Or you just have a really smart compiler. And Lisp compilers are really smart. If you write low-level code in Lisp (as you would in C), you'll can get equivilent performance. Since most Lisp compilers compile to native code, there is no reason to expect that they'd be any slower than other native-code compilers. And it must be noted that Lisp code can be faster than C code in practical situations. Often, where C code is generic (eg: qsort() in the standard library), Lisp compilers can emit specialized-functions for a given type. Since Lisp code has more high-level semantic information than C code, it is possible for a Lisp compiler to perform better high-level optimizations.
What are you talking about?
Unsafe pointers are for the kernel to use, not userspace apps. Its okay if the kernel can crash the system, not if userspace apps can do so. Userspace apps cannot use unsafe pointers.
You don't switch between static and dynamic typing. Rather, you have dynamic typing, and optionally add type declarations in places where you want to tighten the interface or improve performance. There will be some runtime type checks, but modern compiler analysis can eliminate most of those checks. And what's wrong with type inferencing in your kernel? Type inferencing all happens at compile-time!
And the "raw core" they're talking about is not a low-level, close-to-hardware core, but a conceptually primitive core. The idea is that there is a simple base language to which both high and low level features can be added.
Strictly, Crush will have more overhead than C. However, given a good compiler, and well-written, straight-forward code, it is possible to achieve close to C performance for high-level languages like Crush. In some cases (things like generic data structures, where specializations can be used) performance can be even better.
Also note that while a kernel written in Crush might be 10-20% slower in raw performance, it makes up for it in other ways. For example, system calls won't have a huge overhead (hundreds of clock cycles on most modern kernels). Data doesn't keep having to be copied around. You don't have to put things like the X server in a seperate process to provide protection.
Well, there are a lot of performance-related things you can do in C++ that you cannot do in C. For example, you can have well-optimized generic containers. Generic containers in C are usually slow, because they're based on void-pointers and use function pointers as predicates. In contrast, templated containers compile to code specialized for each type, with predicates inlined. Unless you are willing to maintain seperate containers for each type in your code, it ends up being faster to use the templated containers in C++.
You could complain about C all day, the problem is, it's the best thing we have right now.
Hardly.
One of the problem with modern languages is, you can't write an operating system in them.
Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project for an OS written in a safe language.
One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code.
I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.
Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable.
Common Lisp
Another Common Lisp
Ocaml
Scheme
Dylan
Another Dylan
We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.
No we won't. Even by your own arguments, "lower skilled" stuff will go abroad.
Its a matter of our workers having the necessary "low skills" and their workers not having the relevent skills at all. It can be expensive even to train a relatively lower-skilled worker.
They DO have the money.
If they had the money, they wouldn't be so cheap to outsource to!
You keep hanging onto a myth that universities in this country are more advanced that in other countries. It is simply not true (first hand observation).
It is widely acknowledged that we have the best University system in the world. More importantly, they are the richest universities in the world, and have a lot more money to spend on expensive training of this sort than universities in India or China. Developing nations just can't get together the type of cash necessary to not only train workers in fields requiring high capital investment, but to train enough of them to have an impact on our job market.
Maybe not tommorow, maybe not next year, but soon.
For them to have enough money to invest in training programs for advanced technologies, at a scale large enough to produce enough graduates to make a significant impact on the US market, their GDP must increase significantly. If that happens, most of their cost advantages are lost. You are basically assuming that "soon" India will be able to afford to spend as much money as we do on education, and that is just not the case.
(in part thanks to all the cash we send over there - heard anything about a little trade deficit problem we have?)
We have a trade deficit, but its not widely acknowledged as a problem among economists. The thing that most people fail to remember when talking about "trade deficits" is that they are not deficits in the traditional sense. Each transaction is even. If they get $100 in cash, we get $100 worth of goods. So the fact that we maintain a trade deficit does not mean we are pumping value into their economy. This is especially true considering the types of things we buy from these countries. They are not high-margin, high-profit items.
Advanced research may indeed stay in this country for the time being.
I'm not just talking about advanced research. I'm talking about all the professions that require expensive equipment for training. Consider for a moment why India has been so successful at churning out computer programmers. Because computers are cheap! It is not at all capital-intensive to train a computer programmer. But consider other types of engineers: materials engineers, polymers engineers, industrial engineers, chemical engineers, etc. The market has been wide open for those jobs to be shipped overseas for awhile now. Why haven't they? Because those types of engineers require lots of capital resources to train, and India and China do not have lots of capital resources.
I am talking about the jobs for the "average american".
As technology changes, the jobs for which "average Americans" are suitable for will change. Consider what will happen if nanotech really takes off in the next few decades. We will have lots of jobs available for lower-skilled people in nanotech. After all, not everybody who works on a plane is an aerospace engineer! Do you think Indian schools will be churning out skilled nanotech workers when they haven't the resources to invest in nanotechnology infrastructure? Hell no!
What you're seeing here with programmers and support techs cannot be easily generalized to other fields. The fact that many people *are* generalizing this phenomena and saying "oh, all the white-collar jobs are going away" is why I tend to think of the whole lot of them as "Chicken Little" types. Consider what programmers and techs do: they are knowledge workers. Knowledge work is something India and China can do very well. They've got lots of available labor (human capital), and good educational systems for the traditional (math, science, etc) disciplines. What they don't have is a lot of physical capital. Programmers and techs don't require a lot of physical capital to train --- just human capital. Ergo, China and India can take advantage of their low cost of living to compete in these markets. But most markets are not like this. Most markets *do* require significant investments of physical capital for training. And India and China will not be able to compete effectively in those markets.
People in India, by and large, don't have advanced skills in biotech/nanotech. Why? Because its expensive to acquire those skills. That's why "any and all desk jobs" are not leaving the US. Programming left because the equipment required to teach programmers is relatively cheap. Thus, India was able to churn out programmers like there was no tomorrow. In contrast, equipment required to train other types of white-coller workers (eg: computer-controlled mills, wind-tunnels, DNA synthesizers, etc) are expensive. Even if they send students to the US to learn, they cannot pump out the sheer volume of workers like they've been able to do in the programming market. Eventually, these jobs too will become commoditized, but there will always be jobs that require too much capital investment in training for countries like India to compete for, and thus rich countries like the US will always be able to specialize in them.
"Companies in this country keep forgetting that the people they are taking the jobs away from ARE their customers."
Well, the people they are giving jobs too are also their customers. And the fact that they can lower prices by saving on labor means that all of their customers will have more money, potentially to spend on buying more of their products.
Actually, in some 3D design niches (the really high-end) Linux is better than Windows. That's why a lot of movie studios (eg. ILM) are using it.
Damn. I remember reading a Byte magazine from 1994. If it was to be believed:
1) A plethora of CPU architectures (MIPS, SPARC, PowerPC, and Alpha) would replace x86, and compete against each other.
2) We'd have fully document-oriented interfaces thanks to technologies like SOM and OpenDoc.
3) We'd be running fully object-oriented microkernels built in C++ (Taligent).
Yet, the up-and-coming technologies of today are: a rehash of the 8086 (x86-64), a rehash of UNIX (Linux), and fucking *Java*...
1) Education has everything to do with it. You can't outsource biotech/nanotech jobs to India if nobody has the requisite skills. Training biotech/nanotech people takes lots of expensive equipment, which India cannot afford to buy. If/when they do, they won't be so much cheaper than us, will they? There will always be capital-intensive things to do, and in those things, we will always have an edge.
2) It has nothing to do with having "a soul." Saving one person's job here in the US means taking a lot of money out of everyone elses pockets. Its more efficient to just raise taxes and put the guy on welfare! So how does "saving" a job here in the US indicate having more of a soul than sending it overseas? In the end, you're giving the job to *someone*, but in the latter case, you're not robbing your customers in the process.
I go to school in Atlanta, and Georgia reminds me a lot of Bangladesh. The first summer I was there, it rained every day that week. Like fricking monsoon season. And during the summer, every building with an AC has it cranked up as high as it'll go, even though that makes the inside ridiculously cold. The only other place I've ever seen that is Bangladesh. And don't get me started on all the homeless people. Eh, at least the power is reliable :)
You also have to take into account that not only do drives differ in areal density, but the number of platters. Hitachi did not achieve this huge size by upping the areal density. It achieved the 400GB mark by shoving 5 80GB platters onto the drive. You cannot put 5 platters onto a laptop drive. Thus, you have two types of gains: increases in areal density, and increases in # of platters. The increases in # of platters is cyclical. When the areal density jumps up, the number of platters will go down. While areal density stays fixed, manufacturing processes improve, and drive makers compete, the number of platters will increase. The laptop drive market will only reflect increases in areal density, not the number of platters. So you'll see laptop drives jump up in capacity sporadically, because they can't do gradual increases by increasing the number of platters.
I use an Inspiron 8200 as my main desktop, for the following reasons:
1) I love laptop keyboards. Nice, compact, with a soft touch. I've got girly hands so it suits me just fine.
2) The 1600x1200 15" flat panel rocks for coding. Text is ridiculously sharp, clear, and well-formed.
3) Its reasonably powerful (2GHz, 640MB of RAM).
4) I have my Klipsch 4.1's hooked up to my iPod, not the terrible, noisy audio-out on the laptop. The built-in speakers are ok for Kopete yelling "beep" at me when I get an IM.
The LCD, in particular is a god-send. Its small, but in the two years I've had the laptop, I haven't gotten a headache as a result of using the computer a single time. I can stare at it for half the day without any ill-effects.
I know unrestrained cynicism is the "in-thing" among nerds these days, but this statement is silly:
"In all of this it is clear that the Government can lose track of a lot of money easily and even large companies are not above a little fraud now and then."
They can't both be at fault here! I mean, its not physically possible. The Canadian government could not have lost products if HP never gave them any!
I'm not saying that the ATI drivers aren't solid and usable. I'm saying that they're not good *3D* drivers. The whole point of a 3D card is to run 3D code, fast. The DRI drivers do not do that. Thus, the DRI people have not proven they could do better drivers than ATI.
In my experience, the NVIDIA drivers, though they may be binary-only, *do* do that. I've used the NVIDIA drivers variously on a Riva TNT, GeForce2 MX, and GeForce4 Go, and I've never had a stability issue with any of them. In the benchmarks, they are every bit as fast as the Windows drivers. Certainly, ILM thinks highly enough of them to run them on their 3D workstations! They do what a 3D driver is supposed to do --- run 3D code fast.
That argument makes no sense. Since the drivers would be open source, they could roll back those changes. Driver quality plays a big role in the 3D card market, and having faster drivers would then help them sell *more* hardware, and it would be a net win for them.
The simple fact of the matter is that the DRI folks have been given the specs to ATI hardware (R100 and R200) and have not been able to come up with drivers that are any more than drastically inferior to the ATI or XiG ones. That's especially sad considering that ATI's Linux binary drivers are quite a bit worse than their Windows binary drivers!
As far as I'm concerned, there are two good channels on the basic lineup: Food Network (Iron Chef, Good Eats) and Comedy Central (Daily Show, Chapelle's Show). By the looks of it, Dish Network is removing half of the good programming on their lineup!
And to reiterate --- an OpenGL driver is an order of magnitude more complex than a network driver! NVIDIA open-sourcing their OpenGL driver would be the equivilent of Microsoft open-sourcing Direct3D!
That'd suck. I *hate* file browsers. Currently, opening a file involves:
File -> Open -> Select File
With a file browser system, it would be:
Un-maximize word processor -> open browser app -> find folder -> position windows for drag & drop -> drag & drop
There are additional problems. From my experience with Windows users:
1) They don't understand drag & drop
2) They don't understand hierarchical filesystems
They think in terms of applications, not files. They want to open a Word document? They open Word, then open the document from the dialog.
Drag & drop based file selectors is just one of those inefficient holdbacks from when computers needed to model the "real world" by making everything appear to be physical manipulation.
The FD.O X server runs existing X apps just fine. Since it was based on the already-working kdrive server, it should be working (varying degrees of "working") through most of its development cycle.
You're the one who isn't reading it right. The quote you cite is referring to *2D* performance, not 3D performance. Yes, it makes sense that the DRI folks would know XAA better than ATI. Also, its well-known that modern GUIs don't take advantage of a fraction of the acceleration primitives offered by X (mostly because they're obsolete). If you take a look at how ATI does in the important benchmarks (bitblits, fills, line drawing) they don't fare so bad.
More importantly, take a look at the 3D numbers. In many cases, especially in high-detail scenes in SpecViewPerf or high-resolution scenes in the gaming benchmarks, the ATI drivers are twice as fast as the DRI drivers. The DRI drivers also had the most rendering errors of any of the drivers.