. but old in terms of years, experience, etc.
Since this list is exceedingly small (only 14 posts for all of 2018), I can make a few recommendations that could take it from being the "Swiss Army Knife" that it is, to being a switchblade that it deserves to be. First of all, I am not familiar with DTrace and the many uses for it. In this recommendation, some of the uses will be ignored/forgotten and some additional ones will be enhanced (those that need enhancement). I worked at Nortel for about 20 years in many different types of jobs, but the last 10 years were spent as a Unix system administrator or the manager of Unix system administrators. My last title at CSC (Nortel outsourced all of their IT to CSC in ~2000) was manager of Enterprise Server and Storage. It was a lofty sounding title and it was the most miserable job I had. I was laid off in 2004. I remember DTrace from the ~2007 timeframe. It ran on Solaris and Solaris had an open source pedigree. What became of this pedigree has just been determined. Enough about me. This is to let you know that the recommendations are not from Developer, but a systems administrator perspective. What I'd recommend for DTrace (to get it out of the slump that it is currently in): 1) Use it as part of the "re-usable code" system for testing. 2) Use any large code base (compilers, Linux kernel, BSD kernel, X Windows, applications, etc.) as part of the re-usable code. 3) Compile them down to a reusable format such that the variable/function names are the same so that it can be understood by a computer. 4) Really get the code reusable by looking at Modula-2 or ADA to mathematically prove that the compiled modules are correct. There are major sections that are left out and should be jettisoned. For instance, the need to port this on additional operating systems. FreeBSD is good enough. If somebody wanted to port it to Linux, it would have already been done. Performance is another part. Although performance is one of the strengths of DTrace, it has to be used first and anything that is slowing down its usage (like performance) is diverting the energy that must be maintained for this project to succeed. Performance can come at the next iteration. We have seen many "open source" projects that are no more, so there can be some discussion of the causes of their demise so we can learn from them and not make the same mistakes. Comments? Observations? Mike Mazarick --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------- dtrace-discuss Archives: https://www.listbox.com/member/archive/184261/=now Modify Your Subscription: https://www.listbox.com/member/?member_id=25769126 Powered by Listbox: https://www.listbox.com
