As has been mentioned, there's a relatively small number of Cocoa and/or Objective-C programmers around. However, you don't need all that many people (maybe only one?), so I don't see this as a major constraint.
In fact, I might suggest that you consider going into an even smaller niche. By choosing RubyCocoa (or its upcoming replacement, MacRuby), you might be able to create a framework that would encourage scientists to add their own code.
A great deal of Open Source software is written by employees and released by the companies that employ them. This can offer real benefits to the company, in that they may get outside help in the project (eg, in development, documentation, maintenance, and testing).
If the code base starts to attract outside attention, the company may be able to have the developer(s) take on some organizational tasks (herding cats:), as well.
There's a lot of interesting work going on in Semantic Wikis. Most of these work by adding a "type" tag to a wiki link. By using the current page, target page, and type as the subject, object, and predicate, they can form an RDF triple. Other efforts go off in the direction of more formal ontology editing, etc.
The Semantic Wiki page on Wikipedia is a good starting point. I have also written my own overview, including an annotated list of known efforts.
Finally, the Semantic Wiki Interest Group is the best place to go to get involved or watch for new developments.
I am particularly interested in the possibility of augmenting wikis with mechanically-derived content. For example, there could be a Doxygen-style wiki page for each function and data structure in a system. Users could create new pages and/or annotate mechanically-generated pages. I am working on a specification for a wiki that could support such a system, but it's still quite speculative.
Re:Do what Mac Zealots have always done...
on
x86 Assembly on Mac OS X
·
· Score: 2, Interesting
Or, more usefully, code each assignment up both ways and hand in both versions. You'll learn more about both architectures than you would from doing either one alone. And, if the professor is even a bit open-minded, you'll get extra credit for the work.
Thank you, doom, for the nice review. Thanks, as well, to timothy, Slashdot, and the folks who have taken the time and effort to comment. I would like to respond to a few points that have been raised here; I'll try to be brief (:-).
Printed and online documentation are not mutually-exclusive alternatives. I use either or both, depending on my needs of the moment. Books have been around for about two millenia, so it's not surprising that they work well for certain purposes. It is obvious, however, that electronic access has its own advantages.
An edited collection (whether printed or PDF) adds significant value over the "raw" body of source documents. Documents must be located, evaluated, selected, organized, and formatted. It's not accidental that doom found some novel tools in our collections; part of our objective is to introduce readers to relevant tools, whether they are part of a "standard distribution" or not.
Doom is quite correct about the economies of scale for small press runs. Our books are demand-printed in very small lots. This keeps the investment small, but the cost per item is about three times (!) that of offset printing. Only the use of Internet-based sales allows us to offer reasonable pricing.
Like doom, I'd like to see a "Linux Browser", but my resources are limited and I'm concentrating on other tasks right now. If some Linux-knowledgeable folks want to help (e.g., by annotating directories and file system relationships), I encourage them to get in touch.
Aside from DOSSIER, my current efforts are concentrated on creating a browser that will run on a local system and provide integrated access to documentation and system metadata. I'm writing a series on this for MacTech Magazine.
A final note on DOSSIER: send topic suggestions! If you'd like to see a volume on a particular topic, let me know; I may be able to do something about it (:-).
Re:system call tracing needs to become standard
on
Systrace for Mac OS X
·
· Score: 2, Interesting
I would very much like to see OSX ship with truss; in particular, I would like it to be the Solaris-style truss that can trace descendents of processes, etc. (The FreeBSD version is only a pale shadow of this.) Anyone who agrees with this wish might want to send a note to devbugs@apple.com, supporting Problem ID #3121601.
Previous distributions have included image files for the boot floppies; I assume that this one will, as well. Most modern PCs can boot directly from the CD-ROM, however.
My preference is to use a special-purpose box for the first-level firewall. Packet filtering isn't a job that requires a full OS and a simple state machine doesn't provide many oportunities for hacking. If you need fancier services, you can provide those by means of a second-level firewall; I suspect that OpenBSD is a better answer for this than FreeBSD (it certainly tries hard to be!), but I have no personal experience with it.
Slashdot Mirror
As has been mentioned, there's a relatively small number of Cocoa and/or Objective-C programmers around. However, you don't need all that many people (maybe only one?), so I don't see this as a major constraint. In fact, I might suggest that you consider going into an even smaller niche. By choosing RubyCocoa (or its upcoming replacement, MacRuby), you might be able to create a framework that would encourage scientists to add their own code. A great deal of Open Source software is written by employees and released by the companies that employ them. This can offer real benefits to the company, in that they may get outside help in the project (eg, in development, documentation, maintenance, and testing). If the code base starts to attract outside attention, the company may be able to have the developer(s) take on some organizational tasks (herding cats :), as well.
Are the batteries in danger of catching fire when just sitting on a shelf, discharging, charging, or what? Inquiring minds need to know...
The Semantic Wiki page on Wikipedia is a good starting point. I have also written my own overview, including an annotated list of known efforts. Finally, the Semantic Wiki Interest Group is the best place to go to get involved or watch for new developments.
I am particularly interested in the possibility of augmenting wikis with mechanically-derived content. For example, there could be a Doxygen-style wiki page for each function and data structure in a system. Users could create new pages and/or annotate mechanically-generated pages. I am working on a specification for a wiki that could support such a system, but it's still quite speculative.
Or, more usefully, code each assignment up both ways and hand in both versions. You'll learn more about both architectures than you would from doing either one alone. And, if the professor is even a bit open-minded, you'll get extra credit for the work.
... but you'd still need to grab the Sendmail-specific macro files and such.
Thank you, doom, for the nice review. Thanks, as well, to timothy, Slashdot,
and the folks who have taken the time and effort to comment. I would like to
respond to a few points that have been raised here; I'll try to be brief (:-).
Printed and online documentation are not mutually-exclusive alternatives. I
use either or both, depending on my needs of the moment. Books have been
around for about two millenia, so it's not surprising that they work well for
certain purposes. It is obvious, however, that electronic access has its own
advantages.
An edited collection (whether printed or PDF) adds significant value over the
"raw" body of source documents. Documents must be located, evaluated, selected,
organized, and formatted. It's not accidental that doom found some novel tools
in our collections; part of our objective is to introduce readers to relevant
tools, whether they are part of a "standard distribution" or not.
Doom is quite correct about the economies of scale for small press runs. Our
books are demand-printed in very small lots. This keeps the investment small,
but the cost per item is about three times (!) that of offset printing. Only
the use of Internet-based sales allows us to offer reasonable pricing.
Like doom, I'd like to see a "Linux Browser", but my resources are limited and
I'm concentrating on other tasks right now. If some Linux-knowledgeable folks
want to help (e.g., by annotating directories and file system relationships),
I encourage them to get in touch.
Aside from DOSSIER, my current efforts are concentrated on creating a browser
that will run on a local system and provide integrated access to documentation
and system metadata. I'm writing a series on this for MacTech Magazine.
A final note on DOSSIER: send topic suggestions! If you'd like to see a volume
on a particular topic, let me know; I may be able to do something about it (:-).
I would very much like to see OSX ship with truss; in particular, I would like it to be the Solaris-style truss that can trace descendents of processes, etc. (The FreeBSD version is only a pale shadow of this.) Anyone who agrees with this wish might want to send a note to devbugs@apple.com, supporting Problem ID #3121601.
Previous distributions have included image files for the boot floppies; I assume that this one will, as well. Most modern PCs can boot directly from the CD-ROM, however.
My preference is to use a special-purpose box for the first-level firewall. Packet filtering isn't a job that requires a full OS and a simple state machine doesn't provide many oportunities for hacking. If you need fancier services, you can provide those by means of a second-level firewall; I suspect that OpenBSD is a better answer for this than FreeBSD (it certainly tries hard to be!), but I have no personal experience with it.