We're talking about desktop systems. That means if you choose "Medium Security" or above in your Linux installer, things should pretty much be set up correctly already. Also, in addition to all the things you listed for Windows, you have to add programs like OpenOffice, Aol Instant Messenger, DivX codec, and all the other assorted programs commonly used on Windows desktops. All those come pre-installed in a Linux setup.
It has nothing to do with the "approval" of the FSF. The GPL defines certain terms, the CDDL defines certain terms, and the two just aren't compatible. The FSF can't "change" its "attitude" about the CDDL any more than it can retroactively change the licensing of the enormous amount of code that has been put under the GPL over the last decade.
I love how twits like you spin this as a fault of the FSF. What were they supposed to do? Prognosticate the terms of the CDDL in 2005 when they wrote the GPL 14 years ago? Sun had a choice: be GPL compatible, and be able to take advantage of the huge amount of GPL code that's out there, or not be GPL compatible. Since their license came (much) later, it was up to them to either play with the community, or not. They chose not to. That's their right, but don't get uppity at people who point out that Sun's decision is a major constraint in what code can be used in OpenSolaris and where OpenSolaris code can be used.
Get real. Who cares if most consumers would never do it? Most consumers wouldn't consider anything non-MS even if they didn't have to do it! Even if Linux behaved 100% like Windows, most consumers wouldn't consider it. Defining "compete with Windows" that narrowly is completely asnine. The question here is about how easy it is to install Linux compared to Windows. For me, 5 minutes checking the HCL is preferable to 1 hour setting things up afterwards.
I've installed Windows for several people too, as well as Linux on my own machines. Windows installs always take longer, for the simple reason that you just have to do a lot of stuff to get a Windows box functional (install Winzip, Firefox, AdBlocker, etc). A Linux system not only installs slightly faster, but is ready to go once its installed. A smooth Linux install invariably takes me less time than a smooth Windows install.
Now, here's the trick: I never have rockly Linux installs. Why? I'm smart enough to take 5 min to check hardware compatibility beforehand. It's not hard to find Linux-supported hardware (indeed, around my house, all the hardware bought in the last five years has been Linux compatible), and I don't have the patience to deal with unsupported hardware.
The "install to a random system" test is a really stupid one. Actual Linux users don't own "random hardware". They own Linux-compatible hardware. It's easy to do, safer (because it tends to force you to buy name-brand stuff), and not really expensive either. I'm sure a Mac user will tell you the same thing. They don't buy hardware that doesn't say "Mac compatible" on the box!
1) $200 is pretty much standard. OS prices haven't changed substantially in a decade, and there is no way in hell they are going down. Moreover, if you look at PC prices, they are plunging. I believe the average PC is well under $1000 these days. The OS is taking up a larger and larger share of the PC budget, and that's a real issue.
2) OS X has zero driver problems because it only supports a very limited set of hardware. Linux's driver support is far more extensive than OS X's, and probably always will be. Apple is entirely uninterested in supporting random PC hardware, even after they move to x86.
3) Apple bought an incredible, functional OS from a company (NeXT), that had already done much of the work over more than a decade. NeXT, in turn, got a lot of code from universities (Carnagie-Mellon, Berkeley) that had worked on OSs from a decade before that. When Apple started on OS X in the late 1990s, they already had a complete OS. They had the kernel, the userspace tools, the GUI toolkit, a window manager, etc.
With Tiger, they were able to bring out new technologies like Quartz 2D Extreme, Searchlight, and Core*, but until Tiger, most of their work was spent updating existing technologies. Even in Tiger, the biggest pieces of the system (Darwin and Cocoa, though they didn't have those names back then), existed before Apple ever got started working on Rhapsody (what OS X was known as in its development).
So Apple did a lot less work than you claimed, and did it over a much longer period of time. Further, you completely discount the fact that Apple has had well over two decades of experience in operating systems and multimedia, as well as huge developer resources in line with what would be expected of a company that was making $1bn a year in 1983.
In contrast, a modern Linux system contains mostly new code. X11 and the GNU tools are pretty much the only pieces that even existed when NeXTStep was already a mature paltform. By the time the GNOME project was started in late 1997, Apple had already bought NeXT the year before and released the first developer version of Rhapsody! Let me put that into perspective: the OS X GUI is the result of well over two decades of UI research by a billion-dollar software company, and features a codebase that was started about 20 years ago. The Linux GUI is the result of 7 years of research and coding by an entity that had no prior experience with GUIs!
What hassle do you encounter doing day to day tasks in Linux? Since I installed Ubuntu six months ago I haven't had to do anything with it. I ran Ubuntu Update a couple of times, but that's about it. Meanwhile, my roommate whose on an XP machine had to install an ad blocker, constantly has to deal with obnoxious Windows programs (like AIM an its infernal "news I couldn't care less about" page that it pops up), and fuss with Zone Alarm all the time.
We may be saying the same thing here. Do you really find it easier to spot a fencepost error by looking at the code instead of stepping through the debugger?
Easier? No. But I sleep better at night when I analyze the algorithm to figure out what's wrong instead of using the debugger. It gives me confidence in the rest of the code. It's not just me, though. I've heard of lots of places that frown on using the debugger.
It took a long time before strong typing did more good than harm, and it's still a pain in the ass when parsing (or other situations when runtime polymophism is needed).
You're conflating strong typing with static typing. Strong typing just prevents type errors --- in the face of runtime polymorphism, it will catch type errors at runtime. Static typing prevents you from using runtime polymorphism.
Ultimately, the *hard* problems require watching what's going on at the lowest level, where nothing can hide.
In a properly high-level language, problems that require low-level access should be exceedingly rare. Basically, if you've got memory protection (ie: can't overwrite random memory with garbage), garbage collection, and some concurrency model, there should be very few problems that require getting down to the metal. In those rare occasions, it shouldn't be too difficult to do that. Again to use the analogy of optimizing compilers (especially aggressive ones like you'll find in Scheme or ML), you kind of get to know what the compiler will do. A seasoned ML programmer can tell you exactly what the memory layout of his app is as easily as a C programmer can. Things shouldn't be that much different for concurrent compilers.
how many strongly typed languages were there before people reaized you really did need void* after all?
Void* is a bad example because in C its used for two things: dynamically typed access and untyped access. You often need the former, but you almost never need the latter. In languages that have support for the former, you don't need void* at all.
The same mistake was mad ewith the design of COBOL and many other languages which tried to be closer to natural language.
I'm talking about mathematically precise specifications, not natural-language specifications. Natural languages suck for programs because they are ambiguous. There is no systematic way of expressing precisely what you want. However, with regards to concurrency, languages like C are the same way. There is no systematic way of specifying concurrency in those systems either.
A good calculus for describing concurrenct would certainly be handy for design review, but that doesn't automatically mean it would be better in a programming language.
All programming languages have semantics that can be mapped to a calculus of computation. If a language was based on a concurrent calculus, not only could the concurrency model for the application be specified during the design, but that model could be imported wholesale into the program. The more you minimize the path between specification and code, the smaller the chance for error.
Of course I picked the correct algorithm, but that's not necessarily what I typed in.
Fine, I'm not going to argue with this. In my experience, bugs are the result of my making logical errors, not handling corner cases, making fencepost errors, etc. YMMV.
This is not a problem that a different language would have fixed.
It might have, it might not have. If the API erred in marking something thread safe when it wasn't, well, a concurrent language would fix that, because there would be no need for that documentation in the first place! The concurrency of the function would be expressed in its interface, just like the type of a function is expressed in its interface. The compiler would have checked for that error before the test-cases could have even been run.
but when something goes wrong for some deeper reason you're *still* debugging through it in assembler.
You're only debugging through it in assembler because C debuggers suck. In any case, what are you arguing? That using functions from ASM code is just as easy as using functions from C code? How about using classes from C code versus using classes from Java code? Feel free to believe that, but most people would disagree. Strongly-typed programming languages aren't the panacea they were marketed as, but if they did reduce typing-related bugs. Concurrent languages won't be a panacea either, but they will reduce deadlocks and race conditions.
I can't think of a single time in history when someone has said "most people aren't good at programming, so we'll make it simple by designing an easy language!" and was right.
That's a very stupid statement. Programming is a silly undertaking to begin with. The only reason we do it is because current technology doesn't allow anything better. What you want to be doing is writing specifications, and letting the compiler sort out the rest. Human beings are good at design, computers are good at managing details. The more expressive your specification language becomes, the more work the compiler can do for you, and the less error-prone the whole process is. As you said: almost every error is the fault of the programmer. By extension, the less the programmer does, the less likely there will be errors.
In any case, this theoretical "competent programmer" is a myth. Most software in existance today blows. If programmers were really so damn competent, it wouldn't. Software wouldn't be full of races and deadlocks, software would be aggressively multithreaded. Hell, just consider the pain people went through trying to get the Mozilla codebase to play nice with BeOS's multithreading. Consider the fact that GTK+ still isn't properly thread-safe, and that Qt is in version 4 before it has reached a decent-level of thread-safety. Consider that Darwin, NetBSD, and OpenBSD still have course-grained multithreading in their kernel, while FreeBSD and Linux went through tremendous pains to fine-grain multithread their SMP. Consider the huge amount of research going in to making locking algorithms (RCU, etc) that don't kill scalability. Saying that the current state of affairs is acceptable is just plain asnine.
Hard problems are hard problems.
Hard problems are made easier to solve when you have proper tools to find the solution. Calculus problems are hard. Yet, you can solve many calculus problems knowing nothing more than algebra. However, it's difficult, tedious, and error prone. Once you have the language of calculus, a formalism that you can apply to your problem, well, then it becomes much easier.
The lambda calculus did little for formal program specification.
Most existing programming languages are reducible to the lambda calculus. As a result, the lambda calculus is immensely powerful for designing algorithms. Using the techniques of the calculus, you can design algorithms that are provably correct. On hard problems, it's the design that's the hard part. It might take weeks to design the algorithm, but the code for it might only fill a few pages of text. It's easy to use ad-hoc means to make sure your text matches the specification. It's not easy to use ad-hoc means to ensure that your specification is complete and correct.
Re:What's the compelling reason to switch?
on
Zeta Goes Gold
·
· Score: 2, Interesting
BeOS / Zeta has a certain feel which cannot be benchmarked or reviewed, it can only be experienced.
To the skeptics in the audience, there is nothing mythical about this. It's not that BeOS's feel can't be benchmarked, but rather that existing benchmarks don't test the right things. The best part of BeOS is its scheduler, which does an incredible job giving exactly the right time slices to exactly the right processes. Further, it's got a GUI API that's aggressively multithreaded, so your GUI never gets stuck waiting for backend code to finish. This "feeling" could be benchmarked, you could just measure update latencies in various windows while running a mouse macro. It's just that nobody ever bothers to test like that, they test throughput ("megabytes per second"), as if that had any real meaning on a desktop machine...
The slowest possible way to find a problem is to "reason about the code"!
It's the only Right Way (TM) to find a problems. Now, I don't recommend reasoning about the code to find typos, but then again, you shouldn't be making typos anyway.
In my experience, problems with multi-threaded code almost never come from a lack of understanding of how to write multi-threaded code.
Most people would disagree. Almost invariably, problems with multithreaded code are the fault of the programmer. Race conditions, deadlocks, etc, are all the result of the programmer not locking something he should, locking something he shouldn't, or locking things in the wrong order. You can throw scalability problems on top of there too, the programmer only locked one thing when he should have locked several. Just look through the changelogs of a highly-multithreaded system like the Linux/BSD kernels. Notice how often races and deadlocks get fixed relative to typos.
is only a good thing, but you don't need a new language for that, just appropriate attention to the debugger.
You do need a new language for that. Current languages have no formal model for concurrency, so anything the compiler offers you is an ad-hoc solution. Clever debuggers can offer hacks, but nothing complete and reliable. The only way for the compiler to understand concurrency systematically, like the programmer does, is to specify it systematically. To specify it systematically, you need a formal model of concurrency, and a language that allows you to specify concurrency in your application according to that model.
Let me use an analogy. Current languages treat concurrency the way assembler treats functions. You can do functions in assembler (even very complex ones with closures and everything), but it's all ad-hoc. The assembler doesn't really know anything about functions. It can't tell you if you put your arguments in an incorrect register or if you don't adjust the stack-pointer correctly. Now, an asm debugger can use hacks to try to divine the functions in an asm program, it can read the stack pointer and the base pointer and try to figure out what the functions are, but it'll never be as good as a C debugger that systematically understands what a function is and how it is used. Concurrent calculi do for concurrency what lambda calculus does for functions. They offers a formal way of understanding and specifying concurrency in a program.
Eh? Locks suck for debugging, nobody in their right mind likes debugging multithreaded code. If anything, this will make it easier to debug parallel code. Once you have a formal model for expressing concurrency, it makes it much easier to reason about the code and figure out where something went wrong. Further, since the compiler can understand a formal concurrency model in a way it cannot understand an ad-hoc concurrency model, the compiler can offer tools to aid in debugging concurrent applications.
Now, if you're talking about debugging things when the compiler breaks, then yes, it will make debugging harder. On the other hand, the compiler already does some pretty heroic transformations during optimization, and things seem to work pretty smoothly. Certainly, the possibility of hard-to-debug errors caused by a broken optimizer doesn't seem to have prevented people from putting -O2 in their build scripts.
The ratio doesn't matter --- the user has to make it through the text-mode part to get to the GUI part. A chain is only as strong as its weakest link...
Win95, 95 gold, 98, 98SE, 98 gold, ME, 2K, 2K ro, XP, XP Pro, 2003, and others.
What the hell are this "95 gold" releases you're blaberring about? Also, the "Pro" releases aren't new ones, they're parallel product lines, featuring the same software support. So in 10 years, Microsoft has released 7 total updates, 5 if you're a home user and aren't using workstation/server OSs like Win2k or Win2k3. At's a release roughly every 1.5 to 2.0 years. Meanwhile, most of the desktop Linux distros make releases very six months to year. Heck, even Apple makes a new release about once a year.
Try that on all of your backwards versions of the "frequent, free, releases" and tell me how many do not support it.
Why the hell would I want to install RedHat 6.0 on a brand-new machine? Try to use your head, okay? The reason having frequent releases is beneficial is that its much more likely that your new hardware will be supported out-of-box by the latest version of your OS. Nobody really cares if an older version supports their new hardware, all they care about is if the latest version supports their new hardware. If your latest version dates from 2002, well, that's a problem.
Whoever puts drivers on floppies doesn't magically include a CD just for the *nix junkies in the box.
Again, you completely miss the point. We're talking about frequent releases as an advantage. The reasoning behind that is that if your installer CD dates from 2005, its much more likely to have drivers for your circa-2005 hardware than if your installer CD dates from 2002. And burning drivers to CDs is kind of futile if its your CD driver that is the thing that's unsupported!
Sorry, but WTF? My Windows XP, which I first installed around 3 years ago, quite happily keeps itself up-to-date with nothing more than an occasional click to approve downloading and installing a security patch.
We're talking about installer here, not the OS once it is installed. This whole thread has been about the installer, not the OS. Please keep up, m-kay?
Since my system doesn't even have a floppy drive, and as noted above it's been running XP happily for years
Did you have SATA hardware when you installed that system years ago? I didn't think so.
Then again, if you don't have hardware that's capable of booting from anything other than a floppy drive when everyone else has been doing it for years, whose fault is that?
I don't think you understand the situation here. SATA hardware requires different drivers than IDE hardware, drivers that didn't exist in 2002 when the WinXP was released. The BIOS will happily boot the Windows installer, but the installer doesn't use the BIOS to do the install --- it uses its own drivers. So if the installer can't read from the SATA CD-drive, then I've got a problem.
Multithreading is dominant because it's the only way to wring parallelism out of legacy languages like C. And nobody claims multithreading is easy, natural, or anything but error-prone. The future is really in languages that have formal abstractions for concurrency, so programmers can specify at a high level what tasks can be concurrent and let the compiler do the low-level locking. Basically, you want languages based on a concurrent calculus of computation (eg: Pi-calculus), instead of languages based on lambda calculus, which lacks an formal notion of concurrency.
Sure it's fair. If Microsoft can't keep Windows up-to-date between major releases, whose fault is that? Frequent, free, releases is one of the advantages Linux has versus Windows. There is no point in arbitrarily trying to make that advantage inapplicable, since any given user installing both OSs will experience that advantage.
I'm already not looking forward to install WinXP on my new all-SATA all-PCI-E computer. I really hope no driver diskettes are involved, namely because I couldn't bear to put a floppy drive in the thing.
Because Fedora is a GNOME distribution, with a default application set that depends on the GNOME infrastructure. XFCE is no longer so light if you have to bring in all the GNOME libraries anyway...
While I can understand your preference with regards to fluidity, its hardly "objective" (to be pedantic about the definition of "objective") as you say. There is nothing in the definition of animation that suggests fluid animation is better than stacatto animiation. It's like saying the cinematography in "Crouching Tiger" is better than the cinematography in "Snatch" because the former is more fluid. The former is supposed to be fluid, while the latter is supposed to be stacatto. While you may prefer one style vs the other, you can't objectively say one is better than the other, because your critereon of comparison is invalid.
Not really. Word is infuriatingly slow working on large documents. I'm one of those people who instinctively hits CTRL-S several times a minute. Word absolutely chokes when its saving a file of 15MB or so, as it doesn't appear to do any sort of incremental save optimization.
The 2006 Apple machines will likely use an Intel chipset and a regular BIOS. Reports indicate part of the reason Apple went with Intel in the first place is because Intel has an entire platform to sell Apple, unlike AMD. In any case, Apple didn't develop their own chipsets (by themselves anyway) on the PPC platform (they used an AIM-developed chipset), and they'd be stupid not to use Intel's chipsets on the x86 platform. As for the firmware, while EFI is still possible, its unlikely. Apple's current developer documentation all refers to a regular BIOS. If Apple changes things again before the platform is even rolled out, third-party manufacturers are going to be pissed.
Um, moving batches to and from RAM is the definition of "explicit DMA operation". This is in contrast to implicit operation, in which batches are automatically moved from RAM to cache (what most CPUs do today).
Anyway, you're right about the different programming approach. Which is exactly my point: these processors don't behave the way programmers expect general purpose processors today to behave. The vast majority of programs aren't written to do explicit DMA operations, thus the Cell needs specialized code to be written for it.
Slashdot Mirror
We're talking about desktop systems. That means if you choose "Medium Security" or above in your Linux installer, things should pretty much be set up correctly already. Also, in addition to all the things you listed for Windows, you have to add programs like OpenOffice, Aol Instant Messenger, DivX codec, and all the other assorted programs commonly used on Windows desktops. All those come pre-installed in a Linux setup.
It has nothing to do with the "approval" of the FSF. The GPL defines certain terms, the CDDL defines certain terms, and the two just aren't compatible. The FSF can't "change" its "attitude" about the CDDL any more than it can retroactively change the licensing of the enormous amount of code that has been put under the GPL over the last decade.
I love how twits like you spin this as a fault of the FSF. What were they supposed to do? Prognosticate the terms of the CDDL in 2005 when they wrote the GPL 14 years ago? Sun had a choice: be GPL compatible, and be able to take advantage of the huge amount of GPL code that's out there, or not be GPL compatible. Since their license came (much) later, it was up to them to either play with the community, or not. They chose not to. That's their right, but don't get uppity at people who point out that Sun's decision is a major constraint in what code can be used in OpenSolaris and where OpenSolaris code can be used.
Get real. Who cares if most consumers would never do it? Most consumers wouldn't consider anything non-MS even if they didn't have to do it! Even if Linux behaved 100% like Windows, most consumers wouldn't consider it. Defining "compete with Windows" that narrowly is completely asnine. The question here is about how easy it is to install Linux compared to Windows. For me, 5 minutes checking the HCL is preferable to 1 hour setting things up afterwards.
Um, Apple's license to you allows you to do whatever you want to OpenDarwin. DMCA can't do anything about it.
Apple doesn't use any higher-quality parts in its stuff than even cheap manufacturers like Dell use in theirs.
I've installed Windows for several people too, as well as Linux on my own machines. Windows installs always take longer, for the simple reason that you just have to do a lot of stuff to get a Windows box functional (install Winzip, Firefox, AdBlocker, etc). A Linux system not only installs slightly faster, but is ready to go once its installed. A smooth Linux install invariably takes me less time than a smooth Windows install.
Now, here's the trick: I never have rockly Linux installs. Why? I'm smart enough to take 5 min to check hardware compatibility beforehand. It's not hard to find Linux-supported hardware (indeed, around my house, all the hardware bought in the last five years has been Linux compatible), and I don't have the patience to deal with unsupported hardware.
The "install to a random system" test is a really stupid one. Actual Linux users don't own "random hardware". They own Linux-compatible hardware. It's easy to do, safer (because it tends to force you to buy name-brand stuff), and not really expensive either. I'm sure a Mac user will tell you the same thing. They don't buy hardware that doesn't say "Mac compatible" on the box!
Wow, where to start.
1) $200 is pretty much standard. OS prices haven't changed substantially in a decade, and there is no way in hell they are going down. Moreover, if you look at PC prices, they are plunging. I believe the average PC is well under $1000 these days. The OS is taking up a larger and larger share of the PC budget, and that's a real issue.
2) OS X has zero driver problems because it only supports a very limited set of hardware. Linux's driver support is far more extensive than OS X's, and probably always will be. Apple is entirely uninterested in supporting random PC hardware, even after they move to x86.
3) Apple bought an incredible, functional OS from a company (NeXT), that had already done much of the work over more than a decade. NeXT, in turn, got a lot of code from universities (Carnagie-Mellon, Berkeley) that had worked on OSs from a decade before that. When Apple started on OS X in the late 1990s, they already had a complete OS. They had the kernel, the userspace tools, the GUI toolkit, a window manager, etc.
With Tiger, they were able to bring out new technologies like Quartz 2D Extreme, Searchlight, and Core*, but until Tiger, most of their work was spent updating existing technologies. Even in Tiger, the biggest pieces of the system (Darwin and Cocoa, though they didn't have those names back then), existed before Apple ever got started working on Rhapsody (what OS X was known as in its development).
So Apple did a lot less work than you claimed, and did it over a much longer period of time. Further, you completely discount the fact that Apple has had well over two decades of experience in operating systems and multimedia, as well as huge developer resources in line with what would be expected of a company that was making $1bn a year in 1983.
In contrast, a modern Linux system contains mostly new code. X11 and the GNU tools are pretty much the only pieces that even existed when NeXTStep was already a mature paltform. By the time the GNOME project was started in late 1997, Apple had already bought NeXT the year before and released the first developer version of Rhapsody! Let me put that into perspective: the OS X GUI is the result of well over two decades of UI research by a billion-dollar software company, and features a codebase that was started about 20 years ago. The Linux GUI is the result of 7 years of research and coding by an entity that had no prior experience with GUIs!
What hassle do you encounter doing day to day tasks in Linux? Since I installed Ubuntu six months ago I haven't had to do anything with it. I ran Ubuntu Update a couple of times, but that's about it. Meanwhile, my roommate whose on an XP machine had to install an ad blocker, constantly has to deal with obnoxious Windows programs (like AIM an its infernal "news I couldn't care less about" page that it pops up), and fuss with Zone Alarm all the time.
We may be saying the same thing here. Do you really find it easier to spot a fencepost error by looking at the code instead of stepping through the debugger?
Easier? No. But I sleep better at night when I analyze the algorithm to figure out what's wrong instead of using the debugger. It gives me confidence in the rest of the code. It's not just me, though. I've heard of lots of places that frown on using the debugger.
It took a long time before strong typing did more good than harm, and it's still a pain in the ass when parsing (or other situations when runtime polymophism is needed).
You're conflating strong typing with static typing. Strong typing just prevents type errors --- in the face of runtime polymorphism, it will catch type errors at runtime. Static typing prevents you from using runtime polymorphism.
Ultimately, the *hard* problems require watching what's going on at the lowest level, where nothing can hide.
In a properly high-level language, problems that require low-level access should be exceedingly rare. Basically, if you've got memory protection (ie: can't overwrite random memory with garbage), garbage collection, and some concurrency model, there should be very few problems that require getting down to the metal. In those rare occasions, it shouldn't be too difficult to do that. Again to use the analogy of optimizing compilers (especially aggressive ones like you'll find in Scheme or ML), you kind of get to know what the compiler will do. A seasoned ML programmer can tell you exactly what the memory layout of his app is as easily as a C programmer can. Things shouldn't be that much different for concurrent compilers.
how many strongly typed languages were there before people reaized you really did need void* after all?
Void* is a bad example because in C its used for two things: dynamically typed access and untyped access. You often need the former, but you almost never need the latter. In languages that have support for the former, you don't need void* at all.
The same mistake was mad ewith the design of COBOL and many other languages which tried to be closer to natural language.
I'm talking about mathematically precise specifications, not natural-language specifications. Natural languages suck for programs because they are ambiguous. There is no systematic way of expressing precisely what you want. However, with regards to concurrency, languages like C are the same way. There is no systematic way of specifying concurrency in those systems either.
A good calculus for describing concurrenct would certainly be handy for design review, but that doesn't automatically mean it would be better in a programming language.
All programming languages have semantics that can be mapped to a calculus of computation. If a language was based on a concurrent calculus, not only could the concurrency model for the application be specified during the design, but that model could be imported wholesale into the program. The more you minimize the path between specification and code, the smaller the chance for error.
Of course I picked the correct algorithm, but that's not necessarily what I typed in.
Fine, I'm not going to argue with this. In my experience, bugs are the result of my making logical errors, not handling corner cases, making fencepost errors, etc. YMMV.
This is not a problem that a different language would have fixed.
It might have, it might not have. If the API erred in marking something thread safe when it wasn't, well, a concurrent language would fix that, because there would be no need for that documentation in the first place! The concurrency of the function would be expressed in its interface, just like the type of a function is expressed in its interface. The compiler would have checked for that error before the test-cases could have even been run.
but when something goes wrong for some deeper reason you're *still* debugging through it in assembler.
You're only debugging through it in assembler because C debuggers suck. In any case, what are you arguing? That using functions from ASM code is just as easy as using functions from C code? How about using classes from C code versus using classes from Java code? Feel free to believe that, but most people would disagree. Strongly-typed programming languages aren't the panacea they were marketed as, but if they did reduce typing-related bugs. Concurrent languages won't be a panacea either, but they will reduce deadlocks and race conditions.
I can't think of a single time in history when someone has said "most people aren't good at programming, so we'll make it simple by designing an easy language!" and was right.
That's a very stupid statement. Programming is a silly undertaking to begin with. The only reason we do it is because current technology doesn't allow anything better. What you want to be doing is writing specifications, and letting the compiler sort out the rest. Human beings are good at design, computers are good at managing details. The more expressive your specification language becomes, the more work the compiler can do for you, and the less error-prone the whole process is. As you said: almost every error is the fault of the programmer. By extension, the less the programmer does, the less likely there will be errors.
In any case, this theoretical "competent programmer" is a myth. Most software in existance today blows. If programmers were really so damn competent, it wouldn't. Software wouldn't be full of races and deadlocks, software would be aggressively multithreaded. Hell, just consider the pain people went through trying to get the Mozilla codebase to play nice with BeOS's multithreading. Consider the fact that GTK+ still isn't properly thread-safe, and that Qt is in version 4 before it has reached a decent-level of thread-safety. Consider that Darwin, NetBSD, and OpenBSD still have course-grained multithreading in their kernel, while FreeBSD and Linux went through tremendous pains to fine-grain multithread their SMP. Consider the huge amount of research going in to making locking algorithms (RCU, etc) that don't kill scalability. Saying that the current state of affairs is acceptable is just plain asnine.
Hard problems are hard problems.
Hard problems are made easier to solve when you have proper tools to find the solution. Calculus problems are hard. Yet, you can solve many calculus problems knowing nothing more than algebra. However, it's difficult, tedious, and error prone. Once you have the language of calculus, a formalism that you can apply to your problem, well, then it becomes much easier.
The lambda calculus did little for formal program specification.
Most existing programming languages are reducible to the lambda calculus. As a result, the lambda calculus is immensely powerful for designing algorithms. Using the techniques of the calculus, you can design algorithms that are provably correct. On hard problems, it's the design that's the hard part. It might take weeks to design the algorithm, but the code for it might only fill a few pages of text. It's easy to use ad-hoc means to make sure your text matches the specification. It's not easy to use ad-hoc means to ensure that your specification is complete and correct.
BeOS / Zeta has a certain feel which cannot be benchmarked or reviewed, it can only be experienced.
To the skeptics in the audience, there is nothing mythical about this. It's not that BeOS's feel can't be benchmarked, but rather that existing benchmarks don't test the right things. The best part of BeOS is its scheduler, which does an incredible job giving exactly the right time slices to exactly the right processes. Further, it's got a GUI API that's aggressively multithreaded, so your GUI never gets stuck waiting for backend code to finish. This "feeling" could be benchmarked, you could just measure update latencies in various windows while running a mouse macro. It's just that nobody ever bothers to test like that, they test throughput ("megabytes per second"), as if that had any real meaning on a desktop machine...
s/republican/conservative/g
The slowest possible way to find a problem is to "reason about the code"!
It's the only Right Way (TM) to find a problems. Now, I don't recommend reasoning about the code to find typos, but then again, you shouldn't be making typos anyway.
In my experience, problems with multi-threaded code almost never come from a lack of understanding of how to write multi-threaded code.
Most people would disagree. Almost invariably, problems with multithreaded code are the fault of the programmer. Race conditions, deadlocks, etc, are all the result of the programmer not locking something he should, locking something he shouldn't, or locking things in the wrong order. You can throw scalability problems on top of there too, the programmer only locked one thing when he should have locked several. Just look through the changelogs of a highly-multithreaded system like the Linux/BSD kernels. Notice how often races and deadlocks get fixed relative to typos.
is only a good thing, but you don't need a new language for that, just appropriate attention to the debugger.
You do need a new language for that. Current languages have no formal model for concurrency, so anything the compiler offers you is an ad-hoc solution. Clever debuggers can offer hacks, but nothing complete and reliable. The only way for the compiler to understand concurrency systematically, like the programmer does, is to specify it systematically. To specify it systematically, you need a formal model of concurrency, and a language that allows you to specify concurrency in your application according to that model.
Let me use an analogy. Current languages treat concurrency the way assembler treats functions. You can do functions in assembler (even very complex ones with closures and everything), but it's all ad-hoc. The assembler doesn't really know anything about functions. It can't tell you if you put your arguments in an incorrect register or if you don't adjust the stack-pointer correctly. Now, an asm debugger can use hacks to try to divine the functions in an asm program, it can read the stack pointer and the base pointer and try to figure out what the functions are, but it'll never be as good as a C debugger that systematically understands what a function is and how it is used. Concurrent calculi do for concurrency what lambda calculus does for functions. They offers a formal way of understanding and specifying concurrency in a program.
Eh? Locks suck for debugging, nobody in their right mind likes debugging multithreaded code. If anything, this will make it easier to debug parallel code. Once you have a formal model for expressing concurrency, it makes it much easier to reason about the code and figure out where something went wrong. Further, since the compiler can understand a formal concurrency model in a way it cannot understand an ad-hoc concurrency model, the compiler can offer tools to aid in debugging concurrent applications.
Now, if you're talking about debugging things when the compiler breaks, then yes, it will make debugging harder. On the other hand, the compiler already does some pretty heroic transformations during optimization, and things seem to work pretty smoothly. Certainly, the possibility of hard-to-debug errors caused by a broken optimizer doesn't seem to have prevented people from putting -O2 in their build scripts.
The ratio doesn't matter --- the user has to make it through the text-mode part to get to the GUI part. A chain is only as strong as its weakest link...
Win95, 95 gold, 98, 98SE, 98 gold, ME, 2K, 2K ro, XP, XP Pro, 2003, and others.
What the hell are this "95 gold" releases you're blaberring about? Also, the "Pro" releases aren't new ones, they're parallel product lines, featuring the same software support. So in 10 years, Microsoft has released 7 total updates, 5 if you're a home user and aren't using workstation/server OSs like Win2k or Win2k3. At's a release roughly every 1.5 to 2.0 years. Meanwhile, most of the desktop Linux distros make releases very six months to year. Heck, even Apple makes a new release about once a year.
Try that on all of your backwards versions of the "frequent, free, releases" and tell me how many do not support it.
Why the hell would I want to install RedHat 6.0 on a brand-new machine? Try to use your head, okay? The reason having frequent releases is beneficial is that its much more likely that your new hardware will be supported out-of-box by the latest version of your OS. Nobody really cares if an older version supports their new hardware, all they care about is if the latest version supports their new hardware. If your latest version dates from 2002, well, that's a problem.
Whoever puts drivers on floppies doesn't magically include a CD just for the *nix junkies in the box.
Again, you completely miss the point. We're talking about frequent releases as an advantage. The reasoning behind that is that if your installer CD dates from 2005, its much more likely to have drivers for your circa-2005 hardware than if your installer CD dates from 2002. And burning drivers to CDs is kind of futile if its your CD driver that is the thing that's unsupported!
Sorry, but WTF? My Windows XP, which I first installed around 3 years ago, quite happily keeps itself up-to-date with nothing more than an occasional click to approve downloading and installing a security patch.
We're talking about installer here, not the OS once it is installed. This whole thread has been about the installer, not the OS. Please keep up, m-kay?
Since my system doesn't even have a floppy drive, and as noted above it's been running XP happily for years
Did you have SATA hardware when you installed that system years ago? I didn't think so.
Then again, if you don't have hardware that's capable of booting from anything other than a floppy drive when everyone else has been doing it for years, whose fault is that?
I don't think you understand the situation here. SATA hardware requires different drivers than IDE hardware, drivers that didn't exist in 2002 when the WinXP was released. The BIOS will happily boot the Windows installer, but the installer doesn't use the BIOS to do the install --- it uses its own drivers. So if the installer can't read from the SATA CD-drive, then I've got a problem.
Multithreading is dominant because it's the only way to wring parallelism out of legacy languages like C. And nobody claims multithreading is easy, natural, or anything but error-prone. The future is really in languages that have formal abstractions for concurrency, so programmers can specify at a high level what tasks can be concurrent and let the compiler do the low-level locking. Basically, you want languages based on a concurrent calculus of computation (eg: Pi-calculus), instead of languages based on lambda calculus, which lacks an formal notion of concurrency.
Sure it's fair. If Microsoft can't keep Windows up-to-date between major releases, whose fault is that? Frequent, free, releases is one of the advantages Linux has versus Windows. There is no point in arbitrarily trying to make that advantage inapplicable, since any given user installing both OSs will experience that advantage.
I'm already not looking forward to install WinXP on my new all-SATA all-PCI-E computer. I really hope no driver diskettes are involved, namely because I couldn't bear to put a floppy drive in the thing.
LOL. It's 2005. Wake me up when Windows isn't the only major OS to still do half its install in text mode...
Because Fedora is a GNOME distribution, with a default application set that depends on the GNOME infrastructure. XFCE is no longer so light if you have to bring in all the GNOME libraries anyway...
While I can understand your preference with regards to fluidity, its hardly "objective" (to be pedantic about the definition of "objective") as you say. There is nothing in the definition of animation that suggests fluid animation is better than stacatto animiation. It's like saying the cinematography in "Crouching Tiger" is better than the cinematography in "Snatch" because the former is more fluid. The former is supposed to be fluid, while the latter is supposed to be stacatto. While you may prefer one style vs the other, you can't objectively say one is better than the other, because your critereon of comparison is invalid.
Not really. Word is infuriatingly slow working on large documents. I'm one of those people who instinctively hits CTRL-S several times a minute. Word absolutely chokes when its saving a file of 15MB or so, as it doesn't appear to do any sort of incremental save optimization.
The 2006 Apple machines will likely use an Intel chipset and a regular BIOS. Reports indicate part of the reason Apple went with Intel in the first place is because Intel has an entire platform to sell Apple, unlike AMD. In any case, Apple didn't develop their own chipsets (by themselves anyway) on the PPC platform (they used an AIM-developed chipset), and they'd be stupid not to use Intel's chipsets on the x86 platform. As for the firmware, while EFI is still possible, its unlikely. Apple's current developer documentation all refers to a regular BIOS. If Apple changes things again before the platform is even rolled out, third-party manufacturers are going to be pissed.
Um, moving batches to and from RAM is the definition of "explicit DMA operation". This is in contrast to implicit operation, in which batches are automatically moved from RAM to cache (what most CPUs do today).
Anyway, you're right about the different programming approach. Which is exactly my point: these processors don't behave the way programmers expect general purpose processors today to behave. The vast majority of programs aren't written to do explicit DMA operations, thus the Cell needs specialized code to be written for it.