Right, but that's my point - CS is supposed to be theory. That's what the "science" part of the name means. The "vital practical skills" are what Software Engineers should be learning - that's part of what differentiates engineers from scientists. I agree that packing the head of a Software Engineering student with all sorts of esoteric theory is probably not worth the effort. Nor is it feasible given the time constraints. But other engineering disciplines seem to have found ways to fit both sufficient theory and a certain amount of practical skills into the (typically 4-year - at least in the US and New Zealand) engineering program. So it is possible.
As an aside, I think it's a shame that most self-proclaimed "software engineering" courses focus as much on project management as they do on anything actually resembling engineering. Not that project management isn't useful, but IMHO it's better taught in a course devoted to project management, rather than squeezed into a software engineering class.
O(n^2) vs O(nlogn) is simply one example. There are plenty of others. Does every software developer need to be well-versed in the intricacies of category theory as it applies to algebraic data types? Probably not. But a working knowledge of automata theory, computational complexity, logic and set theory, and modern concurrency theory would go a long way towards making a competent software developer. These things are as fundamental to software development as differential calculus, laplace and fourier transforms, and kirchoff's laws are to electrical engineering.
. Which end is society better served by: a workforce of mathematicians trying to be coders in order to earn a wage outside of HE, or of competent developers?
There are two problems here:
The idea that Computer Science prepares one for a career as a software developer. It does not. As David Parnas pointed out many years ago, software development should be the province of Software Engineers. The fundamental knowledge in both fields may be the same, but the entire focus of the education is different. Engineers are (or should be) trained to design and develop useful products which solve some problem, and are fit for that purpose. That's what engineers in other fields have been doing for centuries.
The idea that one can be a truly competent developer without understanding the underlying theory. We expect engineers in other disciplines to understand theory and math, because it is the basis of everything else they do. A competent developer should understand the implications of O(n) vs O(n^2), and know when it might be appropriate to choose the O(n^2) algorithm over the O(n) one (just as we would expect a civil engineer to understand the differences between the material properties of wood and steel).
Is training in debugging useful? Undoubtedly. But so is training in theory. This isn't an either/or thing. Software Engineers should be trained in both.
Oops. Sorry 'bout that. Meant to say >99% probability of successful execution. You're right - recovery rate makes little sense in a fault-prevention scenario.
Incidentally, aside from SIHFT. the other way to fly COTS processors in space is to apply triple-redundancy, and to operate the processors in a lock-step majority voting configuration (a good example is the Maxwell SCS750). This is also more robust to bit-flips than SIHFT (although it ends up costing more in terms of power and hardware complexity). Still not robust to ionizing dose though:(
The good news is the modern fabrication processes actually seem to be moving towards things that are robust to ionizing dose (e.g. SOI, greater gate-oxide purity) for their own reasons. So operating a COTS processor in space then just becomes a case of dealing with single-event effects.
Actually, there has been some research into using "software implemented hardware fault tolerance" (SIHFT) to guard against the effects of bits flips. There's a research group at Stanford that's done a lot of work with SIHFT, and even flew a test processor on the ARGOS satellite. In addition to error-correcting codes on memory (which is standard on most spacecraft anyway) they also use two techniques to ensure that executing software is not corrupted: Control Flow Checking by Software Signatures (CFCSS), and Error Detection through Duplicated Instructions (EDDI). CFCSS involves precomputing signatures for each major block in the control flow during compilation, and then regenerating and checking those signatures at runtime to ensure that a bit-flip hasn't caused a spurious branch. EDDI inserts shadow instructions into each block, so that each computation gets performed twice, and the results are cross-checked before the next block of instructions is executed.
As I pointed out in another comment in this thread, it's not that NASA wants old processors. They want processors that are hardended to radiation, and the reengineering required for hardening causes rad-hard processors to lag commercial processors by a generation or two. Both EDDI and CFCSS work fairly well (~97% error recovery rate IIRC), but not as well as having a rad-hardened processor (> 99% error recovery rate). In addition, SIHFT can't do much to protect you from ionization-induced degradation, which causes cumulative damage to a processor that eventually causes it to stop functioning: rad-hard processors are far less susceptible to damage caused by ionizing dose.
There already are a number of companies working the "niche market". The problem is that the market is relatively small, and the costs are high. Hopefully the advent of commercial spaceflight will bring launch costs down enough that more people will launch, and the space market will expand significantly.
Disks work just fine in space (although they do need to be ruggedized a little). See for example the General Dynamics (nee Spectrum Astro) Space-Qualified RAID. Note that these are meant for use on unmanned spacecraft.
It's not that NASA prefers processors a couple of years old. It's that NASA prefers processors which have been radiation-hardened, which makes them resistant to both single-event effects (bit flips) and to cumulative ionization-induced degradation (which gradually changes the threshold voltage of transistors due to charge build-up in gate oxides).
Unfortunately, radiation hardening a processor involves altering the fabrication process (some processes - e.g. SOI - are more resistant to bit flips than others), inserting guard rings, adding self-checking logic, and a bunch of other changes. Doing all of this stuff takes time (and money) so space-ready processors typically lag COTS processors by a generation or two. Example: the current "hot new" rad-hard processor is the RAD750, which is a rad-hard version of the venerable PowerPC 750.
Having said all of that, some small, risk-tolerant missions do use standard COTS processors (PowerPCs and StrongARMs are popular, as are industrial embedded processors like the Hitachi SuperH line). But you won't tend to find them in most NASA projects.
Not now, but at the time that these laws were enshrined into popular morality thousands of years ago, there was little medicine and no protection. Sexual promiscuity and homosexuality are both vectors for disease, which placed the entire community at risk.
Yeah, I guess that explains why the rampant homosexuality of ancient Greece caused their entire civilization to collapse in short order, huh? Oh. Wait.
You forgot to mention that their OS is called "Darwin", and it's symbol is a platypus - wait for it - dressed up as the devil! I could go on, but it's easier to just point you here. Scroll about halfway down. Laugh your ass off. Then try to figure out whether or not it's actually a joke (sadly, I don't think it is).
"I did write a tool that is interoperable with BitKeeper," Tridgell said in an interview. "I did not use BitKeeper at all in writing this tool and thus was never subject to the BitKeeper license. I developed the tool in a completely ethical and legal manner."
So Tridge seems to think that what he did was above board. McVoy apparently doesn't. Since we don't know what actually happened, it's all "he-said/she-said" right now. Why don't we wait for some facts before passing judgement on Tridge?
That makes no sense. How was Tridge getting access to BK network traffic for reverse engineering? Either he was using the tool or he had an accomplice who had accepted the license. Or are you telling me that OSDL allowed Tridge to sniff Linus' traffic?
I don't know how Tridge was doing his reverse engineering. Apparently neither do you. So perhaps we should wait to crucify the guy until we actually have some facts.
Having said that, given that McVoy had to resort to blackmail to stop Tridge I suspect it's safe to assume that legal means wouldn't have worked, which means that (1) Tridge must not have accepted a BK license, and (2) he probably wasn't working with someone who did have a BK license, since in either case McVoy could simply have revoked that specific license. So what was Tridge doing? I have no idea. Do you?
Tridgell is ultimately responsible for this whole mess, not McVoy. McVoy was under no obligation to give free licenses of BitKeeper to Linux developers, but he did, and he set conditions for those licenses which was something he was entirely in his right to do. He created BitKeeper. He could set any license he wanted. It was his right.
Allow me to repeat: AFAICT Tridge was not bound by any license. What McVoy has done is void the licenses of legitimate BK users due to the actions of someone who wasn't even a BK user. That is, as you say, McVoy's right. But it also his choice. Tridge was not doing anything illegal, nor was he (AFAICT) violating the BK license. But apparently whatever Tridge was up to annoyed McVoy enough that McVoy decided to try emotional blackmail: "I can't legally stop you from doing what you're doing, but if you keep doing it I'll be nasty to your friends and colleagues." Should Tridge have stopped? I dunno - depends on your stance on blackmail I suppose. But the fact remains that it was McVoy that chose to use the threat of BK withdrawal to stop something he disagreed with.
Linus chose the best tool available to get the job done. It happened to be a closed source tool.
Yes, but the problem, as several people have pointed out now, was that the closed nature of the tool may have mode it not "the best tool available". Was it the best in terms of functionality and performance? Apparently. But those aren't the only things you need to evaluate when buying or using a product. You also need to take into account things like cost, risk, reliability, and (particularly in the OSS world) licensing. I'm not an OSS fanatic by any means, but even I could see that Linus' adoption of BK was a bad move.
Regarding Tridge's efforts, I don't see that it makes one bit of difference whether BK was paid for or a gift. In either case "violating the conditions" of using the product would be bad. But Tridge was not a BK user. He was not violating the conditions of using the product. That's what got McVoy pissed: he couldn't stop Tridge by revoking Tridge's license, because Tridge never had one in the first place. So instead McVoy started threatening others in the vicinity.
Linus has every reason to be angry. Someone took away a very useful tool from him. I'd be pissed.
Yes. And that someone was Larry McVoy. Not Tridge.
Whereas I came from 7 years of using Debian Linux, and immediately appreciated the integration of OS X, and the fact that things "just work" without requiring several hours of googling to figure out how to get them to work. Admittedly, it helps that the fink project has made so much free software available (via an apt repository no less). Don't get me wrong, Debian is great, and I still use it a lot. But as far as a desktop OS goes, OS X wins hands down in my book. Of course, YMMV.
Not really. The scientific community has been doing "open source" for several centuries. Even Eric Raymond pointed that out in one of his various books on the subject.
Don't let it tempt you: just do it! I switched to a Powerbook about 9 months ago, and I've never been happier with an OS - I've got the full power of Unix and GNU at my fingertips via the terminal, but all wrapped in an incredibly slick and easy-to-use GUI system that "just works".
No. The standins for Han and Chewie were Lando Calrissian and some weird-looking guy with about 3 sets of lips. The name of his species escapes me, but he was most definitely not Mon Calamari.
Given that I am, by training and profession, an engineer, I'm fairly confident that I understand the engineering principles involved. The whole point of engineering is to find ways to use the laws of nature to do things we couldn't do before (not things that "aren't possible in nature" - if they're not possible, they can't be done at all). It doesn't involve "loopholes" in the laws - no magic there - it involves truly understanding what those laws are, what their full consequences are, and how they interact with each other. That is my last word on this thread.
Slashdot Mirror
As an aside, I think it's a shame that most self-proclaimed "software engineering" courses focus as much on project management as they do on anything actually resembling engineering. Not that project management isn't useful, but IMHO it's better taught in a course devoted to project management, rather than squeezed into a software engineering class.
O(n^2) vs O(nlogn) is simply one example. There are plenty of others. Does every software developer need to be well-versed in the intricacies of category theory as it applies to algebraic data types? Probably not. But a working knowledge of automata theory, computational complexity, logic and set theory, and modern concurrency theory would go a long way towards making a competent software developer. These things are as fundamental to software development as differential calculus, laplace and fourier transforms, and kirchoff's laws are to electrical engineering.
There are two problems here:
- The idea that Computer Science prepares one for a career as a software developer. It does not. As David Parnas pointed out many years ago, software development should be the province of Software Engineers. The fundamental knowledge in both fields may be the same, but the entire focus of the education is different. Engineers are (or should be) trained to design and develop useful products which solve some problem, and are fit for that purpose. That's what engineers in other fields have been doing for centuries.
- The idea that one can be a truly competent developer without understanding the underlying theory. We expect engineers in other disciplines to understand theory and math, because it is the basis of everything else they do. A competent developer should understand the implications of O(n) vs O(n^2), and know when it might be appropriate to choose the O(n^2) algorithm over the O(n) one (just as we would expect a civil engineer to understand the differences between the material properties of wood and steel).
Is training in debugging useful? Undoubtedly. But so is training in theory. This isn't an either/or thing. Software Engineers should be trained in both.Incidentally, aside from SIHFT. the other way to fly COTS processors in space is to apply triple-redundancy, and to operate the processors in a lock-step majority voting configuration (a good example is the Maxwell SCS750). This is also more robust to bit-flips than SIHFT (although it ends up costing more in terms of power and hardware complexity). Still not robust to ionizing dose though :(
The good news is the modern fabrication processes actually seem to be moving towards things that are robust to ionizing dose (e.g. SOI, greater gate-oxide purity) for their own reasons. So operating a COTS processor in space then just becomes a case of dealing with single-event effects.
As I pointed out in another comment in this thread, it's not that NASA wants old processors. They want processors that are hardended to radiation, and the reengineering required for hardening causes rad-hard processors to lag commercial processors by a generation or two. Both EDDI and CFCSS work fairly well (~97% error recovery rate IIRC), but not as well as having a rad-hardened processor (> 99% error recovery rate). In addition, SIHFT can't do much to protect you from ionization-induced degradation, which causes cumulative damage to a processor that eventually causes it to stop functioning: rad-hard processors are far less susceptible to damage caused by ionizing dose.
There already are a number of companies working the "niche market". The problem is that the market is relatively small, and the costs are high. Hopefully the advent of commercial spaceflight will bring launch costs down enough that more people will launch, and the space market will expand significantly.
Disks work just fine in space (although they do need to be ruggedized a little). See for example the General Dynamics (nee Spectrum Astro) Space-Qualified RAID. Note that these are meant for use on unmanned spacecraft.
Unfortunately, radiation hardening a processor involves altering the fabrication process (some processes - e.g. SOI - are more resistant to bit flips than others), inserting guard rings, adding self-checking logic, and a bunch of other changes. Doing all of this stuff takes time (and money) so space-ready processors typically lag COTS processors by a generation or two. Example: the current "hot new" rad-hard processor is the RAD750, which is a rad-hard version of the venerable PowerPC 750.
Having said all of that, some small, risk-tolerant missions do use standard COTS processors (PowerPCs and StrongARMs are popular, as are industrial embedded processors like the Hitachi SuperH line). But you won't tend to find them in most NASA projects.
Bel as in dB == decibel.
Yeah, I guess that explains why the rampant homosexuality of ancient Greece caused their entire civilization to collapse in short order, huh? Oh. Wait.
You forgot to mention that their OS is called "Darwin", and it's symbol is a platypus - wait for it - dressed up as the devil! I could go on, but it's easier to just point you here. Scroll about halfway down. Laugh your ass off. Then try to figure out whether or not it's actually a joke (sadly, I don't think it is).
And out of ???? came this mythical creator?
In OS X the root account isn't even active (by default). Everything is done through sudo.
Well, according to Tridge himself:
So Tridge seems to think that what he did was above board. McVoy apparently doesn't. Since we don't know what actually happened, it's all "he-said/she-said" right now. Why don't we wait for some facts before passing judgement on Tridge?I don't know how Tridge was doing his reverse engineering. Apparently neither do you. So perhaps we should wait to crucify the guy until we actually have some facts.
Having said that, given that McVoy had to resort to blackmail to stop Tridge I suspect it's safe to assume that legal means wouldn't have worked, which means that (1) Tridge must not have accepted a BK license, and (2) he probably wasn't working with someone who did have a BK license, since in either case McVoy could simply have revoked that specific license. So what was Tridge doing? I have no idea. Do you?
Allow me to repeat: AFAICT Tridge was not bound by any license. What McVoy has done is void the licenses of legitimate BK users due to the actions of someone who wasn't even a BK user. That is, as you say, McVoy's right. But it also his choice. Tridge was not doing anything illegal, nor was he (AFAICT) violating the BK license. But apparently whatever Tridge was up to annoyed McVoy enough that McVoy decided to try emotional blackmail: "I can't legally stop you from doing what you're doing, but if you keep doing it I'll be nasty to your friends and colleagues." Should Tridge have stopped? I dunno - depends on your stance on blackmail I suppose. But the fact remains that it was McVoy that chose to use the threat of BK withdrawal to stop something he disagreed with.
Yes, but the problem, as several people have pointed out now, was that the closed nature of the tool may have mode it not "the best tool available". Was it the best in terms of functionality and performance? Apparently. But those aren't the only things you need to evaluate when buying or using a product. You also need to take into account things like cost, risk, reliability, and (particularly in the OSS world) licensing. I'm not an OSS fanatic by any means, but even I could see that Linus' adoption of BK was a bad move.
Regarding Tridge's efforts, I don't see that it makes one bit of difference whether BK was paid for or a gift. In either case "violating the conditions" of using the product would be bad. But Tridge was not a BK user. He was not violating the conditions of using the product. That's what got McVoy pissed: he couldn't stop Tridge by revoking Tridge's license, because Tridge never had one in the first place. So instead McVoy started threatening others in the vicinity.
Linus has every reason to be angry. Someone took away a very useful tool from him. I'd be pissed.
Yes. And that someone was Larry McVoy. Not Tridge.
Actually, prices like that (works out to about $390/person) are not uncommon for conference registration. Sad, but true.
Whereas I came from 7 years of using Debian Linux, and immediately appreciated the integration of OS X, and the fact that things "just work" without requiring several hours of googling to figure out how to get them to work. Admittedly, it helps that the fink project has made so much free software available (via an apt repository no less). Don't get me wrong, Debian is great, and I still use it a lot. But as far as a desktop OS goes, OS X wins hands down in my book. Of course, YMMV.
Not really. The scientific community has been doing "open source" for several centuries. Even Eric Raymond pointed that out in one of his various books on the subject.
Don't let it tempt you: just do it! I switched to a Powerbook about 9 months ago, and I've never been happier with an OS - I've got the full power of Unix and GNU at my fingertips via the terminal, but all wrapped in an incredibly slick and easy-to-use GUI system that "just works".
I had to specifically resist the temptation to go look up his name and species before I posted...
No. The standins for Han and Chewie were Lando Calrissian and some weird-looking guy with about 3 sets of lips. The name of his species escapes me, but he was most definitely not Mon Calamari.
Given that I am, by training and profession, an engineer, I'm fairly confident that I understand the engineering principles involved. The whole point of engineering is to find ways to use the laws of nature to do things we couldn't do before (not things that "aren't possible in nature" - if they're not possible, they can't be done at all). It doesn't involve "loopholes" in the laws - no magic there - it involves truly understanding what those laws are, what their full consequences are, and how they interact with each other. That is my last word on this thread.