At this point, the only thing that really keeps me using Linux are the same things that disgruntled Linux users complain about when it comes to shifting from Windows: Linux is what work supplied, and there are certain apps that I need to use that are either (a) proprietary and not ported to OS X yet, or (b) obscure (but useful) compilers which only emit x86 object code.
As a desktop OS, Mac OS X is just a much more enjoyable user experience than Linux. I'd even go so far as to say there are good odds that my next server will be running Darwin instead of Linux...
And as a follow up to myself, here's some info from the Apple X11 FAQ:
Q: How do I copy and paste using X11 for Mac OS X?
A: X11 for Mac OS X allows cut and paste between X11 and native applications using PRIMARY and PASTEBOARD selections.
You can cut text from X11 applications by selecting the text, performing a cmd-c or copy operation. You can paste in native Mac OS X applications as usual using Cmd-V.
Because there is no standard for pasting in X11 applications (some use middle mouse button, some use control-v, etc.), cmd-v doesn't work for pasting in X11 applications by design. As a result, the "Paste" menu item will be grayed out when X11 applications are in focus. You should use the control-v or the middle mouse button instead for pasting (See X11 Preferences for emulating a middle mouse button).
The "Paste" menu option will be active when non-X windows are active within X11.app (e.g., when entering text in the "Customize Applications" menu item).
A common request has been to make cmd-v work across all X11 applications. This isn't possible without re-writing all X11 applications to standardize on a single approach, which is outside the domain of X11 for Mac OS X.
Please, try option-click on X11 applications. The 'enable key equivalence' in the X11 Preferences allows cmd-c to work, but in some cases it has conflict with other keyboard shortcuts, namely on emacs.
The copy/paste bindings work in the Apple terminal, however that is nominally a Quartz app (although it interfaces with X). I don't recall whether or not they work in the actual xterm app, because I typically use the Apple terminal. I can't speak directly on Emacs, because I've long since given up on it in favor of jEdit (on all of the platforms I use). However, after some brief googling, I found this, which seems to imply that while it is possible to copy/paste between Aqua and Emacs you end up using the keybindings specific to the software that you are dealing with. Hardly surprising I suppose, since they come from fundamentally different interface paradigms. I gather that it is possible to remap the Emacs keybindings to conform to the Apple standards (I've seen at least one.emacs file out there to do just that), in which case you would presumably be able to work seamlessly with Emacs. But why bother when there's jEdit;)
If you'd bothered to understand TFA, instead of just reading it, you would have realized that the point they are trying to make is that the complexity of some systems is reaching a point where unit-testing alone is insufficient, and integration testing cannot achieve the necessary coverage (TFA most definitely does not advocate abandoning unit-testing). "Exhautive" testing really never was exhaustive. And now it's reached a point where even what passes for "exhaustive" testing is insufficient to guarantee functionality and correctness because the state space to be covered by testing is simply too large.
So what do we do if we can't fully test? As I've said elsewhere in this thread: we look to things like design-by-contract (i.e. minimize unexpected interactions), model-checking of abstract system models, carefully designing the test-cases we do perform to achieve good statistical coverage, and actually engineering a system instead of just perpetrating random acts of hackery until it "works".
The problem is that when you have a large and complex system that integrates a lot of different units (particularly where you have loads of concurrency) each unit may be working fine, but the unexpected interactions between these units can come back to bite you. With a really large system the combinatorial explosion of system states is such that full testing simply can't be done. You can have all of the requirements and documentation you want, but you simply will not be able to cover the full state-space of the system. Which is kind of the point the article was trying to make.
Will good requirements and design processes help? Yes. Assuming that by good you mean requirements and design processes that carefully specify interactions between the different parts of the system, and a design process that includes things like model-checking to ensure that the specified interactions actually produce the desired result. Which is exactly what TFA was advocating.
As to your point about NASA vs MS, you might be interested to know that NASA has begun adopting the same approach that TFA describes - in particular, model-checking of complex flight software is becoming more prevalent, for all of the reasons discussed in the article.
Sigh. I can't believe this got rated "insightful".
Testing functions as you write them is fine (and the article advocates unit-testing). The problem comes when you have a large and complex system that integrates a lot of individual functions, particularly where you have loads of concurrency. each individual function be be working fine, but the unexpected interactions between these functions can come back to bite you, and the combinatorial explosion of system states is such that full testing can be well-nigh impossible. Which is kind of the point the article was trying to make.
So what do we do if we can't fully test? We look to things like design-by-contract (i.e. minimize unexpected interactions), model-checking of abstract system models, carefully designing the test-cases we do perform to achieve good statistical coverage, and actually engineering a system instead of just perpetrating random acts of hackery until it "works".
The idea of a free market is not necessarily predicated on the assumption of perfect information. A free market means exactly that: a market in which one is able to freely enter into transactions with others. There isn't a requirement for perfect information. In fact, I've seen several arguments in favor of a free market that make the claim that we need a free market precisely because it's impossible to have perfect information: no one central entity could possibly know enough to adequately control the market, while a free market allows for distributed control, and information flow through price fluctuations.
Interestingly enough, many libertarians base their philosophy on the idea that the few laws we have should make it illegal for "any individual to initiate force or fraud against another individual" - I've seen that catchphrase all over the internet. Presumably truth in advertising laws would fall into the "non-initiation of fraud" category.
There are very few free-marketeers that advocate having no rules at all in the market. And in fact rules of some kind of essentially unavoidable - any transaction of any kind requires some kind of protocol - it's just a question of whether those rules are implicitly understood or explicitly stated. Personally, I prefer the explicitly stated version, since it allows everyone to see what the rules are, agree to them, and ensure that they are applied equally to all. It's just a question of finding the minimal set of rules that allow the market to function in the way that we desire it to function. Of course, that would require that we actually know how we want the market to function (i.e. what end-results we want), and can get everyone to agree on it...;)
Which is fine if you want to spend your life programming financial systems. But it's not going to help to help you so much if you are programming embedded software for the automotive market, or developing large telecommunications apps. If you enjoy business, then by all means take a degree in it. But don't do an advanced degree to enhance your "marketability". Do it because it is something you are genuinely interested in learning more about, in a field that you actually enjoy working in. Your life will be much more pleasant both during and after the degree.
As far as your specific examples go, they all sound like things should be determined during the requirements gathering process by talking to the actual users. Why assume that you know why they want what they want, how they want it calculated, and how it should be presented? Ask them! They are the experts. Not that I'm saying a little domain knowledge isn't helpful in talking to a customer. It helps to have a common language. But I debate the need to take an entire degree in a discipline in order to achieve a little fluency in the language.
BS. It's never been a question of money per se. NASA has, as you rightly pointed out, had all sorts of ideas for shuttle replacements. But usually one of two things happens:
the idea they are hot for involves all sorts of untried technology that requires loads of R&D. The program goes a long for a while, hits a snag, and then gets cancelled.
the political winds change, and suddenly some new concept is the one and only true future of manned spaceflight
The X-33/Venturestar program is a poster-child for the first outcome. NASA sunk 8 years and $200M+ into that program, and never even managed to get a flying half-scale demonstrator. Why? Because at the outset of the program they selected a vaporware Lockheed Martin concept that involved all sorts of sporty technology, rather than go with a more conervative design that might have actually stood a chance of working (like, for example, the Delta-Clipper program, which had already managed to produce a flying half-scale demonstrator in 2 years, on a 1/4 of the X-33's budget).
The Orbital Space Plane is a good example of the second outcome. Everyone was excited about it for a while, and then all of a sudden capsules are the rage and OSP gets replaced with the CEV. Not that I'm saying capsules are bad (I actually prefer them), just that there's a lot of flip-flopping as far as preferred approaches to spaceflight.
It'll be interesting to see which way the CEV ends up going. Based on what I've seen of the requirements documents so far, I'm going to guess the second outcome, since NASA is already over-constraining the solution space (e.g. "thou shalt land using a parachute"). Once everyone gets a new favorite way to do space then the over-specified CEV program will be dropped, and a new program with different requirements will be instituted.
Well, Darwin is out there and free. As are many of the other things that Apple has tacked onto Darwin. Quartz isn't out there, but perhaps you could take GNUstep and slap it on top of Darwin (ideally with an updated set of graphics). It won't be OSX, but it might be a starting point.
The problem with the shuttle isn't so much mass, as the fact that it is an operability nightmare, and costs a fortune in terms of ground support personnel and refurbishment. It makes the cost of using the shuttle to do pretty much anything prohibitive. Not that that has prevented NASA from using it anyway...
I agree that using the ISS as some kind of servicing and experimental hub makes a lot more sense - you can keep the same servicing hardware on orbit, instead of going to the trouble and expense of launching it over and over again. Isn't that the whole point of a space station after all? To provide a permanent presence in space, and a base of operations for doing things that don't rate a launch all to themselves.
Of course, the ISS is, as you say, in kind of a funky orbit. And its design is a bit dodgy at best - the Russians have a much better handle on things like designing to mitigate charge build-up than the US does. Might be nice to establish a new, better station instead.
The amount of uninformed, random, misinformation in this thread is astounding.
You must be new here;)
It's not just this thread. In my experience pretty much every Slashdot thread involving an area in which I have any knowledge is filled with the kind of misinformed crap that you are complaining about. The difference in this case is that you actually have enough knowledge to sort the wheat from the chaff, while in many other threads you may not. Caveat Emptor when it comes to any information derived from a Slashdot thread...
Yes, well, shame the launch market doesn't work that way. You can't purchase a launch in terms of dollars per pound. You purchase a launch vehicle, which typically has a fixed cost. Not that I'm saying a shuttle launch is cheap. But your launch cost calculations aren't really worthwhile. You need to look at the cost of a launch for a vehicle capable of lifting the mass of the HST to a 500+ km orbit. It'll most likely still end up being cheaper than the shuttle (although your cost estimate there is a little on the high side - I've heard figures more around the $500M mark), but it pays to be sure.
The incremental cost is not that much lower, because so much of the cost of a complete spacecraft is wrapped up in integration and test, launch, and operations. Adding a second spacecraft will double these things (although you arguably might manage to avoid creating a complete doubling on ops costs depending on how things were set up). Design engineering is expensive, but not the majority of mission cost.
It's hard enough to get funding for 1 spacecraft, let alone two. MER managed it by claiming that the mission would be cheaper than normal through the reuse of Pathfinder technology. The reality was that MER was different enough from Pathfinder that there had to be major design changes, many of which rippled through the system producing further changes. The final MER budget ended up being about twice the original budget as a result of cost growth.
Well, I wasn't actually trying to match the distance . Just to give an idea of the difference between radius+angle and distance+distance as location specifications. Guess I should have been more careful with my wording.
Quartz is part of OS X. OS X is composed of two major pieces: Quartz and Darwin. These pieces are separate. Darwin is derived from BSD Unix. Quartz is not. Darwin does not require Quartz. Darwin is open source (even though it did not have to be). If BSD Unix had been under the GPL, OS X would not have been in violation. The situation is identical to the proprietary package management software that some Linux distributors used add to their Linux distributions. The GPL does not prohibit that.
Sigh. I see IHBT. There are two discrete products. Darwin is a complete OS, which you can run by itself if you choose to. Quartz and Cocoa form a separate GUI layer that sits on top of Darwin. The combination is called OS X. Quartz was not derived from BSD Unix any more than Enlightenment was derived from the Linux kernel. So, even if the original license had been GPL (which it was not) Apple would be udner no obligation to release the source to Quartz. In fact, since the license was BSD, they were under no obligation to release any source at all. But Apple chose not to take that route. Instead we get this:
Many of the projects in the Darwin repository are the same live source trees used by Apple engineers for the Mac OS X product build. This means that as we work on Mac OS X internally, those changes are visible on the Darwin source code repository.
Repeat after me: Quartz is not based on any OSS product, BSD licensed or otherwise. If Apple had chosen to build OS X on top of the Linux kernel they still would not have to open source Quartz - it is a separate product.
How is "go 1000 paces that-a-way" any more polar than rectangular?
Because it specifies a radial distance (1000 paces), and a direction (that-a-way). The cartesian equivalent would be something like "go to that point 500 paces north and 300 paces west of us".
Really? Seems like Rendezvous is a commercially valuable technology, which originates with Apple (not some GPL product) and is now open source. The Darwin Streaming Server originates from the same code base as the Quicktime server - also an Apple product. There are plenty of other Darwin-based projects that Apple has released into the wild. Plus there are the pre-existing OSS projects that Apple continues to support and release code for.
Would I like to see them open source Quartz? Sure. Do I get my panties in a twist because they haven't? No. Their code, and their choice. If you don't like the terms, don't buy it. It's the same choice you have with the GPL.
Hello? what part of the previous poster's comments did you not understand? Apple has made the source of any code that they have modified available. Darwin is a complete BSD-based OS, which is freely available. They have contributed patches to other OSS projects whose software they make use of. What they have not made available is Quartz, which was not based on OSS, was not ever OSS itself, and is completely an Apple product. Where have they, as you allege, "been able to take that code, modify it, and charge for it (without providing the source)"?
...it was error accumulation from switching back and forth between the units.
No, it wasn't. Yes, there was error accumulation. But the accumulation was due to a metric-english conversion factor that had been dropped during the port of the flight software from a previous program. The lack of decent documentation for the software meant that the folks assigned to do the port were unaware of the significance of the conversion factor. without the conversion factor thruster burns were executed incorrectly, resulting in a deviation from the designed trajectory. Every burn resulted in worse errors. The mission still could have been saved, but the mission managers elected to ignore the growing deviations, and just "hope that things get better".
Slashdot Mirror
At this point, the only thing that really keeps me using Linux are the same things that disgruntled Linux users complain about when it comes to shifting from Windows: Linux is what work supplied, and there are certain apps that I need to use that are either (a) proprietary and not ported to OS X yet, or (b) obscure (but useful) compilers which only emit x86 object code.
As a desktop OS, Mac OS X is just a much more enjoyable user experience than Linux. I'd even go so far as to say there are good odds that my next server will be running Darwin instead of Linux...
Q: How do I copy and paste using X11 for Mac OS X?
A: X11 for Mac OS X allows cut and paste between X11 and native applications using PRIMARY and PASTEBOARD selections. You can cut text from X11 applications by selecting the text, performing a cmd-c or copy operation. You can paste in native Mac OS X applications as usual using Cmd-V. Because there is no standard for pasting in X11 applications (some use middle mouse button, some use control-v, etc.), cmd-v doesn't work for pasting in X11 applications by design. As a result, the "Paste" menu item will be grayed out when X11 applications are in focus. You should use the control-v or the middle mouse button instead for pasting (See X11 Preferences for emulating a middle mouse button). The "Paste" menu option will be active when non-X windows are active within X11.app (e.g., when entering text in the "Customize Applications" menu item). A common request has been to make cmd-v work across all X11 applications. This isn't possible without re-writing all X11 applications to standardize on a single approach, which is outside the domain of X11 for Mac OS X. Please, try option-click on X11 applications. The 'enable key equivalence' in the X11 Preferences allows cmd-c to work, but in some cases it has conflict with other keyboard shortcuts, namely on emacs.
The copy/paste bindings work in the Apple terminal, however that is nominally a Quartz app (although it interfaces with X). I don't recall whether or not they work in the actual xterm app, because I typically use the Apple terminal. I can't speak directly on Emacs, because I've long since given up on it in favor of jEdit (on all of the platforms I use). However, after some brief googling, I found this, which seems to imply that while it is possible to copy/paste between Aqua and Emacs you end up using the keybindings specific to the software that you are dealing with. Hardly surprising I suppose, since they come from fundamentally different interface paradigms. I gather that it is possible to remap the Emacs keybindings to conform to the Apple standards (I've seen at least one .emacs file out there to do just that), in which case you would presumably be able to work seamlessly with Emacs. But why bother when there's jEdit ;)
Really? That hasn't been my experience. Can you cite specific examples?
So what do we do if we can't fully test? As I've said elsewhere in this thread: we look to things like design-by-contract (i.e. minimize unexpected interactions), model-checking of abstract system models, carefully designing the test-cases we do perform to achieve good statistical coverage, and actually engineering a system instead of just perpetrating random acts of hackery until it "works".
Will good requirements and design processes help? Yes. Assuming that by good you mean requirements and design processes that carefully specify interactions between the different parts of the system, and a design process that includes things like model-checking to ensure that the specified interactions actually produce the desired result. Which is exactly what TFA was advocating.
As to your point about NASA vs MS, you might be interested to know that NASA has begun adopting the same approach that TFA describes - in particular, model-checking of complex flight software is becoming more prevalent, for all of the reasons discussed in the article.
Testing functions as you write them is fine (and the article advocates unit-testing). The problem comes when you have a large and complex system that integrates a lot of individual functions, particularly where you have loads of concurrency. each individual function be be working fine, but the unexpected interactions between these functions can come back to bite you, and the combinatorial explosion of system states is such that full testing can be well-nigh impossible. Which is kind of the point the article was trying to make.
So what do we do if we can't fully test? We look to things like design-by-contract (i.e. minimize unexpected interactions), model-checking of abstract system models, carefully designing the test-cases we do perform to achieve good statistical coverage, and actually engineering a system instead of just perpetrating random acts of hackery until it "works".
The idea of a free market is not necessarily predicated on the assumption of perfect information. A free market means exactly that: a market in which one is able to freely enter into transactions with others. There isn't a requirement for perfect information. In fact, I've seen several arguments in favor of a free market that make the claim that we need a free market precisely because it's impossible to have perfect information: no one central entity could possibly know enough to adequately control the market, while a free market allows for distributed control, and information flow through price fluctuations.
There are very few free-marketeers that advocate having no rules at all in the market. And in fact rules of some kind of essentially unavoidable - any transaction of any kind requires some kind of protocol - it's just a question of whether those rules are implicitly understood or explicitly stated. Personally, I prefer the explicitly stated version, since it allows everyone to see what the rules are, agree to them, and ensure that they are applied equally to all. It's just a question of finding the minimal set of rules that allow the market to function in the way that we desire it to function. Of course, that would require that we actually know how we want the market to function (i.e. what end-results we want), and can get everyone to agree on it... ;)
As far as your specific examples go, they all sound like things should be determined during the requirements gathering process by talking to the actual users. Why assume that you know why they want what they want, how they want it calculated, and how it should be presented? Ask them! They are the experts. Not that I'm saying a little domain knowledge isn't helpful in talking to a customer. It helps to have a common language. But I debate the need to take an entire degree in a discipline in order to achieve a little fluency in the language.
The X-33/Venturestar program is a poster-child for the first outcome. NASA sunk 8 years and $200M+ into that program, and never even managed to get a flying half-scale demonstrator. Why? Because at the outset of the program they selected a vaporware Lockheed Martin concept that involved all sorts of sporty technology, rather than go with a more conervative design that might have actually stood a chance of working (like, for example, the Delta-Clipper program, which had already managed to produce a flying half-scale demonstrator in 2 years, on a 1/4 of the X-33's budget).
The Orbital Space Plane is a good example of the second outcome. Everyone was excited about it for a while, and then all of a sudden capsules are the rage and OSP gets replaced with the CEV. Not that I'm saying capsules are bad (I actually prefer them), just that there's a lot of flip-flopping as far as preferred approaches to spaceflight.
It'll be interesting to see which way the CEV ends up going. Based on what I've seen of the requirements documents so far, I'm going to guess the second outcome, since NASA is already over-constraining the solution space (e.g. "thou shalt land using a parachute"). Once everyone gets a new favorite way to do space then the over-specified CEV program will be dropped, and a new program with different requirements will be instituted.
Well, Darwin is out there and free. As are many of the other things that Apple has tacked onto Darwin. Quartz isn't out there, but perhaps you could take GNUstep and slap it on top of Darwin (ideally with an updated set of graphics). It won't be OSX, but it might be a starting point.
I agree that using the ISS as some kind of servicing and experimental hub makes a lot more sense - you can keep the same servicing hardware on orbit, instead of going to the trouble and expense of launching it over and over again. Isn't that the whole point of a space station after all? To provide a permanent presence in space, and a base of operations for doing things that don't rate a launch all to themselves.
Of course, the ISS is, as you say, in kind of a funky orbit. And its design is a bit dodgy at best - the Russians have a much better handle on things like designing to mitigate charge build-up than the US does. Might be nice to establish a new, better station instead.
You must be new here ;)
It's not just this thread. In my experience pretty much every Slashdot thread involving an area in which I have any knowledge is filled with the kind of misinformed crap that you are complaining about. The difference in this case is that you actually have enough knowledge to sort the wheat from the chaff, while in many other threads you may not. Caveat Emptor when it comes to any information derived from a Slashdot thread...
Actually, they're in the business of doing both.
Yes, well, shame the launch market doesn't work that way. You can't purchase a launch in terms of dollars per pound. You purchase a launch vehicle, which typically has a fixed cost. Not that I'm saying a shuttle launch is cheap. But your launch cost calculations aren't really worthwhile. You need to look at the cost of a launch for a vehicle capable of lifting the mass of the HST to a 500+ km orbit. It'll most likely still end up being cheaper than the shuttle (although your cost estimate there is a little on the high side - I've heard figures more around the $500M mark), but it pays to be sure.
Well, I wasn't actually trying to match the distance . Just to give an idea of the difference between radius+angle and distance+distance as location specifications. Guess I should have been more careful with my wording.
And yes, IHBT, HAND.
Repeat after me: Quartz is not based on any OSS product, BSD licensed or otherwise. If Apple had chosen to build OS X on top of the Linux kernel they still would not have to open source Quartz - it is a separate product.
Because it specifies a radial distance (1000 paces), and a direction (that-a-way). The cartesian equivalent would be something like "go to that point 500 paces north and 300 paces west of us".
Would I like to see them open source Quartz? Sure. Do I get my panties in a twist because they haven't? No. Their code, and their choice. If you don't like the terms, don't buy it. It's the same choice you have with the GPL.
Hello? what part of the previous poster's comments did you not understand? Apple has made the source of any code that they have modified available. Darwin is a complete BSD-based OS, which is freely available. They have contributed patches to other OSS projects whose software they make use of. What they have not made available is Quartz, which was not based on OSS, was not ever OSS itself, and is completely an Apple product. Where have they, as you allege, "been able to take that code, modify it, and charge for it (without providing the source)"?
No, it wasn't. Yes, there was error accumulation. But the accumulation was due to a metric-english conversion factor that had been dropped during the port of the flight software from a previous program. The lack of decent documentation for the software meant that the folks assigned to do the port were unaware of the significance of the conversion factor. without the conversion factor thruster burns were executed incorrectly, resulting in a deviation from the designed trajectory. Every burn resulted in worse errors. The mission still could have been saved, but the mission managers elected to ignore the growing deviations, and just "hope that things get better".