Certainly true for Joels world of market economy..
on
The Duct Tape Programmer
·
· Score: 3, Insightful
Duct tape programmers may be invaluable tools in Joels world of overpervasive market economy and the corporate, but in some areas of application duct tape just does not cut it. Mission critical applications, like those used in health "industry", expensive satellites and other kind of space vessels, tunnel digging machines and what not - everything that just cannot fail - will not really benefit from Joels so cleverly coined "duct tape programmer" character. Not sure if Joel included these areas as applicable for the "duct tape programmer" attitude, but I just wanted to say I don't think they are. Let duct tape programmers develop Photoshop, and all those benemoths of software that runs slower the faster machines we throw at them, occupy more space for the same set of features and so on and so on - probably nobody notices that anymore, as we all are sworn to content. But the few areas where software quality makes it or breaks it, Joel is off the mark, IMO.
Just like any other method, it will not work, because nature has a knack of finding a way out. Mosquito sprays, shark repellants - all that does, is bring about mutations in species, so that the supposed repellant can be overcome with ease. Results are repellent-insensitive mosquitoes, sharks impervious to ultrasound etc.
Seems like everyone is discussing the more technical details of this incident. I, for one, am much more "interested" in the moralistic side. I find it lowlife that this scumbag could not be a man enough to realize the woman wanted to fuck someone else, and was so desperate as to reduce himself to a stalker, and not even a stalker that you can actually identify as a stalker, but a stalker that is himself "stealthy". After all, planting spyware, provided you don't get caught, does not get more anonymous than that. Wussy. Then again, our "human nature" takes the best of us every single time. Practically, the five disturbing feelings (after Buddhas terminology) - jealosy, anger, pride, ignorance and attachmen/desire - rule our societies.
Yes you are right. I was afraid I was mistaken there. But what I was trying to say is that at one point the unknown becomes a fact, as in there is a moment where the gender is a fact. Before that time, there is time when it is impossible to know the gender. Whether that time includes the time when millions of sperm cells swim towards the egg, or time even before that, I don't know. I only suggested that at one point the "no gender" becomes "gender".
Actually, you are not far from the truth. Buddhism is pretty damn logical at times;-) Like, they say, humans are reborn as many different species depending on general tendencies. I always liked to look at peoples faces to see diverse animal features. Not without reason we attribute some behavior to be "rat" like, etc. Some people walk like bears. Some smile like tigers. It is the stream of conciousness that takes many forms depending on what the tendency is. After all it is pretty logical that if you feel like a rat whole your life, why not BE a rat? For example, they say if you are really really lazy and like uneventful life, you have a fair chance at being reborn as a large fish - a whale or tiger shark or a giant jellyfish.
I am all for scientific research and evidence study, but since I started with buddhism, it always struck me why cannot we think backwards, as in girls fear spiders not because simple because they are girls, but they are born girls because they fear spiders. After all the gender is decided at one point after inception. Likewise boys like video games because they are born boys because they like video games. No direct evidence suggests that because girls express fear when looking at images of spiders, it is because of evolution. It simply suggests that already after birth there is some difference between sexes, but this difference can be attributed to a whole lot of reasons. But of course even evolution is explained by buddhism to have strong scientific reality, as in scpecies progress into other species from both an adaptational and karmic conditions.
They have two different goals. ALSA aims to be a generic API for interfacing a sound card. PulseAudio is a "sound server" - another layer on top of whatever API (ALSA usually) is underneath it, to provide more fine grained and desktop-worthy API to modern applications, like per-app volume control and seamless sound redirection. I welcome ideas of both, they are not competitors unless either decides to "extend" their functionality.
Why mod this insightful? Just because ALSA proxies OSS, does not mean it HAS to. It is your choice, and choice is part of Linux philosophy. ALSA works fine with its own hardware drivers, without OSS involved at all. Which it usually does too. You are complaining that somebody gave you an option to use a soundcard with OSS-only mixer with ALSA applications. Where is the logic in that? It is like complaining that PulseAudio should be removed and buried because you don't use it, even though many find it convenient enough, even at the cost of increased system complexity and slightest resource usage increase.
Humans want money for everything. Pigeons don't. They are cheap in getting and owning:p They're also cute and assuming they don't become disease carriers, are good pets.
You are saying it as if if you had to snap a random group of IP packets you actually knew what to do with them? Infrastructure always has to be in place.
What about latency? Surely it is orders of magnitude larger with pigeons than with even worst possible fiber connections? We are talking minutes versus tens to hundreds of a second. Something anybody with knowledge on networks knows already. Then again, since for most IT companies bandwidth is more important than latency, I guess pigeons make more sense to them. In fact, that is what I would have used. Every time I had to send a gigabyte of media data back when I was in advertisement media business, I wish I had remembered about pigeons. So, for any case where latency is not a factor, pigeons rule. In all other cases however we need any kind of fiber.
Useful read, thanks. I should subscribe to lkml, after all these.
Well, as with any algorithm implementations, a good question would be - does BFS fail by design or by implementation? If "brain fuck" strategy just does not work, then it does not work, and Con will have to move on. If, however, it is a genuine step forward as far as user-centric schedulers go, but needs "debug, rinse, repeat" workflow on Mr. Kolivas' part due it being in "alpha" stage, then as you say, I also hope Con takes Ingo on. Certainly, if Con saw some improvements on some scenarios, the scheduler has to be worth something.
P.S. Compilers are getting more and more intelligent these days, and intelligence comes at the price of CPU cycles, so it would be more observant to say that indeed even with modern hardware, compilers developing in parallel, they still are keeping up to remain CPU-bound? But you are of course right about C compilers (which is what kernel stuff is built with), these develop much slower (lack of necessity, really) and thus the hardware has outran their needs by now, making them I/O bound indeed.
Well who knows, maybe instead of the elusive year of Linux on desktop, we should be expecting and applauding years of downstream personal automated-installing GNU/Linux distributions like LFS or diy-linux, which will let users to choose schedulers and what not. Not exactly something I expect to happen soon, but my feeling is GNU/Linux is being institutionalized. It is like if the trust is just not there to anything but the mainline. People assume that the majority is right here - that the maintainers of mainline kernel know best - and every other hacker in minority like Con, is just experimenting. What if we can distribute this trust better - use "non-standard" schedulers etc - then the benchmarking will reach the users and the truth will be distilled eventually. If Cons new scheduler is as good as he tries to paint it, build kernel and use it in thousands. Currently, all eyes are on mainline, which is what prevents choice, even though the choice is "potentially" there.
I am not sure what you are trying to paint here. If you have four cores, and do a compilation through 4 jobs, the compilation will race to complete and optimally should load all cores (especially since you explicitly told it to do it 4-way). Also, compilation is not all that I/O bound, it is more CPU bound. Anyways, I think I missed the meaning of your post entirely. Explain please...:-)
It is certainly a good thing - instant response (as far as the user is concerned, since "instant" is relative here). I have never used BeOS, and have to wonder - how was its "race-to-complete" task performance? If everything in the system was so catered to response timings but (concurrent) task performance suffered (in a pre-emptive multitasking OS, every task shares time with others, at least the CPU scheduler), then the user is not happy either. He/she wants instant response AND switft audio/video encoding/decoding (applications that are CPU bound).
I agree. Linux is too large (in the classic meaning of the english word) to run on a single scheduler. But then again, what is a _single_ scheduler? If it means a facility that can plug and unplug schedulers at runtime, let us say switch between CFS (or something even more server oriented) and BFS as it detects server-desktop border patterns, then I guess both Mr. Torvalds and Mr. Kolivas are happy. And users are happy too. The rigid unexplained reason that "we only need ONE scheduler, period." however puts an effective stop to the strategy. If the scheduler cannot be plugged in, i. e. statically linked, mainline kernel will stay with CFS, which it will, because the maintainers will not merge pluggable scheduler facility. Well, we will have to wait and see how this turns out. As a GNU/Linux desktop user, I care.
I think he means "forward looking" in the sense that scheduler does not collect samples from anything that already happened, it only makes decisions on what happens immediately after.
Great news:-) Now, will the kernel people with Mr. Torvalds at their head, restart the whole debate on pluggable schedulers. Since his scheduler, as he says, degrades beyond 16 CPUs, better options already exists for servers where I am guessing CFS is used. So, he may be back, but the road ahead is still as steep?
It is not the same plugin. Go visit Adobe.com and see for yourself. They have separate Windows and Linux versions. They are called versions for a reason. Part of code is shared, yes, but a good share of it is parts that interface the system, which are obviously not shared - because the systems are different.
Well, if applications crash when memory is exhausted on XO, that is a valid reason to hardcap the limit, I guess. Otherwise, it is worth remembering that resources are users property, not vendor. Vendor is trusted to manage these resources (that they do not own themselves) to their best degree of ability. They should not cross the line (something done far too often today. No make that "nearly always".) to assume ownership of these resources, by limiting users access to them. But like I said, if XO crashes, and the hardware simply is unable to isolate memory exceptions from the entire experience, there is no other choice. I doubt there is no workaround though. Even hardware without memory manager can be "programmed around" so as to not cause system-wide havoc when some component somewhere goes belly up.
The article that Slashot links to has an image on the top right corner of the page. It looks like something rendered in-game. Look at it, come back and tell me how it went.
Slashdot Mirror
Duct tape programmers may be invaluable tools in Joels world of overpervasive market economy and the corporate, but in some areas of application duct tape just does not cut it. Mission critical applications, like those used in health "industry", expensive satellites and other kind of space vessels, tunnel digging machines and what not - everything that just cannot fail - will not really benefit from Joels so cleverly coined "duct tape programmer" character. Not sure if Joel included these areas as applicable for the "duct tape programmer" attitude, but I just wanted to say I don't think they are. Let duct tape programmers develop Photoshop, and all those benemoths of software that runs slower the faster machines we throw at them, occupy more space for the same set of features and so on and so on - probably nobody notices that anymore, as we all are sworn to content. But the few areas where software quality makes it or breaks it, Joel is off the mark, IMO.
Just like any other method, it will not work, because nature has a knack of finding a way out. Mosquito sprays, shark repellants - all that does, is bring about mutations in species, so that the supposed repellant can be overcome with ease. Results are repellent-insensitive mosquitoes, sharks impervious to ultrasound etc.
Seems like everyone is discussing the more technical details of this incident. I, for one, am much more "interested" in the moralistic side. I find it lowlife that this scumbag could not be a man enough to realize the woman wanted to fuck someone else, and was so desperate as to reduce himself to a stalker, and not even a stalker that you can actually identify as a stalker, but a stalker that is himself "stealthy". After all, planting spyware, provided you don't get caught, does not get more anonymous than that. Wussy. Then again, our "human nature" takes the best of us every single time. Practically, the five disturbing feelings (after Buddhas terminology) - jealosy, anger, pride, ignorance and attachmen/desire - rule our societies.
Yes you are right. I was afraid I was mistaken there. But what I was trying to say is that at one point the unknown becomes a fact, as in there is a moment where the gender is a fact. Before that time, there is time when it is impossible to know the gender. Whether that time includes the time when millions of sperm cells swim towards the egg, or time even before that, I don't know. I only suggested that at one point the "no gender" becomes "gender".
Actually, you are not far from the truth. Buddhism is pretty damn logical at times ;-) Like, they say, humans are reborn as many different species depending on general tendencies. I always liked to look at peoples faces to see diverse animal features. Not without reason we attribute some behavior to be "rat" like, etc. Some people walk like bears. Some smile like tigers. It is the stream of conciousness that takes many forms depending on what the tendency is. After all it is pretty logical that if you feel like a rat whole your life, why not BE a rat? For example, they say if you are really really lazy and like uneventful life, you have a fair chance at being reborn as a large fish - a whale or tiger shark or a giant jellyfish.
I am all for scientific research and evidence study, but since I started with buddhism, it always struck me why cannot we think backwards, as in girls fear spiders not because simple because they are girls, but they are born girls because they fear spiders. After all the gender is decided at one point after inception. Likewise boys like video games because they are born boys because they like video games. No direct evidence suggests that because girls express fear when looking at images of spiders, it is because of evolution. It simply suggests that already after birth there is some difference between sexes, but this difference can be attributed to a whole lot of reasons. But of course even evolution is explained by buddhism to have strong scientific reality, as in scpecies progress into other species from both an adaptational and karmic conditions.
They have two different goals. ALSA aims to be a generic API for interfacing a sound card. PulseAudio is a "sound server" - another layer on top of whatever API (ALSA usually) is underneath it, to provide more fine grained and desktop-worthy API to modern applications, like per-app volume control and seamless sound redirection. I welcome ideas of both, they are not competitors unless either decides to "extend" their functionality.
Why mod this insightful? Just because ALSA proxies OSS, does not mean it HAS to. It is your choice, and choice is part of Linux philosophy. ALSA works fine with its own hardware drivers, without OSS involved at all. Which it usually does too. You are complaining that somebody gave you an option to use a soundcard with OSS-only mixer with ALSA applications. Where is the logic in that? It is like complaining that PulseAudio should be removed and buried because you don't use it, even though many find it convenient enough, even at the cost of increased system complexity and slightest resource usage increase.
Humans want money for everything. Pigeons don't. They are cheap in getting and owning :p They're also cute and assuming they don't become disease carriers, are good pets.
You are saying it as if if you had to snap a random group of IP packets you actually knew what to do with them? Infrastructure always has to be in place.
What about latency? Surely it is orders of magnitude larger with pigeons than with even worst possible fiber connections? We are talking minutes versus tens to hundreds of a second. Something anybody with knowledge on networks knows already. Then again, since for most IT companies bandwidth is more important than latency, I guess pigeons make more sense to them. In fact, that is what I would have used. Every time I had to send a gigabyte of media data back when I was in advertisement media business, I wish I had remembered about pigeons. So, for any case where latency is not a factor, pigeons rule. In all other cases however we need any kind of fiber.
Useful read, thanks. I should subscribe to lkml, after all these.
Well, as with any algorithm implementations, a good question would be - does BFS fail by design or by implementation? If "brain fuck" strategy just does not work, then it does not work, and Con will have to move on. If, however, it is a genuine step forward as far as user-centric schedulers go, but needs "debug, rinse, repeat" workflow on Mr. Kolivas' part due it being in "alpha" stage, then as you say, I also hope Con takes Ingo on. Certainly, if Con saw some improvements on some scenarios, the scheduler has to be worth something.
Thanks for this important correction.
Ok, I get it now. Will take time to process :-)
P.S. Compilers are getting more and more intelligent these days, and intelligence comes at the price of CPU cycles, so it would be more observant to say that indeed even with modern hardware, compilers developing in parallel, they still are keeping up to remain CPU-bound? But you are of course right about C compilers (which is what kernel stuff is built with), these develop much slower (lack of necessity, really) and thus the hardware has outran their needs by now, making them I/O bound indeed.
Well who knows, maybe instead of the elusive year of Linux on desktop, we should be expecting and applauding years of downstream personal automated-installing GNU/Linux distributions like LFS or diy-linux, which will let users to choose schedulers and what not. Not exactly something I expect to happen soon, but my feeling is GNU/Linux is being institutionalized. It is like if the trust is just not there to anything but the mainline. People assume that the majority is right here - that the maintainers of mainline kernel know best - and every other hacker in minority like Con, is just experimenting. What if we can distribute this trust better - use "non-standard" schedulers etc - then the benchmarking will reach the users and the truth will be distilled eventually. If Cons new scheduler is as good as he tries to paint it, build kernel and use it in thousands. Currently, all eyes are on mainline, which is what prevents choice, even though the choice is "potentially" there.
I am not sure what you are trying to paint here. If you have four cores, and do a compilation through 4 jobs, the compilation will race to complete and optimally should load all cores (especially since you explicitly told it to do it 4-way). Also, compilation is not all that I/O bound, it is more CPU bound. Anyways, I think I missed the meaning of your post entirely. Explain please... :-)
It is certainly a good thing - instant response (as far as the user is concerned, since "instant" is relative here). I have never used BeOS, and have to wonder - how was its "race-to-complete" task performance? If everything in the system was so catered to response timings but (concurrent) task performance suffered (in a pre-emptive multitasking OS, every task shares time with others, at least the CPU scheduler), then the user is not happy either. He/she wants instant response AND switft audio/video encoding/decoding (applications that are CPU bound).
I agree. Linux is too large (in the classic meaning of the english word) to run on a single scheduler. But then again, what is a _single_ scheduler? If it means a facility that can plug and unplug schedulers at runtime, let us say switch between CFS (or something even more server oriented) and BFS as it detects server-desktop border patterns, then I guess both Mr. Torvalds and Mr. Kolivas are happy. And users are happy too. The rigid unexplained reason that "we only need ONE scheduler, period." however puts an effective stop to the strategy. If the scheduler cannot be plugged in, i. e. statically linked, mainline kernel will stay with CFS, which it will, because the maintainers will not merge pluggable scheduler facility. Well, we will have to wait and see how this turns out. As a GNU/Linux desktop user, I care.
I think he means "forward looking" in the sense that scheduler does not collect samples from anything that already happened, it only makes decisions on what happens immediately after.
Great news :-) Now, will the kernel people with Mr. Torvalds at their head, restart the whole debate on pluggable schedulers. Since his scheduler, as he says, degrades beyond 16 CPUs, better options already exists for servers where I am guessing CFS is used. So, he may be back, but the road ahead is still as steep?
It is not the same plugin. Go visit Adobe.com and see for yourself. They have separate Windows and Linux versions. They are called versions for a reason. Part of code is shared, yes, but a good share of it is parts that interface the system, which are obviously not shared - because the systems are different.
I see. Does increasing frequency to 1Ghz increase bandwidth and/or latency? Has to be good for something, if they tweaked the standard like this.
Well, if applications crash when memory is exhausted on XO, that is a valid reason to hardcap the limit, I guess. Otherwise, it is worth remembering that resources are users property, not vendor. Vendor is trusted to manage these resources (that they do not own themselves) to their best degree of ability. They should not cross the line (something done far too often today. No make that "nearly always".) to assume ownership of these resources, by limiting users access to them. But like I said, if XO crashes, and the hardware simply is unable to isolate memory exceptions from the entire experience, there is no other choice. I doubt there is no workaround though. Even hardware without memory manager can be "programmed around" so as to not cause system-wide havoc when some component somewhere goes belly up.
The article that Slashot links to has an image on the top right corner of the page. It looks like something rendered in-game. Look at it, come back and tell me how it went.
The machines were diskless - booting from a central server over 1GHz ethernet
You mean 1 Gbps Ethernet, right?