As other people have suggested, one path is to invest in an expert system. You haven't mentioned how many rules your expert system consists of, and you may switch to some other expert system to find that it hasn't improved your capability to manage your rules.
Regardless of whether you switch or not, I cannot overemphasize the importance of having a good suite of regression tests for your rules.
I read the rant you linked to and while I think it had some reasonable things to say, I think you'll find you're a bit off here.
As far as supercomputing goes, it's all about doubles rather than floats, and the G5 has a strong edge over the P4s here.
For example, the top P4 supercomputer ranks at #10 with 1250 3.06 GHz Dual Xeons.
Quoted Rpeak is 15300 Gflops, coming to 6.12 GFlops per processor, or 12.24 for each dual box.
As a reminder, the XServes are 9.2 Gflops per processor, or 18.4 per dual box.
As far as pricing is concerned, I configured a Dell PowerEdge 1850 (the successor to the 1750s used in the previously mentioned NCSA cluster) to be equivalent to the Dual Xserve G5.
It came to slightly over $4000, while the Dual Xserve G5 is obviously overpriced at $3000.
Though I must admit to comparison wasn't totally fair - to keep the price of the Dell down I configured it without an operating system.
So to summarize: The Xserve G5s are $3000 for 18.4 Gflops - or $163/Gflop. The Dell Xeon was $4000 for 12.24 Gflops - or $326/Gflop.
Reconfiguring the Dells with faster processors, 3.6Ghz instead of 3.0Ghz, raises the price to $4600 for 14.4 Gflops, or $314/Gflop
Parent poster messed up on their calcs.
Current XServes are 18.4 GFlops peak, not 35
eg Virginia Tech currently at #7/500 is 20240 GFlops peak for 1100 XServes.
So 7 would only be ~129 GFlops peak, and 33 would be 607 GFlops peak.
But not exactly fitting in a single tower case - though 8 would fit nicely one of those mini sound-padded racks which would be almost as good.
And at least the last time I saw a price comparison made, the G5s were far cheaper than comparable rack P4s. (The G5 has 2x the FP hardware).
Is the output easy to parse so I can get it into the form I want?
Can launctl stop service be run automatically and log something to a postgresql if it couldn't be run for some reason?
Apparently in your world all software is completely perfect and doesn't require custom applications to be written. Apparently I've been wasting my time writing development tools.
I didn't way the propertly list xml was unable to do the job, just that it was badly structured - a concept that you seem to take personally.
My issue here is that while it's previous scope was limited to application manifests, preferences, etc, the issues were limited, but as part of a bold new platform for process launching - something that is far more likely to want some degree of customized reporting within the enterprise, its shortcomings are painfully apparent.
And ultimately my point that it's silly that you should be forced to resort to CFDictionary to do anything with a property list that isn't provided by launchctl can't be countered with "you should use CFDictionary".
If I want to write a web service using PHP that wants to access config data, where's my CFDictionary interface?
If I'm writing something with Java under Linux, where's my CFDictionary interface?
If you want something closer to home, where's my CFDictionary interface in RealBasic?
The fact that you can obviously spend so much time posting to slashdot indicates that you don't do much of importance. I do.
That's exactly how you're supposed to do it. It's not meant to be done in another way. Why would you want to do it any other way?
Because maybe I don't want to learn yet another API for no good reason. What's the point of having it written in XML if the only way to conveniently access it is by using a different API? It's a PITA if I need to track down a module for accessing property lists in every tool I use.
Your whole concept of "best practice" seems to revolve around some ideas that simply don't apply. You want to "pretty print" your property lists? What?
Sure, why not. Let's say I want to write a utility that lets me view all of my launchd config files.
Do I want the end-user to see raw XML? No. So I write an XSL template to reformat the data into something more presentable and present it in a web view. Whoops! Can't do it - have to write code instead (the separation of keys and values prevents me from doing any useful reformatting).
Another example: I want to find the launchd items that directly depend on another item - and there isn't a CFDictionary implementation in the tool I'm using, but it has a perfectly good XML implementation.
Because the property list XML isn't structured properly, I have to write a chunk of pointless deserialization code to get to the data I need, while if the data was formatted correctly in the first place, it would be a trivial one liner.
The strength of XML isn't just the data format - it's the wealth of tools that exist for operating on arbitrary XML data. The damage was limited when it was an Apple specific mechanism, but now they are presenting this to the wider community.
My idea of best practice in XML is the ability to leverage the tools that exist for operating on XML. Your argument that validation is the only thing that anybody would ever want is just closed-minded and your assertion that every development tool should include a CFDictionary implementation to deal with the format's deficiency is just silly.
It's not hard to fix the property list format. Just make the values and keys more strongly bound - eg something like: <item key="blah">value xml data here</item>. There is nothing lost by doing this - and everything to gain. CFDictionary is no longer required to easily access property lists, and they are easily transformable.
..and one of the big advantages of serializing into XML is that it's easier for it to be consumed by other applications.
The fact that it's improperly structured, means that nothing useful can be done with the data outside of loading it into a CFDictionary.
The parent poster 6e7a specifically ran into problems when he/she wanted to retrieve information - something that would have been trivial if the xml was formed properly.
What's the point of it being in XML if it can only be effectively loaded/manipulated with a CFDictionary? Pretty much any development tool, scripting or otherwise, already has a decent XML library available - but you think they should all have a CFDictionary interface just in case they want to operate on a property list? Or write a pile of extra code because the data is arranged crappily?
Perhaps you use XML differently than I do. I tend to use lots of XPaths, write quick and dirty reports with XSL, etc. Why do I do that? Because it makes things easier. And I can do this in pretty well any tool that has XPath support.
All of these things aren't possible in this case because Apple's property list XML isn't properly structured.
I have suggested one way that the schema could be fixed to make it compatible with the wider world of XML tools, and your response was that nobody wants to do that anyway - even though the poster who set off this subthread wanted to do exactly that.
is basically useless to any other XML tool. XML format is supposedly for interoperability, so your suggestion to always unserialize into CFDictionary is not really useful.
An alternative could be: <dictionary>
<item key="item1">
<string>somevalue</string>
</item>
<item key="item2">
<string>somevalue2</string>
</item> </dictionary>
which would be readily digestible by any other XML parsing tool, XSL, etc.
(the value is the child of the item, rather than being an attribute, as often dictionary values can be other dictionaries, etc)
I wouldn't hold your breath on Onyx doing an OS X version anytime soon.
I was the original author of Spotlight, and they haven't developed the IP much from the original version I sold them (I'd sold it because I was busy creating CrossBasic at the time, which was eventually renamed to RealBasic).
In fact they went so far as to threaten me with legal action a couple of years ago, when I started to develop a Mac OS X equivalent, even though the non-compete provision had expired.
As a software developer, I need to pay the bills - back when I was single I didn't much to survive, but once you add in wife, three children, etc, you really need to pay attention to the bottom line.
I'm in the process of developing a commercial app for Linux that I'm hoping will bring in sufficient revenue for me to dedicate a reasonable portion of my time to - but I can't deny that it's not without a certain amount of trepidation.
Consider how 'big' Perl is to the open source community, or PHP, or Python - and then consider how many people can afford to work full-time on them. It's a fairly sobering thought.
The biggest cause of compiler problems is from the optimizer.
Turn it off.
If you have some very time critical sections of code, try turning on the optimizer for just those routines - but otherwise you're just asking for trouble.
Actually, I think you missed the full extent of the original question.
If I give your sister a built version of a GPL program, I'm suddenly obligated to provide her with a copy of the source code.
Indeed, I'm potentially obligated to provide her with the exact source for the version I gave her, even if she asks for the source several years later.
Presuming that the source is non-trivial, perhaps I'd even have to buy a CD-burner to provide her with the source...
Of course your sister isn't likely to take me to court over this, but under the strict terms of the GPL, I'm undertaking a new obligation every time I share a program that I like (whether I am the original author or not).
Slashdot Mirror
That would make a good sig: "I am *so* stealing this quote"
---
I am *so* stealing this quote
As other people have suggested, one path is to invest in an expert system. You haven't mentioned how many rules your expert system consists of, and you may switch to some other expert system to find that it hasn't improved your capability to manage your rules. Regardless of whether you switch or not, I cannot overemphasize the importance of having a good suite of regression tests for your rules.
I read the rant you linked to and while I think it had some reasonable things to say, I think you'll find you're a bit off here.
As far as supercomputing goes, it's all about doubles rather than floats, and the G5 has a strong edge over the P4s here.
For example, the top P4 supercomputer ranks at #10 with 1250 3.06 GHz Dual Xeons.
Quoted Rpeak is 15300 Gflops, coming to 6.12 GFlops per processor, or 12.24 for each dual box.
As a reminder, the XServes are 9.2 Gflops per processor, or 18.4 per dual box.
As far as pricing is concerned, I configured a Dell PowerEdge 1850 (the successor to the 1750s used in the previously mentioned NCSA cluster) to be equivalent to the Dual Xserve G5.
It came to slightly over $4000, while the Dual Xserve G5 is obviously overpriced at $3000.
Though I must admit to comparison wasn't totally fair - to keep the price of the Dell down I configured it without an operating system.
So to summarize:
The Xserve G5s are $3000 for 18.4 Gflops - or $163/Gflop.
The Dell Xeon was $4000 for 12.24 Gflops - or $326/Gflop.
Reconfiguring the Dells with faster processors, 3.6Ghz instead of 3.0Ghz, raises the price to $4600 for 14.4 Gflops, or $314/Gflop
Parent poster messed up on their calcs. Current XServes are 18.4 GFlops peak, not 35 eg Virginia Tech currently at #7/500 is 20240 GFlops peak for 1100 XServes. So 7 would only be ~129 GFlops peak, and 33 would be 607 GFlops peak. But not exactly fitting in a single tower case - though 8 would fit nicely one of those mini sound-padded racks which would be almost as good. And at least the last time I saw a price comparison made, the G5s were far cheaper than comparable rack P4s. (The G5 has 2x the FP hardware).
Does launctl be run as a web service?
Is the output easy to parse so I can get it into the form I want?
Can launctl stop service be run automatically and log something to a postgresql if it couldn't be run for some reason?
Apparently in your world all software is completely perfect and doesn't require custom applications to be written. Apparently I've been wasting my time writing development tools.
I didn't way the propertly list xml was unable to do the job, just that it was badly structured - a concept that you seem to take personally.
My issue here is that while it's previous scope was limited to application manifests, preferences, etc, the issues were limited, but as part of a bold new platform for process launching - something that is far more likely to want some degree of customized reporting within the enterprise, its shortcomings are painfully apparent.
And ultimately my point that it's silly that you should be forced to resort to CFDictionary to do anything with a property list that isn't provided by launchctl can't be countered with "you should use CFDictionary".
If I want to write a web service using PHP that wants to access config data, where's my CFDictionary interface?
If I'm writing something with Java under Linux, where's my CFDictionary interface?
If you want something closer to home, where's my CFDictionary interface in RealBasic?
The fact that you can obviously spend so much time posting to slashdot indicates that you don't do much of importance. I do.
That's exactly how you're supposed to do it. It's not meant to be done in another way. Why would you want to do it any other way?
Because maybe I don't want to learn yet another API for no good reason. What's the point of having it written in XML if the only way to conveniently access it is by using a different API? It's a PITA if I need to track down a module for accessing property lists in every tool I use.
Your whole concept of "best practice" seems to revolve around some ideas that simply don't apply. You want to "pretty print" your property lists? What?Sure, why not. Let's say I want to write a utility that lets me view all of my launchd config files.
Do I want the end-user to see raw XML? No. So I write an XSL template to reformat the data into something more presentable and present it in a web view. Whoops! Can't do it - have to write code instead (the separation of keys and values prevents me from doing any useful reformatting).
Another example: I want to find the launchd items that directly depend on another item - and there isn't a CFDictionary implementation in the tool I'm using, but it has a perfectly good XML implementation.
Because the property list XML isn't structured properly, I have to write a chunk of pointless deserialization code to get to the data I need, while if the data was formatted correctly in the first place, it would be a trivial one liner.
The strength of XML isn't just the data format - it's the wealth of tools that exist for operating on arbitrary XML data. The damage was limited when it was an Apple specific mechanism, but now they are presenting this to the wider community.
My idea of best practice in XML is the ability to leverage the tools that exist for operating on XML. Your argument that validation is the only thing that anybody would ever want is just closed-minded and your assertion that every development tool should include a CFDictionary implementation to deal with the format's deficiency is just silly.
It's not hard to fix the property list format. Just make the values and keys more strongly bound - eg something like: <item key="blah">value xml data here</item>. There is nothing lost by doing this - and everything to gain. CFDictionary is no longer required to easily access property lists, and they are easily transformable.
What else do you want?
I'd like a property list format that was compatible with XPath.
At the moment, I can only retrieve values from a property list either by using the CFDictionary interface, or by processing it with custom code.
If property lists were structured better, then I could do easily retrieve data values with XPaths, easily pretty print them with XSL, etc.
My basic point is that while they are indeed XML, they don't even come close to best practice.
..and one of the big advantages of serializing into XML is that it's easier for it to be consumed by other applications.
The fact that it's improperly structured, means that nothing useful can be done with the data outside of loading it into a CFDictionary.
The parent poster 6e7a specifically ran into problems when he/she wanted to retrieve information - something that would have been trivial if the xml was formed properly.
What's the point of it being in XML if it can only be effectively loaded/manipulated with a CFDictionary? Pretty much any development tool, scripting or otherwise, already has a decent XML library available - but you think they should all have a CFDictionary interface just in case they want to operate on a property list? Or write a pile of extra code because the data is arranged crappily?
Perhaps you use XML differently than I do. I tend to use lots of XPaths, write quick and dirty reports with XSL, etc. Why do I do that? Because it makes things easier. And I can do this in pretty well any tool that has XPath support.
All of these things aren't possible in this case because Apple's property list XML isn't properly structured.
I have suggested one way that the schema could be fixed to make it compatible with the wider world of XML tools, and your response was that nobody wants to do that anyway - even though the poster who set off this subthread wanted to do exactly that.
The basic point here is that the plist stuff is XML unfriendly.
<dictionary>
<key>item1</key>
<string>somevalue</string>
<key>item2</key>
<string>somevalue2</string>
</dictionary>
is basically useless to any other XML tool. XML format is supposedly for interoperability, so your suggestion to always unserialize into CFDictionary is not really useful.
An alternative could be:
<dictionary>
<item key="item1">
<string>somevalue</string>
</item>
<item key="item2">
<string>somevalue2</string>
</item>
</dictionary>
which would be readily digestible by any other XML parsing tool, XSL, etc.
(the value is the child of the item, rather than being an attribute, as often dictionary values can be other dictionaries, etc)
I wouldn't hold your breath on Onyx doing an OS X version anytime soon.
I was the original author of Spotlight, and they haven't developed the IP much from the original version I sold them (I'd sold it because I was busy creating CrossBasic at the time, which was eventually renamed to RealBasic).
In fact they went so far as to threaten me with legal action a couple of years ago, when I started to develop a Mac OS X equivalent, even though the non-compete provision had expired.
Gollum's Song (sung to Sound of Silence)
My lovely Precious was the ring
Which I loved like anything
'Til a thief cam by to rob it
Was a filthy stinking hobbit
For many years,
I've crawled through filth and grime
Marking time
'Til I gets back, my Precious
As a software developer, I need to pay the bills - back when I was single I didn't much to survive, but once you add in wife, three children, etc, you really need to pay attention to the bottom line.
I'm in the process of developing a commercial app for Linux that I'm hoping will bring in sufficient revenue for me to dedicate a reasonable portion of my time to - but I can't deny that it's not without a certain amount of trepidation.
Consider how 'big' Perl is to the open source community, or PHP, or Python - and then consider how many people can afford to work full-time on them. It's a fairly sobering thought.
i.e. Outside the US, the figures would seem to be:
- PS2: 34 million
- Gamecube: 5.6 million
- Xbox: 3.2 million
I hadn't realized the figures were so one-sided outside of the US.So we now try and slashdot servers before they are even up?
Turn it off.
If you have some very time critical sections of code, try turning on the optimizer for just those routines - but otherwise you're just asking for trouble.
This is the OpenGL call to copy a block of pixels from the frame buffer.
EvilAndrew
Actually, I think you missed the full extent of the original question.
If I give your sister a built version of a GPL program, I'm suddenly obligated to provide her with a copy of the source code.
Indeed, I'm potentially obligated to provide her with the exact source for the version I gave her, even if she asks for the source several years later. Presuming that the source is non-trivial, perhaps I'd even have to buy a CD-burner to provide her with the source...
Of course your sister isn't likely to take me to court over this, but under the strict terms of the GPL, I'm undertaking a new obligation every time I share a program that I like (whether I am the original author or not).