The "cost of finding a bug" is incredibly variable, and the cost of developing the full benchtest setup of every possibility is often much higher than that of releasing a beta and letting people hammer at it to find some of the interesting corner cases you'd spend millions to workk through in iterative tests in the lab. Finding it in advance is good, but human review and test benches also add up.
Yes, exhaustive test benches are prohibitively expensive, which is why you use formal methods. I think perhaps you are not understanding what I mean by that. I'm refering to things like B-method, algebraic systems specification etc. which allow you to do rigourous mathematical analysis on your code. Using these sorts of methods you can construct formal proofs of the correctness of your code prior to having to do any testing. No, proofs like that don't make softare completely infallible, you'll probably still want to do some testing - but the point is that formal methods drastically reduce the amount of testing required. Ideally they also give you measures of the test space and help you to conduct targetted testing in a way that gives you the best possible coverage for the least amount of work.
You just have no idea of the cost of an absolute guarantee that it doesn't screw up. It doesn't cost 20% more or even 100% more, an "absolute guarantee" (formal methods) costs 10x to 20x more than "99.9% certain". Our employers almost never feel that the additional cost is worth the reduction in risk from 0.1% to 0% unless lives are on the line, and even then, they'll do just about anything to avoid the real costs.
I can't imagine a testign regimine that guarantees you 99.9% certainty of correct performance that manages to cost less than a formal method to prove your code, and associated targetted testing, that would give you the same 99.9% certainty. Exactly how many years of testing do you do? And where do you get that "...(formal methods) costs 10x to 20x more" from? I've never seen anything that gives figures like that. Another poster claims that formal methods costs the same or less, an coveniently provides sources for his quotes.
I rather suspect you are just pulling figures out of your ass to justify the way you do things.
How do you think those formal methods have been developed in the first place?! If not via "build and test"? How many bridges have fallen down before designers new enough to formalize their methods?
I'm talking about formal mathematical analysis, not a strict "you do this, then this, then this". Once Newtonian physics, calculus etc. was hammered out, mathematical analysis and proving of designs didn't require all that much testing at all - merely a bit of testign to get a good idea of how much error tolerance to factor in to cover the vagaries of the real world.
The computer world is pure binary data. It has no such vagaries. It is all just mathematics. So yes, someone has to sit down and figure out how to do the math to prove a program. Interestingly people already have. There's no testing involved in this, it's a matter of rigourous mathematics.
Naturally such a thing doesn't eliminate the need for testing, but it does drastically reduce th amount of testing required (as well as letting you design, for instance, a statistically significant sampling of of the test space), and it gives you a whole new level of checks and assurances on the quality of the code that testing simply can't compare to.
It is on Linux. Whether the Mac version did somethign special I don't know - I doubt it, as I don't think GTK supports a global top of the screen Mac style menu. Besides, Photoshop for Mac is a multiwindowed system anyway, the Mac just has the global menu, and decent support for palette windows in the window manager.
If you want a solution to GIMPs multiwindow issues, try reading my sig and lobbying the major Linux window managers to get at least some support for window groups in a sensible way.
If you're on Windows... sorry, you're out of luck on that one. I do believe there was a hack for Window GIMP that added a background window (like Photoshop on Windows), but I have no idea where to find it.
Adobe's interfaces tend to be pretty bad, actually, but they are an improvement on the GIMP's in some respects. I wonder if GimpShop really manages to incorporate the subtle things that give Photoshop an advantage, though...
Adjustment layers? CMYK support? I'm not sure what you're looking for. Having run it, I can tell you: it is the same old GIMP we know and love (or hate as the case may be), just with all the menus reorganized to be structured the same way Photoshop organizes them. Oh, and some of the tools have been renamed. Other than that, it's pretty much exactly the same. If you want to find "brightness-contrast" under "Image/Adjustments" Instead of "Layer/Color" then by all means you'll find this useful. If you want a complete Photoshop workalike... buy Photoshop.
Having downloaded and run the Linux version, I can assure you this is no joke. It's also not that big of a deal: mostly all that has been done is a rearrangement of the menus, and renaming of some of the tools. Other than that, it's still the GIMP with its usual multiwindow interface. If you're a die hard photoshop fan (why are you using GIMP) then it would help with your transition. ut really, I found the menu layout to be no more logical than the original GIMP layout - each structure has it's own logic which can be argued for.
I appreciate what the guy has done, and it is probably a fair amount of work. Unless you need your menus structured the same way Photoshop structures them though, this probably isn't going to make much difference to you.
Which is really a long excuse for failing to go through the design stage where you work with the end users to develop a formal requirements specification.
If you are designing a new GUI frontend for database access, sure, you probably want to have flexiility in requirements. If you are writing a mission critical application of any kind (pretty much anything where stability, integrity, or security are important) you really ought to be get a formal specification of requirements worked out with the user before you start. Make it contractual. If you can't fully spec the whole project, formally spec the critical parts (say the backend) and don't bother with the formal development of the GUI frontend for the users - the principle being that the part that has to work will work, and if the GUI fails - well, your design should isolate that so that it can't cause any data corruption or loss at the backend which is formally specified, and guaranteed not screw up.
I'm interested, do all you developers do nothing but write software where the costs of failure, data corruption, data loss, or security breaches are negligible? I thought all these slashdot people were busy writing mission critical enterprise applications (well, not really).
The cost of a bug in software found after deployment is vastly higher than the cost of a bug found prior to deployment. That coul take the form of a bug causing severe data loss or downtime in a critical production environment, or it could take the form of a security vulnerability is a deplyed product.
If your software is intended to fulfill a critical role, be dependable, or be secure, then "rebuilding" after the fact comes at an extremely high price. Not every desktop application needs to be built to serious engineering principles, but if the application is "mission critical" then perhaps you ought to consider what you can do besides a bit of testing to be sure it is going to be stable and work as intended.
Sure, if management persists with short deadlines you'll never be able to produce quality. Pretending that proper engineering of systems isn't necessary is only going to help lower managements expectations of how hard it is to develop software.
The simplest reason is that for all but a tiny, TINY fraction of software projects, the worst thing that a catastrophic failure can cause is data loss.
Sure, but let's be honest, catastrophic failure and data loss can be very very bad. It can cost a company many many millions of dollars. It can cost a country a fair democratic election (presuming they, for some reason, use electronic voting with no paper trail - but why would any country be silly enough to do that?). I'm not proposing formal methods to design a minor desktop application, I'm proposing formal methods for anything deemed mission critical, or anything where security is important. There are plenty of projects that fall into those sorts of categories for which no real level of formal design is used.
And that bridges typically serve a single, simple purpose, whereas software depends on the complex interaction of thousands of elements that are not well-understood.
Yup. I never said software engineering was as easy as bridge engineering, merely that it is possible to do the same level of design and engineering. Formal specification, verification and validation of software is hard. It is still an active research field. That does not mean, however, that practical systems for doing it are not available. It can be done. As I said, in the worst case you can restrict yourself to formal methods for just those small components of the total system that are the most critical - validate those.
I think the real problem is that too many developers are unaware of what is available in the way of formal methods. If you don't know what can be done, of course you're not even going to consider it for your project. It may, or may not be appropriate, but if you don't even know what can be done, how can you judge appropriateness?
Which comes straight back to the point that it is a matter of changing the expectations of the public with regard to how software design and construction works. How do you expect to educate the public when the developers themselves are accepting of half assed hack it together methods even for critical systems? Where the hell was Diebold's formal specification and validation of their code? Do you really believe they shouldn't have bothered with such a thing?
However (and it's a big however), it still doesn't mean that your solution is correct! Did you get the requirements right? Is your system what the users expected? Is the interface layout easy to use? Is it fast enough to be useful? Does it add value to the customers toolset?
You can ask the same questions about bridge design. Did you get the requirements for the bridge right (maybe it actually needs to be able to bear more weight than your requirements said)? Is your bridge what the users expected (Is it in the right place, satisfying the right requirements?)? Is the bridge interface right (Are there enough lanes, support for rail as well, etc.)? Is it light/flexible/cheap enough to be useful? Does it add value to the the local residents lives? These are all questions that formal bridge design methods don't address. That doesn't mean we don't design bridges formally, it means we spend a lot more time getting the requirements properly formalised and documented and checked for correctness. Yes, customers don't expect to have to do that with software, but if integrity, stability, or security are at all important we should be teachign them that such things are part of the process.
Honestly, can you tell me you wouldn't be far happier if the software for electronic voting machines didn't have a formal requirement specification that you can check and code that has been verified and proven against that specification? I know I would. How about that mission critical database or webserver? How about your email encryption software - there are formally specified protocols from which to build requirements? The little database access frontend that you whipped up for accounting is not going to require formal design, but not all projects have such a high tolerance for faults, security breaches, or stability issues
I said, quite specifically, that formal methods are harder and take longer. Can I deliver to an arbitrary deadline? Of course not. Why am I being asked to deliver to such an arbitrary deadline though? Because the customers don't appreciate that getting correct code is a matter of formal design which is going to be time consuming. Because the customers don't realise that simply throwing something together and running a few random tests is not really sufficient to build a system where stability, integrity, or security are factors. Sure that's a problem.
My point is that if the people writing the software think throwing it together and running the odd test is good enough, then how the hell are the customers and general public going to learn any better?!
I think that's exactly the problem with software expectations. They always assume that building software is like building a house, or a bridge, or a toaster. In other words, they always assume that building software is done by experienced people who've built nearly identical software systems before.
When an engineer designs and builds a new bridge it is entirely possible that no bridge like it has ever been designed or built before. Sure, there are some base cases that just get churned out, but there are also big, new, creative designs that occur for bridges. How is that bridge engineers usually manage to not have their bridges falling down all the time? Well, for starters the designer doesn't run with a "build and test" mentality. There are formal methods for bridge design, and if you assume the properties of various basic components, there are methods to prove the stability and properties of the bridge. Did you know that there are formal methods for software design, and if you assume the properties of basic components (like hardware, OS , etc.) there are methods to prove the stability and properties of the software?
Yes, formal software methods are hard and time consuming compared to just building and testing. Formal bridge design is hard and time consuming compared to just building and testing.
For some reason we accept that software should be just thrown together rather than properly designed and proved. Yes, there are plenty of projects for which the level of formality I'm talking about simply isn't required - that's fine. My point is that there are plenty of projects for which the level of formality I'm talking about would be a damn good idea - yet it is never even contemplated let alone used. At worst you should be considering some level of formality for just those components of your system that are most critical.
No Linux gives you all that, with almost zero effort.
I never claimed any current Linux ditribution did - that was kind of my point. Be able to guarantee a userbase buying your product and you can invest in little GUI tools to automate setting up firewalls etc (though Redhat and SuSE already provide many of these things), not to mention the fact that all the hardware vendors will make sure they work with "distribution X" as they have significant market share, so anything yu plug in will "just work". The market also ensures commercial software developers provide plenty of high quality, perfectly integrated "just works" software.
No Linux distributor can do this, ecause they can't guarantee the market. It can't and won't happen. It was a thought experiment, not a statement of present reality. Pay attention.
There's no advantage to using the x86 architecture aside from a perceived price gain.
Actually there is the issue of availability. Apple has had issues with the supply of PowerPC chips, particularly G5s. On the x86 side of the fence there are no such availability issues as Intel and AMD already have large markets adn produce extremely large volumes. That said...
I'd rather see Windows, Linux, BSD, etc move to the PowerPC architecture.
If this actually happened then the situation would likely reverse as the volume of PowerPC chips in demand would be huge, and some serious productuon facilities would get built to deal with it.
In the meantime Apple will have minor supply issues. Given the costs of switching/porting to x86 I don't see how the gains (in availability) could possibly be worth it.
On another note: Where exactly are the Linux PPC systems? PPC Linux works quite well from what I've heard - why aren't there any people selling Linux PPC desktops or laptops?
Jedidiah.
Re: What amazes me most
on
Return of the Mac
·
· Score: 2, Interesting
I agree entirely. Had MacOS X been poor it would have failed. I'm simply trying to point out that it didn't have to be magic either. These days unless you are very niche, an OS needs good support from application developers to get anywhere, and Microsoft has a stranglehold on most developers. If you don't get the app developers, you don't get any applications, and no one wants to use the platform... and so it dies.
Mac and Linux are two wannabe mainstream OSs that have managed to survive. MacOS X did this by being able to promise app developers a guaranteed market, and so they got a lot of serious commercial app developers on board.
Linux managed by being open and letting developers do whateer they want with it - thus appealing to a wide range of developers who want to tinker. It also managed to become to poster boy for open source, which again, attracts all the developers. The upside for Linux is that it never had to be able to promise market share - the people who wrote apps for it just wanted a platform they could do whatever they wanted with. The downside is that Linux app developers are a broad bunch who will write whatever they want. That means that while Linux has managed to aquire a fairly strong set of applications, there are a lot fewer guarantees that they all play together nicely, or really have much of anything in common at all.
The truly interesting point, as far as I'm concerned, is that there really isn't much more room in the OS market. Either you have to be an open source poster boy and attract the developers that way, or you have to be able to guarantee some market share. In the mainstream desktop market, I don't see any new commercial OS doing that.
Use what the distro provides, or use Firestarter or similar. A little frontend to firewall configuration is hardly difficult. Redhat has a nice one for example. Yes, it's simple, but if you want hardcore firewall configuration your tool is going to get complicated and you may as well use Firestarter. Given that both SuSE and Redhat (the main commercial vendors) provide simple GUI tools that integrate into the desktop to set up firewalls, I think we can easily presume Distribution X does the same.
How do you integrate your digital camera with your screensaver?
I'm not sure, I haven't tried, but why is that important? I'm sure there are things you can do simply in GNOME/Linux that are more tricky in Mac OS X (How do you sort email into virtual folders like in Evolution? How do you manage multiple WiFi connections with a click or two?).
If someone sat down with GNOME adn Linux, standardised everything, and could promise developers a large(ish) userbase that would all hew precisely to those standards - I think that distribution would quickly become as "easy" and "just works" as Mac OS X. Will that happen? No. You need to be able to promise a captive userbase, and no Linux distribution can do that.
Jedidiah.
Re:What amazes me most
on
Return of the Mac
·
· Score: 5, Insightful
What amazes me most is how short of a time it took for OS X to get put together.
What really made MacOS X work is that Apple already had a very secure decently sized niche market for Macs. That is, there was a guaranteed devoted userbase that:
(1) Hardware manufacturers bother to write and include drivers. (2) Software companies bother to release OS X versions of their applications.
That means that "things just work" - hardware works, and there is enough software, all built for the specific platform, that it all plays together nicely.
Imagine, for a minute, that there was a Linux distributor (Call them X) that standardised on a fixed platform (say GNOME for example), and had enough guaranteed userbase that Adobe wrote a version of the Creative Suite (Photoshop, Illustrator, etc.) for GNOME, Microsoft released MS Office for GNOME, and lots of other serious software companies also wrote GNOME versions of their commercial applications. All of a sudden distribution X would be a viable platform that had all the software you need, and it all works seamlessly together inside GNOME. Presuming you also have hardware coming with distribution X drivers, dsitribution X would be quite reasonable competition for OS X - it would certainly have the "it just works" factor.
You can redo the whole gedanken experiment with KDE if you like, you'll get similar results.
What made OS X really work was the guaranteed userbase and the fact that it could run old mac software to ensure a smooth transition of that userbase and an immediate supply of software. Honestly, if a small startup company wrote a brand new OS that was as good as OS X but lacked the userbase, and hecne software and hardware support, it would just potter along and probably eventually die or get bought out (see BeOS, NeXTStep etc.)
Nope, next update is to Emacs so the whole Emacs/VI holy war can erupt and somebody can poke there head up and say pico or joe.
Don't laugh, the new (CVS) version of GNU Emacs uses GTK+ and integrates into GNOME or XFCE quite nicely (except for keybindings, of course, which can be changed to suit). I'm quite keen for the next version to actually arrive - comiling from CVS is all well and good, but it isn't exactly a stable finished product.
You can be better in specific markets. Spatial Nautilus is probably a better paradigm for Apple's user community than the OS X finder. On the other hand, for Gnome, something more powerful might be better.
Except that (given the number of UNIX geeks saying they've found Nirvana with MacOS X) the number of power users for Macs is increasing. The Mac community might have a significant percentage of power users already.
In the meantime GNOME is aspiring to be usable for something other than just power users. Sure, if you want to permanently confine yourself to a niche market you can create something "better" for that market - but few people want to be so confined.
Jedidiah.
Re:What's wrong with finder?
on
Hacking Mac OS X
·
· Score: 4, Insightful
To understand the basic complaint about the OS X Finder look at this ArsTechnica article.
Which is essentially asking for a finder that works like the spatial Nautilus (this isn't surprising given that spatial Nautilus was designed based on this series of Ars Technica articles). We all know how well spatial Nautilus was recieved. I don't think you can win - there is no "better" only "different".
In the end I quite like what Nautilus has ended up with - you can pick or choose between the two options, and both are reasonably (if not exceptionally) well implemented.
The "choice" obsessed people would beat them down. They want every OSS effort to be splintered and fragmented, so that I have to install and load two entire desktop environments just to be able to run each other's apps.
The solution is quite simple: don't run the other DEs apps. Or actually pay for an OS - be it Windows, MacOS X, or something else altogether. No one is forcing you to use Linux/*BSD. If it sucks, by all means, stop using it.
The "Linux Desktop" is no some vast concerted effort, it is a hodge podge of whatever people are willing to contribute. As long as people are free to code whatever interests them there will always be splintering. If you don't like that, buy a system where there are enforced standards of what is acceptable.
No. The problem is that it BREAKS the package management of those systems.
So now I'd have to use TWO methods of updating my system. Great. Just what I was looking for.
Autpackage should sit peacefully alongside other package management systems, it is designed to be complementary, nt a replacement. As to a central place to manage your packages from, try Smart - it gives you a single interface view to your packages whether they be via RPM, DEB, TGZ or whatever. I have been contemplating writing an Autopackage channel/backend for Smart so that autopackage packages that have been installed will show up in smat and can be removed etc. from there as well.
"Das Boot" was truly an excellent film. It is the submarine movie, and nothing else comes close. Having said that, even a film of that quality only buys you so much respect. After "A Perfect Storm", "Air Force One", and "Troy" Peterson has spent it all. Maybe it's the influence of Hollywood producers, but whatever it is, the end results have been utterly appalling. I don't see Peterson signed on as Director as the least bit positive.
The whole point of Ender's Shadow was that Bean could NOT have done what Ender did, despite being "brighter". Bean lacked Ender's social skills, and his "killer instinct". Ender was a natural leader, while Bean was an awkward, self-conscious, loner. Ender could form and lead a team - a task the Bean struggled with. Ender killed his enemies, Bean humilated and angered his.
That was the cop out Card used, yes. It just doesn't wash though.
Bean lacked killer instinct? You mean the way he wanted to kill Achilles from the outset was lacking killer instinct? Bean was quite coldly ruthless most of the time.
Bean lacked people skills and couldn't lead? He managed to get the other army leaders to join him in "not playing the game". He managed to get his army to rally around him. He managed to have enough people utterly loyal to him to take out Achilles. When it mattered he seemed to have no problem getting people to follow him.
Sure Card threw in a few passages where Bean "lacked people skills" and used the "couldn't lead people" as an excuse as to why Ender was needed to do the job, but if you actually look at what Bean did in the book he was entirely capable of getting the job done.
Slashdot Mirror
The "cost of finding a bug" is incredibly variable, and the cost of developing the full benchtest setup of every possibility is often much higher than that of releasing a beta and letting people hammer at it to find some of the interesting corner cases you'd spend millions to workk through in iterative tests in the lab. Finding it in advance is good, but human review and test benches also add up.
Yes, exhaustive test benches are prohibitively expensive, which is why you use formal methods. I think perhaps you are not understanding what I mean by that. I'm refering to things like B-method, algebraic systems specification etc. which allow you to do rigourous mathematical analysis on your code. Using these sorts of methods you can construct formal proofs of the correctness of your code prior to having to do any testing. No, proofs like that don't make softare completely infallible, you'll probably still want to do some testing - but the point is that formal methods drastically reduce the amount of testing required. Ideally they also give you measures of the test space and help you to conduct targetted testing in a way that gives you the best possible coverage for the least amount of work.
Jedidiah.
You just have no idea of the cost of an absolute guarantee that it doesn't screw up. It doesn't cost 20% more or even 100% more, an "absolute guarantee" (formal methods) costs 10x to 20x more than "99.9% certain". Our employers almost never feel that the additional cost is worth the reduction in risk from 0.1% to 0% unless lives are on the line, and even then, they'll do just about anything to avoid the real costs.
I can't imagine a testign regimine that guarantees you 99.9% certainty of correct performance that manages to cost less than a formal method to prove your code, and associated targetted testing, that would give you the same 99.9% certainty. Exactly how many years of testing do you do? And where do you get that "...(formal methods) costs 10x to 20x more" from? I've never seen anything that gives figures like that. Another poster claims that formal methods costs the same or less, an coveniently provides sources for his quotes.
I rather suspect you are just pulling figures out of your ass to justify the way you do things.
Jedidiah.
How do you think those formal methods have been developed in the first place?! If not via "build and test"? How many bridges have fallen down before designers new enough to formalize their methods?
I'm talking about formal mathematical analysis, not a strict "you do this, then this, then this". Once Newtonian physics, calculus etc. was hammered out, mathematical analysis and proving of designs didn't require all that much testing at all - merely a bit of testign to get a good idea of how much error tolerance to factor in to cover the vagaries of the real world.
The computer world is pure binary data. It has no such vagaries. It is all just mathematics. So yes, someone has to sit down and figure out how to do the math to prove a program. Interestingly people already have. There's no testing involved in this, it's a matter of rigourous mathematics.
Naturally such a thing doesn't eliminate the need for testing, but it does drastically reduce th amount of testing required (as well as letting you design, for instance, a statistically significant sampling of of the test space), and it gives you a whole new level of checks and assurances on the quality of the code that testing simply can't compare to.
Jedidiah.
It is on Linux. Whether the Mac version did somethign special I don't know - I doubt it, as I don't think GTK supports a global top of the screen Mac style menu. Besides, Photoshop for Mac is a multiwindowed system anyway, the Mac just has the global menu, and decent support for palette windows in the window manager.
If you want a solution to GIMPs multiwindow issues, try reading my sig and lobbying the major Linux window managers to get at least some support for window groups in a sensible way.
If you're on Windows... sorry, you're out of luck on that one. I do believe there was a hack for Window GIMP that added a background window (like Photoshop on Windows), but I have no idea where to find it.
Jedidiah.
Adobe's interfaces tend to be pretty bad, actually, but they are an improvement on the GIMP's in some respects. I wonder if GimpShop really manages to incorporate the subtle things that give Photoshop an advantage, though...
Adjustment layers? CMYK support? I'm not sure what you're looking for. Having run it, I can tell you: it is the same old GIMP we know and love (or hate as the case may be), just with all the menus reorganized to be structured the same way Photoshop organizes them. Oh, and some of the tools have been renamed. Other than that, it's pretty much exactly the same. If you want to find "brightness-contrast" under "Image/Adjustments" Instead of "Layer/Color" then by all means you'll find this useful. If you want a complete Photoshop workalike... buy Photoshop.
Jedidiah.
Having downloaded and run the Linux version, I can assure you this is no joke. It's also not that big of a deal: mostly all that has been done is a rearrangement of the menus, and renaming of some of the tools. Other than that, it's still the GIMP with its usual multiwindow interface. If you're a die hard photoshop fan (why are you using GIMP) then it would help with your transition. ut really, I found the menu layout to be no more logical than the original GIMP layout - each structure has it's own logic which can be argued for.
I appreciate what the guy has done, and it is probably a fair amount of work. Unless you need your menus structured the same way Photoshop structures them though, this probably isn't going to make much difference to you.
Jedidiah.
Which is really a long excuse for failing to go through the design stage where you work with the end users to develop a formal requirements specification.
If you are designing a new GUI frontend for database access, sure, you probably want to have flexiility in requirements. If you are writing a mission critical application of any kind (pretty much anything where stability, integrity, or security are important) you really ought to be get a formal specification of requirements worked out with the user before you start. Make it contractual. If you can't fully spec the whole project, formally spec the critical parts (say the backend) and don't bother with the formal development of the GUI frontend for the users - the principle being that the part that has to work will work, and if the GUI fails - well, your design should isolate that so that it can't cause any data corruption or loss at the backend which is formally specified, and guaranteed not screw up.
I'm interested, do all you developers do nothing but write software where the costs of failure, data corruption, data loss, or security breaches are negligible? I thought all these slashdot people were busy writing mission critical enterprise applications (well, not really).
Jedidiah.
The cost of a bug in software found after deployment is vastly higher than the cost of a bug found prior to deployment. That coul take the form of a bug causing severe data loss or downtime in a critical production environment, or it could take the form of a security vulnerability is a deplyed product.
If your software is intended to fulfill a critical role, be dependable, or be secure, then "rebuilding" after the fact comes at an extremely high price. Not every desktop application needs to be built to serious engineering principles, but if the application is "mission critical" then perhaps you ought to consider what you can do besides a bit of testing to be sure it is going to be stable and work as intended.
Sure, if management persists with short deadlines you'll never be able to produce quality. Pretending that proper engineering of systems isn't necessary is only going to help lower managements expectations of how hard it is to develop software.
Jedidiah.
The simplest reason is that for all but a tiny, TINY fraction of software projects, the worst thing that a catastrophic failure can cause is data loss.
Sure, but let's be honest, catastrophic failure and data loss can be very very bad. It can cost a company many many millions of dollars. It can cost a country a fair democratic election (presuming they, for some reason, use electronic voting with no paper trail - but why would any country be silly enough to do that?). I'm not proposing formal methods to design a minor desktop application, I'm proposing formal methods for anything deemed mission critical, or anything where security is important. There are plenty of projects that fall into those sorts of categories for which no real level of formal design is used.
And that bridges typically serve a single, simple purpose, whereas software depends on the complex interaction of thousands of elements that are not well-understood.
Yup. I never said software engineering was as easy as bridge engineering, merely that it is possible to do the same level of design and engineering. Formal specification, verification and validation of software is hard. It is still an active research field. That does not mean, however, that practical systems for doing it are not available. It can be done. As I said, in the worst case you can restrict yourself to formal methods for just those small components of the total system that are the most critical - validate those.
I think the real problem is that too many developers are unaware of what is available in the way of formal methods. If you don't know what can be done, of course you're not even going to consider it for your project. It may, or may not be appropriate, but if you don't even know what can be done, how can you judge appropriateness?
Jedidiah.
Which comes straight back to the point that it is a matter of changing the expectations of the public with regard to how software design and construction works. How do you expect to educate the public when the developers themselves are accepting of half assed hack it together methods even for critical systems? Where the hell was Diebold's formal specification and validation of their code? Do you really believe they shouldn't have bothered with such a thing?
Jedidiah.
However (and it's a big however), it still doesn't mean that your solution is correct! Did you get the requirements right? Is your system what the users expected? Is the interface layout easy to use? Is it fast enough to be useful? Does it add value to the customers toolset?
You can ask the same questions about bridge design. Did you get the requirements for the bridge right (maybe it actually needs to be able to bear more weight than your requirements said)? Is your bridge what the users expected (Is it in the right place, satisfying the right requirements?)? Is the bridge interface right (Are there enough lanes, support for rail as well, etc.)? Is it light/flexible/cheap enough to be useful? Does it add value to the the local residents lives? These are all questions that formal bridge design methods don't address. That doesn't mean we don't design bridges formally, it means we spend a lot more time getting the requirements properly formalised and documented and checked for correctness. Yes, customers don't expect to have to do that with software, but if integrity, stability, or security are at all important we should be teachign them that such things are part of the process.
Honestly, can you tell me you wouldn't be far happier if the software for electronic voting machines didn't have a formal requirement specification that you can check and code that has been verified and proven against that specification? I know I would. How about that mission critical database or webserver? How about your email encryption software - there are formally specified protocols from which to build requirements? The little database access frontend that you whipped up for accounting is not going to require formal design, but not all projects have such a high tolerance for faults, security breaches, or stability issues
Jedidiah.
I said, quite specifically, that formal methods are harder and take longer. Can I deliver to an arbitrary deadline? Of course not. Why am I being asked to deliver to such an arbitrary deadline though? Because the customers don't appreciate that getting correct code is a matter of formal design which is going to be time consuming. Because the customers don't realise that simply throwing something together and running a few random tests is not really sufficient to build a system where stability, integrity, or security are factors. Sure that's a problem.
My point is that if the people writing the software think throwing it together and running the odd test is good enough, then how the hell are the customers and general public going to learn any better?!
Jedidiah.
I think that's exactly the problem with software expectations. They always assume that building software is like building a house, or a bridge, or a toaster. In other words, they always assume that building software is done by experienced people who've built nearly identical software systems before.
When an engineer designs and builds a new bridge it is entirely possible that no bridge like it has ever been designed or built before. Sure, there are some base cases that just get churned out, but there are also big, new, creative designs that occur for bridges. How is that bridge engineers usually manage to not have their bridges falling down all the time? Well, for starters the designer doesn't run with a "build and test" mentality. There are formal methods for bridge design, and if you assume the properties of various basic components, there are methods to prove the stability and properties of the bridge. Did you know that there are formal methods for software design, and if you assume the properties of basic components (like hardware, OS , etc.) there are methods to prove the stability and properties of the software?
Yes, formal software methods are hard and time consuming compared to just building and testing. Formal bridge design is hard and time consuming compared to just building and testing.
For some reason we accept that software should be just thrown together rather than properly designed and proved. Yes, there are plenty of projects for which the level of formality I'm talking about simply isn't required - that's fine. My point is that there are plenty of projects for which the level of formality I'm talking about would be a damn good idea - yet it is never even contemplated let alone used. At worst you should be considering some level of formality for just those components of your system that are most critical.
Jedidiah.
No Linux gives you all that, with almost zero effort.
I never claimed any current Linux ditribution did - that was kind of my point. Be able to guarantee a userbase buying your product and you can invest in little GUI tools to automate setting up firewalls etc (though Redhat and SuSE already provide many of these things), not to mention the fact that all the hardware vendors will make sure they work with "distribution X" as they have significant market share, so anything yu plug in will "just work". The market also ensures commercial software developers provide plenty of high quality, perfectly integrated "just works" software.
No Linux distributor can do this, ecause they can't guarantee the market. It can't and won't happen. It was a thought experiment, not a statement of present reality. Pay attention.
Jedidiah.
There's no advantage to using the x86 architecture aside from a perceived price gain.
Actually there is the issue of availability. Apple has had issues with the supply of PowerPC chips, particularly G5s. On the x86 side of the fence there are no such availability issues as Intel and AMD already have large markets adn produce extremely large volumes. That said...
I'd rather see Windows, Linux, BSD, etc move to the PowerPC architecture.
If this actually happened then the situation would likely reverse as the volume of PowerPC chips in demand would be huge, and some serious productuon facilities would get built to deal with it.
In the meantime Apple will have minor supply issues. Given the costs of switching/porting to x86 I don't see how the gains (in availability) could possibly be worth it.
On another note: Where exactly are the Linux PPC systems? PPC Linux works quite well from what I've heard - why aren't there any people selling Linux PPC desktops or laptops?
Jedidiah.
I agree entirely. Had MacOS X been poor it would have failed. I'm simply trying to point out that it didn't have to be magic either. These days unless you are very niche, an OS needs good support from application developers to get anywhere, and Microsoft has a stranglehold on most developers. If you don't get the app developers, you don't get any applications, and no one wants to use the platform... and so it dies.
Mac and Linux are two wannabe mainstream OSs that have managed to survive. MacOS X did this by being able to promise app developers a guaranteed market, and so they got a lot of serious commercial app developers on board.
Linux managed by being open and letting developers do whateer they want with it - thus appealing to a wide range of developers who want to tinker. It also managed to become to poster boy for open source, which again, attracts all the developers. The upside for Linux is that it never had to be able to promise market share - the people who wrote apps for it just wanted a platform they could do whatever they wanted with. The downside is that Linux app developers are a broad bunch who will write whatever they want. That means that while Linux has managed to aquire a fairly strong set of applications, there are a lot fewer guarantees that they all play together nicely, or really have much of anything in common at all.
The truly interesting point, as far as I'm concerned, is that there really isn't much more room in the OS market. Either you have to be an open source poster boy and attract the developers that way, or you have to be able to guarantee some market share. In the mainstream desktop market, I don't see any new commercial OS doing that.
Jedidiah.
How do you set up the firewall in GNOME?
Use what the distro provides, or use Firestarter or similar. A little frontend to firewall configuration is hardly difficult. Redhat has a nice one for example. Yes, it's simple, but if you want hardcore firewall configuration your tool is going to get complicated and you may as well use Firestarter. Given that both SuSE and Redhat (the main commercial vendors) provide simple GUI tools that integrate into the desktop to set up firewalls, I think we can easily presume Distribution X does the same.
How do you integrate your digital camera with your screensaver?
I'm not sure, I haven't tried, but why is that important? I'm sure there are things you can do simply in GNOME/Linux that are more tricky in Mac OS X (How do you sort email into virtual folders like in Evolution? How do you manage multiple WiFi connections with a click or two?).
If someone sat down with GNOME adn Linux, standardised everything, and could promise developers a large(ish) userbase that would all hew precisely to those standards - I think that distribution would quickly become as "easy" and "just works" as Mac OS X. Will that happen? No. You need to be able to promise a captive userbase, and no Linux distribution can do that.
Jedidiah.
What amazes me most is how short of a time it took for OS X to get put together.
What really made MacOS X work is that Apple already had a very secure decently sized niche market for Macs. That is, there was a guaranteed devoted userbase that:
(1) Hardware manufacturers bother to write and include drivers.
(2) Software companies bother to release OS X versions of their applications.
That means that "things just work" - hardware works, and there is enough software, all built for the specific platform, that it all plays together nicely.
Imagine, for a minute, that there was a Linux distributor (Call them X) that standardised on a fixed platform (say GNOME for example), and had enough guaranteed userbase that Adobe wrote a version of the Creative Suite (Photoshop, Illustrator, etc.) for GNOME, Microsoft released MS Office for GNOME, and lots of other serious software companies also wrote GNOME versions of their commercial applications. All of a sudden distribution X would be a viable platform that had all the software you need, and it all works seamlessly together inside GNOME. Presuming you also have hardware coming with distribution X drivers, dsitribution X would be quite reasonable competition for OS X - it would certainly have the "it just works" factor.
You can redo the whole gedanken experiment with KDE if you like, you'll get similar results.
What made OS X really work was the guaranteed userbase and the fact that it could run old mac software to ensure a smooth transition of that userbase and an immediate supply of software. Honestly, if a small startup company wrote a brand new OS that was as good as OS X but lacked the userbase, and hecne software and hardware support, it would just potter along and probably eventually die or get bought out (see BeOS, NeXTStep etc.)
Jedidiah.
Nope, next update is to Emacs so the whole Emacs/VI holy war can erupt and somebody can poke there head up and say pico or joe.
Don't laugh, the new (CVS) version of GNU Emacs uses GTK+ and integrates into GNOME or XFCE quite nicely (except for keybindings, of course, which can be changed to suit). I'm quite keen for the next version to actually arrive - comiling from CVS is all well and good, but it isn't exactly a stable finished product.
Jedidiah.
You can be better in specific markets. Spatial Nautilus is probably a better paradigm for Apple's user community than the OS X finder. On the other hand, for Gnome, something more powerful might be better.
Except that (given the number of UNIX geeks saying they've found Nirvana with MacOS X) the number of power users for Macs is increasing. The Mac community might have a significant percentage of power users already.
In the meantime GNOME is aspiring to be usable for something other than just power users. Sure, if you want to permanently confine yourself to a niche market you can create something "better" for that market - but few people want to be so confined.
Jedidiah.
To understand the basic complaint about the OS X Finder look at this ArsTechnica article.
Which is essentially asking for a finder that works like the spatial Nautilus (this isn't surprising given that spatial Nautilus was designed based on this series of Ars Technica articles). We all know how well spatial Nautilus was recieved. I don't think you can win - there is no "better" only "different".
In the end I quite like what Nautilus has ended up with - you can pick or choose between the two options, and both are reasonably (if not exceptionally) well implemented.
Jedidiah.
The "choice" obsessed people would beat them down. They want every OSS effort to be splintered and fragmented, so that I have to install and load two entire desktop environments just to be able to run each other's apps.
The solution is quite simple: don't run the other DEs apps. Or actually pay for an OS - be it Windows, MacOS X, or something else altogether. No one is forcing you to use Linux/*BSD. If it sucks, by all means, stop using it.
The "Linux Desktop" is no some vast concerted effort, it is a hodge podge of whatever people are willing to contribute. As long as people are free to code whatever interests them there will always be splintering. If you don't like that, buy a system where there are enforced standards of what is acceptable.
Jedidiah.
No. The problem is that it BREAKS the package management of those systems.
So now I'd have to use TWO methods of updating my system. Great. Just what I was looking for.
Autpackage should sit peacefully alongside other package management systems, it is designed to be complementary, nt a replacement. As to a central place to manage your packages from, try Smart - it gives you a single interface view to your packages whether they be via RPM, DEB, TGZ or whatever. I have been contemplating writing an Autopackage channel/backend for Smart so that autopackage packages that have been installed will show up in smat and can be removed etc. from there as well.
Jedidiah.
Currently Wolfgang Peterson is slated to direct
"Das Boot" was truly an excellent film. It is the submarine movie, and nothing else comes close. Having said that, even a film of that quality only buys you so much respect. After "A Perfect Storm", "Air Force One", and "Troy" Peterson has spent it all. Maybe it's the influence of Hollywood producers, but whatever it is, the end results have been utterly appalling. I don't see Peterson signed on as Director as the least bit positive.
Jedidiah.
The whole point of Ender's Shadow was that Bean could NOT have done what Ender did, despite being "brighter". Bean lacked Ender's social skills, and his "killer instinct". Ender was a natural leader, while Bean was an awkward, self-conscious, loner. Ender could form and lead a team - a task the Bean struggled with. Ender killed his enemies, Bean humilated and angered his.
That was the cop out Card used, yes. It just doesn't wash though.
Bean lacked killer instinct? You mean the way he wanted to kill Achilles from the outset was lacking killer instinct? Bean was quite coldly ruthless most of the time.
Bean lacked people skills and couldn't lead? He managed to get the other army leaders to join him in "not playing the game". He managed to get his army to rally around him. He managed to have enough people utterly loyal to him to take out Achilles. When it mattered he seemed to have no problem getting people to follow him.
Sure Card threw in a few passages where Bean "lacked people skills" and used the "couldn't lead people" as an excuse as to why Ender was needed to do the job, but if you actually look at what Bean did in the book he was entirely capable of getting the job done.
Jedidiah.