>> If the problem decomposes down most neatly into one, three or 6789 threads, then design and write the implementation that way.
Agreed. But the problem is that most programs are inherently serial in nature. Intel and others are targeting multi-core everywhere, not just the highly parallel scientific community, but the average desktop as well.
These Intel tools are trying to solve the problem by letting you write an apparently single-threaded application, that the compiler turns into something multi-threaded under the covers. There's no harm in not exploiting the extra parallelism available, but you're missing out on some potential performance if you don't.
The other approach is to make programmers think about the parallelism. In my experience, most programmers just aren't good at this. Some argue that we need better primitives than just semaphores, queues, etc., but I think it's human nature to think serially and that "thinking parallel" all the time just isn't going to happen.
Personally, I don't think this will be an issue at all for several more years, because systems are typically running an SMP-aware OS and are running lots of processes/threads at a time anyway (just ps -ef or look at the Windows Task Manager and look how much is there!) Users are also becoming more sophisticated and multitasking at the user level, e.g. web browsing, listening to music, whatever else all at the same time. Parallelism at the top should be exploited first and more fine-grained parallelism can be dealt with later, IMO.
First, performance should never be a reason not to try something new. Most people are very bad at predicting the performance of something that doesn't exist yet.
As I see it, the problem stems from the sheer amount of data that people are dealing with these days. A typical system now has hundreds, if not thousands, of folders/directories.
Plus the sorting criteria -- determining how to use folders and what to put in them -- is not consistent. As on UNIX, where some packages put everything into one directory and others split things up into/etc,/usr/bin, and so on. Often, the directory name doesn't completely describe what the purpose of the grouping is in the most intuitive manner.
Innovation is not fixing what is broken; it's making things better.
I counted 26 open windows on my desktop (win2k) at the office today. Browser, email, xterms, editors, IMs, pdfs, and other proprietary doc formats. I need all of these to do my job effectively.
I figure it takes at least 15 minutes to stop all my apps, shutdown, reboot, and restart them all again. And you can't put a value on the loss of concentration.
There are times when a reboot is necessary (granted, updating graphics drivers is probably one of them!) but most of the time reboots are disruptive and unnecessary when you're multitasking.
1. My time is better spent doing things other than compiling basic system utilities.
Gentoo does not force users to sit in front of their computers during upgrades, or force you into single-tasking mode. Plus you don't have to upgrade anything until you want to.
2. My optimized Gentoo system does not run faster enough to make up for the time lost building it from source.
It seems most people, myself included, seem to love Gentoo more for the package management than raw CPU speed. I've never been obsessed with speed enough to measure it, so I couldn't say if it's faster or not.
3. Turns out there was nothing to learn from installing Gentoo from stage 1...
So you learned that there was nothing to learn. That's deep:)
But I agree with you. As I see it, Gentoo forces newbies to confront all the dirty details of the shell, the compiler, etc. from the get-go, which is a Good Thing, because you're probably going to need them eventually anyway.
The #1 thing I've learned from using Gentoo is how to use the lynx web browser to browse the forums when X is b0rked.
8. Tag your bug fixes, code enhancements with a comment followed by a dash, date, and your initials. This is essential for large projects or for anything you will be working on for more than 6 months.
Just use a decent source control system to track all of this. I've worked on projects where the source was cluttered with this kind of information, and it was incredibly distracting. Yes, it is a must have, but no, I don't need to see it all the time.
Arch and Monotone have progressed a lot since the decision to use BK. That might have been a good decision to avoid them back then. That doesn't mean they shouldn't be considered at all today.
I really don't see why a brand new tool had to be written for this purpose. I bet any of the OSS tools' development teams would be eager to jump in and work on any of Linus' gripes. I wonder how much time the kernel guys will spend working on git when they could be working on new kernel features/fixing bugs. Starting *completely* over is rarely the right decision in the long run.
My hope is that git serves useful in the short run to keep the kernel from completely stalling, but that a switch to something more standard happens within the next 6-12 months.
Don't most people discover new web sites either through search engines or hyperlinks from other sites, in which case it really doesn't matter what the URL is anyway?
I couldn't tell you the URLs of most of the web sites I visit; I just bookmark them once I discover them. And by organizing and renaming bookmark entries, I can then call the site whatever I want.
No the OS doesn't age in that way, but consumer hardware isn't built to last forever, and you should expect something mechanical to fail eventually. I doubt grandma takes the cover off every 6 months and pulls out a can of compressed air...
And although the OS functionality doesn't decrease over time, people's expectations of what their system should do has gotten way more sophisticated. Most people (i.e. not./ers) don't have multiple boxes for various tasks and will continue to push the limits to do new kinds of tasks, e.g. multimedia.
The fact is that America is a divided country with respect to certain issues and non-configurable devices like this have the potential to piss off half the population.
Suppose there's a nice, "clean" movie except for one scene that shows two men kissing... now some would be horrified by that, and some wouldn't question it... now how is this thing gonna handle that without offending somebody? (I can hear it now, "this thing doesn't work! Did you see THAT?")
Another example... some so-called "bad words" are heard so often, some parents don't even try to shield their kids from them, while others risk life and limb to make sure that they are never heard. Who decides what's OK and what's not?
The danger is that of a single manufacturer of this kind of equipment controlling the market and ultimately making that decision for everyone (sound familiar?) But I believe this type of product will become more prevalent and there will be options. Then parents will have the choice of which device, or none at all, filters the way they want.
Sounds like an open source version of such a device would make everyone happy.
I'm not totally against the idea of such devices myself, but as they stand today, they give you as a parent very little control as to what is considered acceptable or not acceptable.
You do have the right to choose what is OK for your children to see/hear. But every parent's view of what is "right" is different. When we leave it up to the manufacturers of such equipment to make that call, we've given up our parental authority entirely.
Now if the device is configurable, allowing you to choose different types of material to filter (like most of the decent web filters these days), then it's more tolerable. Manufacturers need to clearly define how these devices work, and parents have to evaluate them carefully before trusting them.
C code does become unmanageable(pun intented) as the project size increases. You need all of encapsulation and inheritance to avoid nightmares of one huge gorilla staring at you!
Which reminds me of another big difference between Windows and UNIX: the monolithic application vs. a set of smaller utilities. When you view a project as one large piece of code, it will become unmanageable very quickly, regardless of the source language.
Encapsulation and inberitance are good things, when used properly. Even though C isn't a true OO language, you can still design your program using OO concepts and code it in C. A little thinking before you start typing goes a long way.
Except, of course, that Company AB is in competition with Company C, which makes a real 150GB drive which costs less to produce than company AB's "150GB" drive because it's not really a 200GB drive with modified firmware.
I don't follow the logic here. Just because Company C's 150GB drive is "really" 150GB, that doesn't make it cheaper to produce. I don't know for sure, but I'm willing to bet that production costs have virtually nothing to do with capacity. Except maybe at the high end, where the technology isn't as proven and the processes aren't as refined.
In college I had to write a program in MIPS assembler to parse and evaluate a numeric expression. Both input/output in Roman numerals:)
IMHO, assembly language should be required but it does not make a good first-year CS course. The entry level classes already do a good job of weeding out many students, and I don't think difficulties with assembly should be the basis for that.
I've always taken a more practical view towards CompSci and felt that students should be taught more things that will actually help them get a job and do that job well. Fundamentals like data structures and tight logic are what's really important (whether C, assembler, whatever language). Today, there are very few places that need assembly language programmers.
That said, I think a new asm book is overdue. I read Peter Norton's book on x86 assembly language back in high school and it certainly did help me understand what was really going on inside the silicon.
Both Linux and Windows crash. In fact, I'd say Linux has probably crashed more for me because I try more bleeding edge software on it. But in my experience, when Windows crashes, it never fully recovers. Filesystem corruption, halfassed registry state, and no clue what to do about it. IMO Linux tolerates them much better.
And Windows isn't so bad once you install the patch known as Cygwin.
Slashdot Mirror
>> If the problem decomposes down most neatly into one, three or 6789 threads, then design and write the implementation that way.
Agreed. But the problem is that most programs are inherently serial in nature. Intel and others are targeting multi-core everywhere, not just the highly parallel scientific community, but the average desktop as well.
These Intel tools are trying to solve the problem by letting you write an apparently single-threaded application, that the compiler turns into something multi-threaded under the covers. There's no harm in not exploiting the extra parallelism available, but you're missing out on some potential performance if you don't.
The other approach is to make programmers think about the parallelism. In my experience, most programmers just aren't good at this. Some argue that we need better primitives than just semaphores, queues, etc., but I think it's human nature to think serially and that "thinking parallel" all the time just isn't going to happen.
Personally, I don't think this will be an issue at all for several more years, because systems are typically running an SMP-aware OS and are running lots of processes/threads at a time anyway (just ps -ef or look at the Windows Task Manager and look how much is there!) Users are also becoming more sophisticated and multitasking at the user level, e.g. web browsing, listening to music, whatever else all at the same time. Parallelism at the top should be exploited first and more fine-grained parallelism can be dealt with later, IMO.
First, performance should never be a reason not to try something new. Most people are very bad at predicting the performance of something that doesn't exist yet.
As I see it, the problem stems from the sheer amount of data that people are dealing with these days. A typical system now has hundreds, if not thousands, of folders/directories.
Plus the sorting criteria -- determining how to use folders and what to put in them -- is not consistent. As on UNIX, where some packages put everything into one directory and others split things up into /etc, /usr/bin, and so on. Often, the directory name doesn't completely describe what the purpose of the grouping is in the most intuitive manner.
Innovation is not fixing what is broken; it's making things better.
I counted 26 open windows on my desktop (win2k) at the office today. Browser, email, xterms, editors, IMs, pdfs, and other proprietary doc formats. I need all of these to do my job effectively.
I figure it takes at least 15 minutes to stop all my apps, shutdown, reboot, and restart them all again. And you can't put a value on the loss of concentration.
There are times when a reboot is necessary (granted, updating graphics drivers is probably one of them!) but most of the time reboots are disruptive and unnecessary when you're multitasking.
So you learned that there was nothing to learn. That's deep :)
But I agree with you. As I see it, Gentoo forces newbies to confront all the dirty details of the shell, the compiler, etc. from the get-go, which is a Good Thing, because you're probably going to need them eventually anyway.
The #1 thing I've learned from using Gentoo is how to use the lynx web browser to browse the forums when X is b0rked.
Arch and Monotone have progressed a lot since the decision to use BK. That might have been a good decision to avoid them back then. That doesn't mean they shouldn't be considered at all today.
I really don't see why a brand new tool had to be written for this purpose. I bet any of the OSS tools' development teams would be eager to jump in and work on any of Linus' gripes. I wonder how much time the kernel guys will spend working on git when they could be working on new kernel features/fixing bugs. Starting *completely* over is rarely the right decision in the long run.
My hope is that git serves useful in the short run to keep the kernel from completely stalling, but that a switch to something more standard happens within the next 6-12 months.
Don't most people discover new web sites either through search engines or hyperlinks from other sites, in which case it really doesn't matter what the URL is anyway?
I couldn't tell you the URLs of most of the web sites I visit; I just bookmark them once I discover them. And by organizing and renaming bookmark entries, I can then call the site whatever I want.
No the OS doesn't age in that way, but consumer hardware isn't built to last forever, and you should expect something mechanical to fail eventually. I doubt grandma takes the cover off every 6 months and pulls out a can of compressed air...
./ers) don't have multiple boxes for various tasks and will continue to push the limits to do new kinds of tasks, e.g. multimedia.
And although the OS functionality doesn't decrease over time, people's expectations of what their system should do has gotten way more sophisticated. Most people (i.e. not
The fact is that America is a divided country with respect to certain issues and non-configurable devices like this have the potential to piss off half the population.
... some so-called "bad words" are heard so often, some parents don't even try to shield their kids from them, while others risk life and limb to make sure that they are never heard. Who decides what's OK and what's not?
Suppose there's a nice, "clean" movie except for one scene that shows two men kissing... now some would be horrified by that, and some wouldn't question it... now how is this thing gonna handle that without offending somebody? (I can hear it now, "this thing doesn't work! Did you see THAT?")
Another example
The danger is that of a single manufacturer of this kind of equipment controlling the market and ultimately making that decision for everyone (sound familiar?) But I believe this type of product will become more prevalent and there will be options. Then parents will have the choice of which device, or none at all, filters the way they want.
Sounds like an open source version of such a device would make everyone happy.
I'm not totally against the idea of such devices myself, but as they stand today, they give you as a parent very little control as to what is considered acceptable or not acceptable.
You do have the right to choose what is OK for your children to see/hear. But every parent's view of what is "right" is different. When we leave it up to the manufacturers of such equipment to make that call, we've given up our parental authority entirely.
Now if the device is configurable, allowing you to choose different types of material to filter (like most of the decent web filters these days), then it's more tolerable. Manufacturers need to clearly define how these devices work, and parents have to evaluate them carefully before trusting them.
C code does become unmanageable(pun intented) as the project size increases. You need all of encapsulation and inheritance to avoid nightmares of one huge gorilla staring at you!
Which reminds me of another big difference between Windows and UNIX: the monolithic application vs. a set of smaller utilities. When you view a project as one large piece of code, it will become unmanageable very quickly, regardless of the source language.
Encapsulation and inberitance are good things, when used properly. Even though C isn't a true OO language, you can still design your program using OO concepts and code it in C. A little thinking before you start typing goes a long way.
Except, of course, that Company AB is in competition with Company C, which makes a real 150GB drive which costs less to produce than company AB's "150GB" drive because it's not really a 200GB drive with modified firmware.
I don't follow the logic here. Just because Company C's 150GB drive is "really" 150GB, that doesn't make it cheaper to produce. I don't know for sure, but I'm willing to bet that production costs have virtually nothing to do with capacity. Except maybe at the high end, where the technology isn't as proven and the processes aren't as refined.
I think Motorola 680x is one of the most elegant assembly languages ever. Does the word "orthogonality" mean *anything* anymore?
"We don't need no stinkin' mmx"
In college I had to write a program in MIPS assembler to parse and evaluate a numeric expression. Both input/output in Roman numerals :)
IMHO, assembly language should be required but it does not make a good first-year CS course. The entry level classes already do a good job of weeding out many students, and I don't think difficulties with assembly should be the basis for that.
I've always taken a more practical view towards CompSci and felt that students should be taught more things that will actually help them get a job and do that job well. Fundamentals like data structures and tight logic are what's really important (whether C, assembler, whatever language). Today, there are very few places that need assembly language programmers.
That said, I think a new asm book is overdue. I read Peter Norton's book on x86 assembly language back in high school and it certainly did help me understand what was really going on inside the silicon.
Both Linux and Windows crash. In fact, I'd say Linux has probably crashed more for me because I try more bleeding edge software on it. But in my experience, when Windows crashes, it never fully recovers. Filesystem corruption, halfassed registry state, and no clue what to do about it. IMO Linux tolerates them much better.
And Windows isn't so bad once you install the patch known as Cygwin.