Only because Python uses a refcounting garbage collector.
Refcounting itself isn't necessarily the problem; it's using a rudimentary implementation that bogs down. I read a paper a while back where they successfully experimented with a high-tech refcounting gc algorithm specifically because it was amenable to parallel operation on multiple CPUs.
By using a variety of tricks, they were able to avoid actually having to update refcounts for the vast majority of writes (most notably all stack references), and the mutex acquisition was limited to a couple per thread per gc cycle (one dedicated thread did periodic adjustments in a cyclical fashion).
I thought it was pretty interesting because reference counting can have more cache-friendly behavior than copying gc or mark-sweep approaches.
OK, so we'll to agree that evolution is only approximately right, but the approximation error w.r.t. 100% right is immeasurably small unless the species in question are traveling at a significant fraction of the speed of light relative to the paleontologist.
It's posts like these that make me think that I'm the only one with 7 programs on the task bar, 12 in the system tray, assorted server processes, and 32 tabs open in Firefox (come on, 1 thread per tab!!).
I'd be willing to bet a good deal of money that almost all of those tasks are currently asleep and waiting for input, a timer signal or external I/O. Such processes don't need *any* cores unless and until they wake up.
(The big exception for most people would be having flash ads running in those 32 firefox tabs. The way to solve that problem without adding more cores is by installing flashblock.)
Right now "ps" says that my system is running 127 different processes. Current CPU utilization? 0.7%.
However, everyone I know runs multiple applications just by booting their OS.
But not everybody knows what their system is doing. I do: I always keep a CPU load chart in my KDE taskbar, and for interactive usage I probably use one core less than 3% of the time, and both cores about 0.1% of the time.
If I am transcoding a video, then one core gets pegged. However, I would never notice load on the processor on even with a single-core CPU if I just ran the transcode under "nice". It might take 3% longer to run because it waits for the interactive stuff, but that's insignificant.
But I don't run transcoding on my workstation anyway. Why? Because all the I/O continuosly flushes out my disk buffers for other processes. That makes my interactive apps seem slower than crap anyway because they have to hit the disk every time some of their data or program image gets flushed out. My dual cores do nothing to address that issue. I run transcode jobs on a server box where they won't bug anybody.
The only place dual core would really help most people with typical single-threaded apps is if they run at least two copies of programs heavy on number crunching but light on I/O and memory bandwidth, like $FavoriteCause@Home. Other than that, people will have to wait for multithreaded user apps to get much real-world benefit out of multicore CPUs.
Do not open or crush battery. Severe risk of releasing a life-sucking vortex.
Do not dispose in fire. Doing so could loose a storm of flaming vortices.
Do not use this battery on carnival rides, while figure skating, or place in spinning clothes washer. Risk of severe gyroscopic reactions, which may lead to property damage, personal injury or death.
Well, at least pimps, hos and playas are merely indifferent to science. They don't actively work to discredit it, suppress it or redefine it as something else.
Back when 10MB HDDs with 100ms access times where prevalent and floppies were all the rage, buffered I/O was a good idea. If I find that an application is somehow overwhelming my 3.0GB/s SATA bus and 10,000 RPM hard drive, I'll be sure to turn this "feature" on.
Your bus bandwidth and drive RPM have nothing to do with track-to-track seek time, which is the bottleneck for synchronous writes, and which hasn't improved much more than 10X since those days. Meanwhile, your CPU is almost 10000X faster. So you're exactly wrong: you need more buffering than ever in order to actually use your additional CPU performance as more than a space heater.
The filesystem should be hitting the metal about 0.001 microseconds after I call write() or whatever the function is.
If that's the behavior you expect, then you need to be running your apps under an OS like DOS, not POSIX or Windows (which both clearly specify that this is *not* how they function).
and were therefore selling off stuff like broken computers and the toilet-paper dispenser from the restroom
At the checkout:
"You know, I've got a couple of these toilet paper dispensers, and they always seem to jam at the most inopportune times. Could I interest you in purchasing our exclusive 5-year extended warranty protection plan for only $179 more? It would really give you more peace of mind in the bathroom."
By making practically everything into userland, including hardware drivers, filesystems, GUI's, etc. In most OS'es that's a lot of code, and there are bugs and vulnerabilities in there too, you know.
Maybe so, but not relevant to the original topic which was buffer overflows in user applications.
By enforcing strict limitations on what each part can do. In a common OS, malicious code can do everything a normal user can do. In a microkernel OS, that part may have no disk access rights whatsover, and only permission to communicate with a small number of other components. Such restrictions can be enforced strongly, and everywhere throughout the system. That makes breakage much more a local event, with limited damage.
That doesn't really have anything to do with the kernel architecture. You're talking about a capabilites-based system, and/or splitting user apps into groups of sandboxed subprocesses, both of which can be done with or without a micorkernel. What you want requires rewriting all end-user applications from scratch, but it could be done with only minor modifications to standard kernels.
Even Microsoft was able to introduce a limited form of that concept into Vista with their low-privileged IE sandbox.
I never thought that I had problems with my CDs (some of which are 25 years old) until I ripped them all using "grip" with cdparanoia turned on. A small number of the CDs ripped at very slow speeds (sometimes less than 1X), which I assume was the result of cdparanoia doing multiple read passes to try to compensate for errors.
However, since standard CD players have logic to hide small errors, I never heard any problems with them anyway. Maybe audiophiles disagree. IMO, probably the main benefit from this technology would be avoiding slow ripping times, which doesn't seem worth much to me.
I'll rephrase.. The space shuttle software seems to be doing it just fine.
They have invested a lot of money in debugging the software so that the odds of seeing a bug during operation are very low (especially compared to the risks of the Shuttle's Rube Goldberg physical design). However, as with any nontrivial program, it is a certainty that bugs remain, and if they were to invest significantly more resources looking for bugs, they'd find some.
OMFG!!! Obama's going to raise the marginal tax rate by a few of percentage points! Rather than lose a couple of points on the net gain, let's all panic and sell our stock at a 50% loss of the basis!!!
Unless there is a EULA, (which only software claims to have, and the validity of that is debatable) there is NO LICENSE for copyrighted content. NO CONTRACTS and NO AGREEMENTS.
I damned well have a right right to play content I bought, regardless of what the whiney authors want. Why? Because I didn't agree with the author about anything, and I'm not making a new copy.
Once you sold me your crappy movie or music, I get to watch it without your permission or blessing. I can also scribble on it, piss on it, or let my dog play with it. You might use the DMCA to create technical tricks to restrict my rights, but other than that bogus law (which is what I was complaining about in the first place) there still is no license, no agreement, no contract and no moral justification for you to control what I do with it, as long as I don't make new copies of it.
I have a box in which I seal a cat along with my computer and a radioactive isotope. I connect an electronic monitor to the cat, and it is rigged up to click the "Agree" button if the cat dies.
Bearing in mind that most TVs built in the past 20 years (at least) suppress the sound and picture if no signal is received, did they display simulated static?
Oddly enough, even though the TV is only about 5 years old, it does show snow on the antenna input. It cuts the sound after a short burst of noise.
...it was actually kind of entertaining. The station that stopped last night had some fun and went old-school. They announced the end of the broadcast day (for good), played the national anthem over patriotic images of the flag.
After that, they put up the old Indian Head test pattern and audio tone for a couple of minutes. At the stroke of midnight, it cut to static. It was just like nightly sign-offs when I was a little kid, and it almost made me misty-eyed.
The one that went out this afternoon showed a bunch of snippets from the past 50 years, then they showed a live coverage of one of their engineers out in the transmitter shack pushing the "OFF" button. The instant cut to static was good for a laugh.
If the DRM is disclosed up front and you still buy the product then you have no one to blame but yourself.
Most DRM would be irrelevant if the government weren't willing to throw people in the slammer for disabling it or helping others to disable it. Without this radical government intrusion into your own personal affairs, you wouldn't have to blame anyone because most DRM would be hacked into oblivion.
Slashdot Mirror
Only because Python uses a refcounting garbage collector.
Refcounting itself isn't necessarily the problem; it's using a rudimentary implementation that bogs down. I read a paper a while back where they successfully experimented with a high-tech refcounting gc algorithm specifically because it was amenable to parallel operation on multiple CPUs.
By using a variety of tricks, they were able to avoid actually having to update refcounts for the vast majority of writes (most notably all stack references), and the mutex acquisition was limited to a couple per thread per gc cycle (one dedicated thread did periodic adjustments in a cyclical fashion).
I thought it was pretty interesting because reference counting can have more cache-friendly behavior than copying gc or mark-sweep approaches.
OK, so we'll to agree that evolution is only approximately right, but the approximation error w.r.t. 100% right is immeasurably small unless the species in question are traveling at a significant fraction of the speed of light relative to the paleontologist.
It's posts like these that make me think that I'm the only one with 7 programs on the task bar, 12 in the system tray, assorted server processes, and 32 tabs open in Firefox (come on, 1 thread per tab!!).
I'd be willing to bet a good deal of money that almost all of those tasks are currently asleep and waiting for input, a timer signal or external I/O. Such processes don't need *any* cores unless and until they wake up.
(The big exception for most people would be having flash ads running in those 32 firefox tabs. The way to solve that problem without adding more cores is by installing flashblock.)
Right now "ps" says that my system is running 127 different processes. Current CPU utilization? 0.7%.
However, everyone I know runs multiple applications just by booting their OS.
But not everybody knows what their system is doing. I do: I always keep a CPU load chart in my KDE taskbar, and for interactive usage I probably use one core less than 3% of the time, and both cores about 0.1% of the time.
If I am transcoding a video, then one core gets pegged. However, I would never notice load on the processor on even with a single-core CPU if I just ran the transcode under "nice". It might take 3% longer to run because it waits for the interactive stuff, but that's insignificant.
But I don't run transcoding on my workstation anyway. Why? Because all the I/O continuosly flushes out my disk buffers for other processes. That makes my interactive apps seem slower than crap anyway because they have to hit the disk every time some of their data or program image gets flushed out. My dual cores do nothing to address that issue. I run transcode jobs on a server box where they won't bug anybody.
The only place dual core would really help most people with typical single-threaded apps is if they run at least two copies of programs heavy on number crunching but light on I/O and memory bandwidth, like $FavoriteCause@Home. Other than that, people will have to wait for multithreaded user apps to get much real-world benefit out of multicore CPUs.
Do not open or crush battery. Severe risk of releasing a life-sucking vortex.
Do not dispose in fire. Doing so could loose a storm of flaming vortices.
Do not use this battery on carnival rides, while figure skating, or place in spinning clothes washer. Risk of severe gyroscopic reactions, which may lead to property damage, personal injury or death.
Well, at least pimps, hos and playas are merely indifferent to science. They don't actively work to discredit it, suppress it or redefine it as something else.
Back when 10MB HDDs with 100ms access times where prevalent and floppies were all the rage, buffered I/O was a good idea. If I find that an application is somehow overwhelming my 3.0GB/s SATA bus and 10,000 RPM hard drive, I'll be sure to turn this "feature" on.
Your bus bandwidth and drive RPM have nothing to do with track-to-track seek time, which is the bottleneck for synchronous writes, and which hasn't improved much more than 10X since those days. Meanwhile, your CPU is almost 10000X faster. So you're exactly wrong: you need more buffering than ever in order to actually use your additional CPU performance as more than a space heater.
The filesystem should be hitting the metal about 0.001 microseconds after I call write() or whatever the function is.
If that's the behavior you expect, then you need to be running your apps under an OS like DOS, not POSIX or Windows (which both clearly specify that this is *not* how they function).
and were therefore selling off stuff like broken computers and the toilet-paper dispenser from the restroom
At the checkout:
"You know, I've got a couple of these toilet paper dispensers, and they always seem to jam at the most inopportune times. Could I interest you in purchasing our exclusive 5-year extended warranty protection plan for only $179 more? It would really give you more peace of mind in the bathroom."
Courts enforce contracts, not the government.
I think that you've been watching too much Judge Judy.
By making practically everything into userland, including hardware drivers, filesystems, GUI's, etc. In most OS'es that's a lot of code, and there are bugs and vulnerabilities in there too, you know.
Maybe so, but not relevant to the original topic which was buffer overflows in user applications.
By enforcing strict limitations on what each part can do. In a common OS, malicious code can do everything a normal user can do. In a microkernel OS, that part may have no disk access rights whatsover, and only permission to communicate with a small number of other components. Such restrictions can be enforced strongly, and everywhere throughout the system. That makes breakage much more a local event, with limited damage.
That doesn't really have anything to do with the kernel architecture. You're talking about a capabilites-based system, and/or splitting user apps into groups of sandboxed subprocesses, both of which can be done with or without a micorkernel. What you want requires rewriting all end-user applications from scratch, but it could be done with only minor modifications to standard kernels.
Even Microsoft was able to introduce a limited form of that concept into Vista with their low-privileged IE sandbox.
How is a microkernel going to protect against a phenomenon that happens completely within userland?
You mean, even LaTeX is not safe against Viruses? What should we use then?
LaMbSkIn?
I never thought that I had problems with my CDs (some of which are 25 years old) until I ripped them all using "grip" with cdparanoia turned on. A small number of the CDs ripped at very slow speeds (sometimes less than 1X), which I assume was the result of cdparanoia doing multiple read passes to try to compensate for errors.
However, since standard CD players have logic to hide small errors, I never heard any problems with them anyway. Maybe audiophiles disagree. IMO, probably the main benefit from this technology would be avoiding slow ripping times, which doesn't seem worth much to me.
Only if you can prove that your formal verification process is bug-free. (Which you can't.)
Both non-software related..
I'll rephrase.. The space shuttle software seems to be doing it just fine.
They have invested a lot of money in debugging the software so that the odds of seeing a bug during operation are very low (especially compared to the risks of the Shuttle's Rube Goldberg physical design). However, as with any nontrivial program, it is a certainty that bugs remain, and if they were to invest significantly more resources looking for bugs, they'd find some.
OMFG!!! Obama's going to raise the marginal tax rate by a few of percentage points! Rather than lose a couple of points on the net gain, let's all panic and sell our stock at a 50% loss of the basis!!!
Investors like you are real geniuses.
Unless there is a EULA, (which only software claims to have, and the validity of that is debatable) there is NO LICENSE for copyrighted content. NO CONTRACTS and NO AGREEMENTS.
I damned well have a right right to play content I bought, regardless of what the whiney authors want. Why? Because I didn't agree with the author about anything, and I'm not making a new copy.
Once you sold me your crappy movie or music, I get to watch it without your permission or blessing. I can also scribble on it, piss on it, or let my dog play with it. You might use the DMCA to create technical tricks to restrict my rights, but other than that bogus law (which is what I was complaining about in the first place) there still is no license, no agreement, no contract and no moral justification for you to control what I do with it, as long as I don't make new copies of it.
I have a box in which I seal a cat along with my computer and a radioactive isotope. I connect an electronic monitor to the cat, and it is rigged up to click the "Agree" button if the cat dies.
The hardware remains yours, and you are completely free to fuck around with it as much as you like.
No, the DMCA says I'm not free to do that. That's the point.
Bearing in mind that most TVs built in the past 20 years (at least) suppress the sound and picture if no signal is received, did they display simulated static?
Oddly enough, even though the TV is only about 5 years old, it does show snow on the antenna input. It cuts the sound after a short burst of noise.
After that, they put up the old Indian Head test pattern and audio tone for a couple of minutes. At the stroke of midnight, it cut to static. It was just like nightly sign-offs when I was a little kid, and it almost made me misty-eyed.
The one that went out this afternoon showed a bunch of snippets from the past 50 years, then they showed a live coverage of one of their engineers out in the transmitter shack pushing the "OFF" button. The instant cut to static was good for a laugh.
This is not contract law. It's illegal to circumvent DRM without any contract.
If you can't get the basic facts straight before spouting your opinions, at least try to be polite.
My hardware can operate on information, but the hardware is still my property.
If the DRM is disclosed up front and you still buy the product then you have no one to blame but yourself.
Most DRM would be irrelevant if the government weren't willing to throw people in the slammer for disabling it or helping others to disable it. Without this radical government intrusion into your own personal affairs, you wouldn't have to blame anyone because most DRM would be hacked into oblivion.