While getting my B.S. in Electrical Engineering at a Big-10 university, I never had to write anything longer than a couple pages (besides a technical lab report).
On the other hand, the asker of the question is a snob and obviously hasn't dealt with a typical community where a large percentage of people do not have a college education. Heck, go to Milwaukee and you will learn that the high school drop-out rate is beyond 50%.
ECS are great boards if you can deal with kinks. For example, I had random freezes after I upgraded from an Athlon 900MHz to a Athlon XP 1800. I found a site that outlined how to solve the problem by soldering on an additional resistor to adjust the voltage of one of the supply lines to the CPU. Scary procedure, but it worked like a charm!
Theo de Raadt: I don't know. I have never run Linux.
Torvalds says the same thing about Windows. I suggest that creators and active developers of open-source operating systems should start using rival systems to learn and carry over the best practices. This is quite common in industry and the attitude displayed in these quotes show arrogance and ignorance.
1./usr/local. Everything that you add afterwards goes in there. It's just extra to type. And is apache config in/usr/local/apache/conf or/usr/local/etc/apache/conf ?
Maybe a more experience sys admin can chime in here, but/usr/local is exactly where additional software, not included in the base OS, should be installed. More typing?? For what?/usr/local should be in your path and manually going to this directory should be rare.
There are many reasons why one might _not_ want to use BSD, but this is the silliest yet!
#pragma ident "@(#)mutex.c 1.28 05/06/08 SMI"/*
* Big Theory Statement for mutual exclusion locking primitives.
*
* A mutex serializes multiple threads so that only one thread
* (the "owner" of the mutex) is active at a time. See mutex(9F)
* for a full description of the interfaces and programming model.
* The rest of this comment describes the implementation.
*
* Mutexes come in two flavors: adaptive and spin. mutex_init(9F)
* determines the type based solely on the iblock cookie (PIL) argument.
* PIL > LOCK_LEVEL implies a spin lock; everything else is adaptive.
*
* Spin mutexes block interrupts and spin until the lock becomes available.
* A thread may not sleep, or call any function that might sleep, while
* holding a spin mutex. With few exceptions, spin mutexes should only
* be used to synchronize with interrupt handlers.
*
* Adaptive mutexes (the default type) spin if the owner is running on
* another CPU and block otherwise. This policy is based on the assumption
* that mutex hold times are typically short enough that the time spent
* spinning is less than the time it takes to block. If you need mutual
* exclusion semantics with long hold times, consider an rwlock(9F) as
* RW_WRITER. Better still, reconsider the algorithm: if it requires
* mutual exclusion for long periods of time, it's probably not scalable.
*
* Adaptive mutexes are overwhelmingly more common than spin mutexes,
* so mutex_enter() assumes that the lock is adaptive. We get away
* with this by structuring mutexes so that an attempt to acquire a
* spin mutex as adaptive always fails. When mutex_enter() fails
* it punts to mutex_vector_enter(), which does all the hard stuff.
*
Yes, the locking code in mutex.c is fascinating. They dynamically switch between spin-locks and adaptive backoff locks based on who is running and who is locking what. This is the stuff that makes Solaris scale to dozens of processors out-of-the-box.
There are lots of reasons for not upgrading. Here is an interesting one I heard about:
At a large General Electric office building, it was determined that they could not upgrade PCs because that AC wiring in the walls of the old building couldn't handle the power requirements of new PCs. Their only reasonable solution was to transition to terminal computing using the existing machines, or with lower-power thin clients.
Why does your sister have debt? If she didn't get her PhD and basic living expenses paid for, like most PhD programs, then something was very wrong.
Getting a PhD costs a lot in opportunity cost, but you shouldn't go into debt.
Re:Hyperthreading is not easier than multicore.
on
AMD Quad Cores, Oh My
·
· Score: 1
Yes, you are. If you care that much about communicating between threads you've already lost. Many good multi-tasked applications run communicating as little as possible (all communication is a serialization point), here multiple cores means you can run two real tasks, while "hyperthreading" means you can run two tasks at a little over 50%.
Dude, go take an architectural class. The idea behind Symmetric Multithreading (SMT) is that the majority of real programs do not achieve the IPC (instructions per cycle) that the processor is capable of giving. Things like cache misses, branch mispredictions and other long latency events cause the processor's functional execution resources to go unused. However while one thread is block, other threads can be scheduled. The only time that SMT (or "hyperthreading") will hurt you is if both threads are running near-optimal and could fully utilize the function units by themselves. In practical terms, there are other effects from SMT such as cache pollution, but these are often second-order.
Regarding communication, well yes, if you take some parallel programming or architecture classes you will learn about the communication to computation ratio. Simply put, if a parallel code spends more time communicating than computing, then you will not see a speedup. However a SMT or CMP lowers the communication portion of that ratio by at least an order of magnitude.
You do know that Apache is not compute-bound. Therefore SMT works quite well with Apache because threads typically spend most of their time waiting for cache misses and I/O.
Re:Hyperthreading is not easier than multicore.
on
AMD Quad Cores, Oh My
·
· Score: 1
Wrong. The communication latency with SMT and CMPs is much much lower than that of SMPs. This means that programs with fine-grained granularity will actually exhibit a speedup rather than a slowdown.
If you've ever written parallel codes for an SMP, this happened quite frequently. In fact, I'm familiar with programs where the programmers couldn't crack the problem and ended up running their multithreaded parallel code on a single processor to get the best performance.
Sorry, you are wrong and I spoke with Patterson just a few days ago at the Internation Symposium of Computer Architecture in Madison, WI.
Patterson and Hennessy argued for RISC in the 80s before technology allowed Intel and AMD to burn 3 million transistors on a CISC->RISC translation layer. They did not forsee x86 hanging on until the mid-90s to enable this. So yes, they are wrong about the death of x86 but modern out-of-order superscalar pipelines are all based on the principles of the early RISC 5-state pipelines.
But your post claims they are failures and you are dead wrong. Among numerous other contributions, you can thank Patterson (and Randy Katz) for RAID.
Of the old-school big-iron UNIX platforms (Alpha/Tru64, PA-RISC/HP-UX, Sparc/Solaris), the only kernel panic I have ever witnessed was HP-UX on a PA-RISC machine. I suppose it could have been a hardware problem...and my only experience is with workstation machines.
That said, I see a kernel panic or freeze on Linux x86 at least a couple times a year.
In fact, repackaging used equipment is not too uncommon.
I know of a small company that sells a $1 million device to a very niche market. A certain component of this device is only manufactured by a few companies world-wide and requires huge technical know-how and manufacturing capabilities. None of the big boys will sell the component individually for various reasons including the fact that they don't offer this niche capability of the small company's product and are probably trying to develop it themselves.
So what does this small company do? They purchased used equipment on the Latin American market, strip the specialized part, and repackage it in their $1 million product.
(Yes, I am being quite vague on purpose to hide the details)
...and people start realizing Linux can do everything windows can and more, for the low low cost of $0.00.
Right...gaming is the primary reason why people 90-95% of people/business choose Windows over Linux. Sorry, but it will take a lot more than the transition of gaming to consoles in order for Linux to capture more than 25% of the market for desktops. Many of these reasons are business-related (yes, big bad Microsoft has a nice monopoly), but many are technical as well. Even putting aside things like the user interface and lack of a clear winner of a component model (kParts, Bonobo, what else?), even the device driver model in the Linux kernel sort of stinks for closed-source drivers. Just ask nVidia and the silly wrapper they have to maintain in order to directly access kernel structures.
You are wrong. I did exactly this with SBC DSL and now I have unrestricted access to port 25 after calling and asking for it. By default, it is blocked.
I devoted long hours to a PowerPoint presentation. In about hour 12 or 13, PowerPoint 2002 kept crashing whenever I tried to open the file. Unfortunately I did not have any previous revisions before the save which messed things up.
I thought I was hosed, but I tried opening it in OpenOffice and it worked fine. Then a friend suggested I run "Office Update". Once I did this, PowerPoint opened the file without problems.
Can you tell apt-get to only install the latest security patches and not the latest versions of all the software? Because when your life or job relies on knowing the particular quirks of various software revisions, getting a change I didn't expect is definitely not what I want.
Linux modules all run in the same address space. Module functionality is invoked with a function call. A microkernel typically uses a message-passing approach and modules are isolated from one another. A small context switch must occur when invoking something in a microkernel module. Hence the overhead of a microkernel is much greater than a monolithic kernel. However many argue that the overheads are worth the organization and safety advantages that the microkernel gives you-- especially nowadays where for typical appliations, the OS accounts for a tiny fraction of overall runtime.
I see Linux crash on our cluster of 100 Sun Opteron boxes daily.
The hardware is rock solid because it originally shipped with Solaris. The Sun reps said that we are one of their few customers running 64-bit Linux because it isn't stable enough.
I deal with an Opteron cluster of 100 nodes. The hardware is by Sun and is solid (it shipped with Solaris...we converted to Linux recently).
The stability of Linux x86-64 is aweful. Crashes all the time and manually restarting the nodes is getting painful...luckily this is a scientific compute cluster and the apps can deal with it.
The Sun reps recommended that, if we wanted to use Linux, that we use 32-bit until the stability increases. They say that most of their customers using Linux with Opterons are using 32-bit for the same reason.
Frankly we are surprised, but after talking with other colleagues from elsewhere, in the high-performance computing realm, it is well known that Linux x86-64 is not there.
toilets aren't modular, you cant just go buy one and put it in like legos, it requires a lot of plumbing and floorwork, too
Not in the U.S. where 99.999% of homes have a standard flange in which the center (or "rough-in") is 12 inches from the wall. Replacing a toilet is one of the easier DIY plumbing projects you can do.
Slashdot Mirror
While getting my B.S. in Electrical Engineering at a Big-10 university, I never had to write anything longer than a couple pages (besides a technical lab report).
On the other hand, the asker of the question is a snob and obviously hasn't dealt with a typical community where a large percentage of people do not have a college education. Heck, go to Milwaukee and you will learn that the high school drop-out rate is beyond 50%.
ECS are great boards if you can deal with kinks. For example, I had random freezes after I upgraded from an Athlon 900MHz to a Athlon XP 1800. I found a site that outlined how to solve the problem by soldering on an additional resistor to adjust the voltage of one of the supply lines to the CPU. Scary procedure, but it worked like a charm!
Theo de Raadt: I don't know. I have never run Linux.
Torvalds says the same thing about Windows. I suggest that creators and active developers of open-source operating systems should start using rival systems to learn and carry over the best practices. This is quite common in industry and the attitude displayed in these quotes show arrogance and ignorance.
1. /usr/local. Everything that you add afterwards goes in there. It's just extra to type. And is apache config in /usr/local/apache/conf or /usr/local/etc/apache/conf ?
/usr/local is exactly where additional software, not included in the base OS, should be installed. More typing?? For what? /usr/local should be in your path and manually going to this directory should be rare.
Maybe a more experience sys admin can chime in here, but
There are many reasons why one might _not_ want to use BSD, but this is the silliest yet!
From the comment:
/*
#pragma ident "@(#)mutex.c 1.28 05/06/08 SMI"
* Big Theory Statement for mutual exclusion locking primitives.
*
* A mutex serializes multiple threads so that only one thread
* (the "owner" of the mutex) is active at a time. See mutex(9F)
* for a full description of the interfaces and programming model.
* The rest of this comment describes the implementation.
*
* Mutexes come in two flavors: adaptive and spin. mutex_init(9F)
* determines the type based solely on the iblock cookie (PIL) argument.
* PIL > LOCK_LEVEL implies a spin lock; everything else is adaptive.
*
* Spin mutexes block interrupts and spin until the lock becomes available.
* A thread may not sleep, or call any function that might sleep, while
* holding a spin mutex. With few exceptions, spin mutexes should only
* be used to synchronize with interrupt handlers.
*
* Adaptive mutexes (the default type) spin if the owner is running on
* another CPU and block otherwise. This policy is based on the assumption
* that mutex hold times are typically short enough that the time spent
* spinning is less than the time it takes to block. If you need mutual
* exclusion semantics with long hold times, consider an rwlock(9F) as
* RW_WRITER. Better still, reconsider the algorithm: if it requires
* mutual exclusion for long periods of time, it's probably not scalable.
*
* Adaptive mutexes are overwhelmingly more common than spin mutexes,
* so mutex_enter() assumes that the lock is adaptive. We get away
* with this by structuring mutexes so that an attempt to acquire a
* spin mutex as adaptive always fails. When mutex_enter() fails
* it punts to mutex_vector_enter(), which does all the hard stuff.
*
Yes, the locking code in mutex.c is fascinating. They dynamically switch between spin-locks and adaptive backoff locks based on who is running and who is locking what. This is the stuff that makes Solaris scale to dozens of processors out-of-the-box.
There are lots of reasons for not upgrading. Here is an interesting one I heard about:
At a large General Electric office building, it was determined that they could not upgrade PCs because that AC wiring in the walls of the old building couldn't handle the power requirements of new PCs. Their only reasonable solution was to transition to terminal computing using the existing machines, or with lower-power thin clients.
Why does your sister have debt? If she didn't get her PhD and basic living expenses paid for, like most PhD programs, then something was very wrong.
Getting a PhD costs a lot in opportunity cost, but you shouldn't go into debt.
Yes, you are. If you care that much about communicating between threads you've already lost. Many good multi-tasked applications run communicating as little as possible (all communication is a serialization point), here multiple cores means you can run two real tasks, while "hyperthreading" means you can run two tasks at a little over 50%.
Dude, go take an architectural class. The idea behind Symmetric Multithreading (SMT) is that the majority of real programs do not achieve the IPC (instructions per cycle) that the processor is capable of giving. Things like cache misses, branch mispredictions and other long latency events cause the processor's functional execution resources to go unused. However while one thread is block, other threads can be scheduled. The only time that SMT (or "hyperthreading") will hurt you is if both threads are running near-optimal and could fully utilize the function units by themselves. In practical terms, there are other effects from SMT such as cache pollution, but these are often second-order.
Regarding communication, well yes, if you take some parallel programming or architecture classes you will learn about the communication to computation ratio. Simply put, if a parallel code spends more time communicating than computing, then you will not see a speedup. However a SMT or CMP lowers the communication portion of that ratio by at least an order of magnitude.
You do know that Apache is not compute-bound. Therefore SMT works quite well with Apache because threads typically spend most of their time waiting for cache misses and I/O.
Wrong. The communication latency with SMT and CMPs is much much lower than that of SMPs. This means that programs with fine-grained granularity will actually exhibit a speedup rather than a slowdown.
If you've ever written parallel codes for an SMP, this happened quite frequently. In fact, I'm familiar with programs where the programmers couldn't crack the problem and ended up running their multithreaded parallel code on a single processor to get the best performance.
Also the designer of Sun's "Rock" processor is Marc Trembley from Sweden. He started as an H1-B
Sorry, you are wrong and I spoke with Patterson just a few days ago at the Internation Symposium of Computer Architecture in Madison, WI.
Patterson and Hennessy argued for RISC in the 80s before technology allowed Intel and AMD to burn 3 million transistors on a CISC->RISC translation layer. They did not forsee x86 hanging on until the mid-90s to enable this. So yes, they are wrong about the death of x86 but modern out-of-order superscalar pipelines are all based on the principles of the early RISC 5-state pipelines.
But your post claims they are failures and you are dead wrong. Among numerous other contributions, you can thank Patterson (and Randy Katz) for RAID.
Of the old-school big-iron UNIX platforms (Alpha/Tru64, PA-RISC/HP-UX, Sparc/Solaris), the only kernel panic I have ever witnessed was HP-UX on a PA-RISC machine. I suppose it could have been a hardware problem...and my only experience is with workstation machines.
That said, I see a kernel panic or freeze on Linux x86 at least a couple times a year.
Deke Slayton, Astronaut, Wisconsin
So sad.
Dream on x86 fanboys...
I refer you to http://www.spec.org for any microprocessor evaluation purposes.
In fact, repackaging used equipment is not too uncommon.
I know of a small company that sells a $1 million device to a very niche market. A certain component of this device is only manufactured by a few companies world-wide and requires huge technical know-how and manufacturing capabilities. None of the big boys will sell the component individually for various reasons including the fact that they don't offer this niche capability of the small company's product and are probably trying to develop it themselves.
So what does this small company do? They purchased used equipment on the Latin American market, strip the specialized part, and repackage it in their $1 million product.
(Yes, I am being quite vague on purpose to hide the details)
Right...gaming is the primary reason why people 90-95% of people/business choose Windows over Linux. Sorry, but it will take a lot more than the transition of gaming to consoles in order for Linux to capture more than 25% of the market for desktops. Many of these reasons are business-related (yes, big bad Microsoft has a nice monopoly), but many are technical as well. Even putting aside things like the user interface and lack of a clear winner of a component model (kParts, Bonobo, what else?), even the device driver model in the Linux kernel sort of stinks for closed-source drivers. Just ask nVidia and the silly wrapper they have to maintain in order to directly access kernel structures.
You are wrong. I did exactly this with SBC DSL and now I have unrestricted access to port 25 after calling and asking for it. By default, it is blocked.
I devoted long hours to a PowerPoint presentation. In about hour 12 or 13, PowerPoint 2002 kept crashing whenever I tried to open the file. Unfortunately I did not have any previous revisions before the save which messed things up.
I thought I was hosed, but I tried opening it in OpenOffice and it worked fine. Then a friend suggested I run "Office Update". Once I did this, PowerPoint opened the file without problems.
Did this dude bother to update his PowerPoint?
Can you tell apt-get to only install the latest security patches and not the latest versions of all the software? Because when your life or job relies on knowing the particular quirks of various software revisions, getting a change I didn't expect is definitely not what I want.
Linux modules all run in the same address space. Module functionality is invoked with a function call. A microkernel typically uses a message-passing approach and modules are isolated from one another. A small context switch must occur when invoking something in a microkernel module. Hence the overhead of a microkernel is much greater than a monolithic kernel. However many argue that the overheads are worth the organization and safety advantages that the microkernel gives you-- especially nowadays where for typical appliations, the OS accounts for a tiny fraction of overall runtime.
I see Linux crash on our cluster of 100 Sun Opteron boxes daily.
The hardware is rock solid because it originally shipped with Solaris. The Sun reps said that we are one of their few customers running 64-bit Linux because it isn't stable enough.
I deal with an Opteron cluster of 100 nodes. The hardware is by Sun and is solid (it shipped with Solaris...we converted to Linux recently).
The stability of Linux x86-64 is aweful. Crashes all the time and manually restarting the nodes is getting painful...luckily this is a scientific compute cluster and the apps can deal with it.
The Sun reps recommended that, if we wanted to use Linux, that we use 32-bit until the stability increases. They say that most of their customers using Linux with Opterons are using 32-bit for the same reason.
Frankly we are surprised, but after talking with other colleagues from elsewhere, in the high-performance computing realm, it is well known that Linux x86-64 is not there.
for the Dumbest Slashdot Story Ever?
toilets aren't modular, you cant just go buy one and put it in like legos, it requires a lot of plumbing and floorwork, too
Not in the U.S. where 99.999% of homes have a standard flange in which the center (or "rough-in") is 12 inches from the wall. Replacing a toilet is one of the easier DIY plumbing projects you can do.