Slashdot Mirror

Lutec is another person involved in the Overunity engine quest.

Disclaimer: I follow this stuff off and on because it's almost as good as reading sci-fi novels.

I found This post which goes deeper into the discussion of the physics behind this machine which is WAY over my head. Can any of you slashdot electrical engineering gurus make sense out of it?

Could you post this one for us? Otherwise, I'll have to give back my MS in CS, since I don't know what the hell you're talking about.

Wouldn't a two-line program that could execute all possible programs make one excessively rich?

BringMeAFuckingSandwith(hotness=hot);

I didn't write the original article - I just posted it... But this exact thing hung me up, too.

These were the best articles that I found:

universes

And especially this email:

dovetailer

Essentially, have an infinite number of computers - and execute every 0-bit program (all 1 of them.) Then every 1-bit program (all 2 of them.) Then every 2-bit program (all 4 of them.) Etc. Eventually, you will have run every possible program - discounting timing, and hardware differences.

Also, if I'm not mistaken, this will find the shortest possible program that produces a given input.

In practice can you implement it? Not really. But it's an interesting theoretical argument - just like most of the CA stuff in the book...

I'm definitely making a living; even with health insurance and the sky-high cost of rent in Manhattan I'm still banking $1000/month or so. If you get a successful product the first thing you need to do is establish a savings account - that way if the next product's a bust you can still keep your head above water.

There's some recent discussion of this sort of thing on the Palm OS developer forum here,
and a slightly less enthusiastic account from one game developer here - clearly YMMV but there are certainly plenty of folks out there making a living on this.

I'm not a virologist, but as far as I remember, drug-directed approaches haven't been notably successful with attacking coronaviruses (ever hear that "medicine can't cure the common cold", anyone?) -- and to confuse things more, this one seems to be very atypical.
Also, from what I know about the anti-virals that have shown some efficacy against these type of SS-RNA viruses, they've been directed at nucleic acids, not at product-proteins. Ribavirin, which was initially hoped to be the "magic bullet" to stop SARS is a nucleoside analogue (purine? I don't remember). I haven't heard of an effective intervention that disrupts the protein envelope or synthesis.

There already is a cure for SARS, and it can be made in any hospital in the world for pennies.

It's called Colloidal Silver, and is made by electrolysis of pure silver wire in distilled water. Contrary to the scare tactics of the FDA, it will not give you Agyria.

Anyone who has tried it on a cut, and watched it heal the next day, or taken it at the first sign of a sore throat from a cold will tell you it works. It kills germs and viruses, and has little or no side effects.

SARS has been a major topic on Mike Devour's Silver List, one of the oldest and most respected web journals on colloidal silver. You can see the threads here:

http://escribe.com/health/thesilverlist/search.htm l?query=sars

Unfortunately, it is very difficult to persuade doctors to consider trying this on their patients, even though the current treatment is ineffective and makes the patients very ill.

There is a lot of hype on the web about colloidal silver and how to prepare it. But it is very simple to make, and it is truly the magic bullet everyone is looking for.

But you won't believe it unless you see how it works for yourself. Give it a try. All it takes is three 9V batteries, some 0.999 fine silver wire, and ordinary distilled water.

You might not end up with the best quality of colloidal silver, but it will work just fine.

Good Health to All,

Mike Monett

I suspect they're onto something too.. I like the idea that other universes aren't "over there" in the sense that you could travel from our universe to another one, but they're just in a different part of parameter space. The link to uncertainty is also fascinating to think about..i.e., when you see the outcome of a quantum experiment, maybe you don't collapse a wave function, or cause the universe to split, but merely find out which universe/program you're in.

I'll go ahead and link to the mailing list (the "everything list") where these guys occasionally post.. there are lots of interesting discussions. The archive is here.

There are two C/C++ development toolchains for Palm OS: Metrowerks CodeWarrior and what's called prc-tools, which is GCC, GDB, etc configured and patched as a cross-compiler for Palm OS. Some surveys suggest that each of them has about 50% of the market of Palm OS developers.

In the past, Palm OS SDKs have supported both toolchains: the 3.5 and 4.0 SDKs contained various linker (static) libraries in both CodeWarrior format and, for GCC, COFF format. The 4.0 SDK was even available from Palm as an RPM as well as a Unix tarball.

The 5.0 SDK's ReadMe has this to say about GCC:

This release of the SDK does not provide any support for the GCC development tools for Palm OS. GCC-specific components have not been updated for this release. SDK 4.0 Update 1 should be used for development under Linux and for using GCC on Windows.

I've also posted to palm-dev-forum about this.

In practice, it's not a show-stopper: the header files, which are all you really need to use the new 5.0 APIs (notably high density graphics and ARM subroutines), work fine with GCC. There's a bit of extra pain on Unix due to line termination issues and PalmSource's lack of familiarity with case-sensitive filesystems, but it's not too bad.

The GCC link libraries are entirely missing from the 5.0 SDK. This is unfortunate: while you can easily write an application without using them, the glue routines in one of the libraries makes compatibility with various versions of the OS easier, and PalmSource recommends their use.

Curiously, while the ReadMe says the SDK "does not provide any support for [GCC]", PalmSource were happy to fix showstopper GCC-usage-related bugs in the SDK's header files when they were pointed out to them during the SDK's beta period. Thus the note in the ReadMe is not really true.

All that's really missing is the GCC linker libraries and the Unix builds of the SDK. Because they were happy to fix those header bugs, because their Web pages still claim to "support prc-tools", and because of what various PalmSource employees have told me, I don't believe there's been any conscious decision (or conspiracy :-)) not to support GCC. I think the problem is that, even though the GCC library and Unix build scripts are still lying around from the 4.0 SDK, it's simply nobody's job to take responsibility for maintaining the scripts or for pressing the button that runs them.

It's all very disappointing: in all probability, there's no technical reason why the 5.0 SDK doesn't include GCC libraries or an easily installable Unix package, it's just that no-one cared enough to make them. It seems like it was always just Someone Else's Problem.

It's not too late to fix this. The company I work for and I know how to build these things (I wrote the scripts in a previous life :-)), and we've offered to help PalmSource build them several times. Hopefully they'll take us up on it, and make the users' lives easier.

Oh, disclaimer: I'm a prc-tools maintainer.

There are numerous researchers who have said that the multiverse (of which our universe is of course just a tiny part) has a total information content of essentially zero.

Those of you with too much time on your hands may enjoy Schmidhuber's 1996 paper, A Computer Scientist's View of Life, the Universe, and Everything.

And check out the Everything List archives too.

Here's a tip for those of you that use MLMs without archiving functionality: eScribe is a service that subscribes a bot to your mailing list and creates a searchable online archive. Very helpful.

Some of the Slashdot discussion speculated that RedHat might be interested in buying Be. Others noted legal difficulties in opening the BeOS source, but the company recently registered some thought provoking domain names, so they may be planning to try it anyway.

A very interesting comment noted that BeOS and Linux complement each other nicely, with BeOS a great desktop system for end users while Linux works best as a server. It's a good point. We may be expecting a lot of an OS to make it do well on everything from high end mainframes & servers to desktop PCs & handheld PDAs & even small embedded controllers. While it's impressive that Linux can do all this, maybe allowing complementary systems to have complementary roles might be a better idea.

As the head of RedHat (chief hat wearer? ;), what do you think of such speculation? Do you think that Linux could stand to gain by using BeOS technology? Would it be worthwhile to purchase Be &/or get involved in opening their software? If Sony's BeIA driven eVilla internet appliance catches on, having a stake in that contract could be very lucrative, but of course that's a gamble at this point.

Or do you feel that, as much as things may seem superficially similar, that there is too much dissonance between the Linux & BeOS worlds to make a merger worthwhile? Do you disagree that having separate systems for desktop & server could be a good idea? If you feel that there should be "one OS to rule them all," could (indeed, should)Linux take a lesson from Be about how to make a really good, easy, slick desktop frontend for the existing excellent but arcane back end that Linux provides?

In short, should these two be wedded and can such a marriage work?

The chemical you're talking about is solanine, a steroidal glycoalkaloid. As far as I can tell, it's not particularly found in people with schizophrenia, but it does cause psychotic symptoms.

From http://www.chuckiii.com/Reports/Psychology/schizop hrenia.shtml,

If potatoes are exposed to too much sunlight they produce an alkaloid called solanine. Solanine has the ability to induce gastro-intestinal problems and psychotic symptoms such as hallucinations. The idea that schizophrenia in Ireland is caused by the potato is not as far fetched as people might believe. Closer to home, a mental disease that afflicted southerners, pellagra, was caused solely from the lack of the vitamin niacin. This may lead us to believe that a mental disorder can be caused by too much exposure or lack of a certain type of food. Another possibility, is the amount of insecticides the Irish consume from the potato. At planting time farmers use high amounts of chemicals on their potatoes to protect them from insects. When an insect ingests the chemicals they are easily killed because the chemicals interfere with the normal functioning of the nervous system by disrupting the transmission of nerve impulses. If large doses of these chemicals have the same affect on humans as they do on insects this could answer the Irish dilemma. These toxins could be especially dangerous to women who are pregnant by damaging the fetal nerve tissue.

Although the aetiology is still unknown, numerous hypotheses have been postulated including dietetic factors but never has the potato (Solanum tuberosum L.) been suspected. However, a strong case can be advanced incriminating this widely, in fact almost universally, consumed vegetable tuber with its variable content of steroidal glycoalkaloids (SGAs) with known toxic action on both animals and humans, including possible teratogenic and cell membrane-damaging properties, as a very likely aetiological contender in most but possibly not all cases.

--

The work I am doing with the Linux Quality Database is inspired in large part by a desire to bring this kind of quality to Open Source and Free Software systems. I use Linux on a daily basis in my own work now but honestly my experience of it wears me down and I fell so... refreshed whenever I restart into the BeOS.

But it is clear to me that Be, Inc.'s troubles are due to lack of wisdom and commitment among its management despite the best efforts of its engineers. From the start, Be made very little effort to market to the public, even though anyone who ever tried the BeOS immediately liked it and usually wanted to run it on their machine.

After a while it became clear that Be had problems keeping its commitments to its developers. I lost out on a lot of evenings and weekends spent developing a product that didn't sell well when I could have developed another product for the Mac OS - I was well into one for the Mac but gave it up for the BeOS. The investors who funded BeatWare and Adamation lost millions of dollars on their BeOS development efforts; the companies were only saved when they ported their products to the Mac OS and Windows.

Read about my observations about the difficulties that a number of companies have had surviving in the turbulent world of High-Tech, including my advice as to why business partnerships with Be are best avoided:

• The Valley is a Harsh Mistress

• Freeing the Developer from OS Vendor Shackles

• Some of Us Work for a Living

Be dug their own grave. If someone comes to their rescue with new funding, I'd like to suggest that the package include a new top-level management team with a mandate to shake things up. Firing the sales-prevention team would help.

I'll be sad if the BeOS dies and I hope they do open source it. It is likely that it uses licensed technology so that they could not legally open source the whole thing; let us hope they take the route netscape did and remove the proprietary parts and allow the open sourcing of the rest, rather than allowing it to die.

Mike

http://www.escribe.com/software/beusertalk/m40678. html

Also, I don't think some guy that might work for Be saying it's not going to happen means anything.

Also, they might only open up parts of the code that they can without pissing off others. There's still hope.
--

Oooo...I guess I don't know what I'm talking about then, do I?

How about a link? The "Re: Linux ports" thread on Sun, 7 Jan 2001 is of interest.

It starts with "Once upon a time a nice guy ported the Linux 3c509 driver to BeOS. But a GPL fanatic blamed him for violating GPL and the author was driven into closing his door." Another post says "The file is still available though" and gives a link. Then follows up with "*hush -- don't tell*." The original author of the driver posted "Yes I was told, that I had to delete my link to the driverarchive. I did this. I removed the link, but maybe I've forgotten to delete the archive itself. So if some people are "searching" and "trying" a little bit around my site, and they will find the archive, there is nothing I can do..... :-) I think Internet is a really unsafe place :-)"

Sounds to me like "some people on BeDevTalk are trying to figure out way to circumvent the GPL to get a 3com driver going."
I don't need to "trash an alternative (BeOS) OS" when Be, the developer community, and the user community are doing a fine job of it themselves!
There's nothing worse than a reformed smoker...unless it's a BeOS developer whose been screwed over one too many times!

I'll probably regret posting this, and doing so goes against the advice of my fellow co-workers, but there's a very good (and oft-stated) reason why BeOS in general and Net+ in particular cannot be open-sourced: we have legally binding contracts with the makers of proprietary technologies we use which forbid us from releasing their code into the public domain. Even mentioning making BeOS or Net+ open source sends our corporate counsel into hysterics.

It ain't gonna happen.

So, this is another case of nVidiaism. They have contracts with other people which disallow them from opening the source. Stop bickering about it. Stop dreaming about it. It just ain't gonna happen.

Even if it could happen, I wouldn't want it to. All you linux zealots would dive in and try and start 'fixing' things. Then we'd get a "microkernel" as large as that monolithic piece of shit linux 2.4.0.

-G
BeNews Editor

Linux is only free if your time is of no value

I don't think so.
The idea of creating a "unique"(*) hash based on track length is very old.

There's an Apple tech note on it. I can't find the Tech Note itself, but the same format is used in BeOS, and there's a posting about it here.

(*) Since it is impossible to positively identify a CD based on track length (there is no requirement for uniqueness there) does that invalidate the patent? Aren't patents on the impossible automatically invalid?

--

I wrote a web page a long time ago about why I quit Mac programming and took up the BeOS instead

But after too many years of too many broken promises from Be, Inc. I spoke up one too many times on BeDevTalk and got forcibly unsubscribed after being one of Be's most loyal developers, and winning an award for shipping one of the few actual commercial BeOS applications.

I haven't had any first-hand experience with Microsoft but I have heard many horror stories that didn't make it into the Microsoft/DoJ antitrust trial. Remember that one of DoJ's problems was getting executives to testify publicly - but there's no shortage of developers willing to confide privataly about how Microsoft has screwed them.

One very public example is Stacker Software. They invented filesystem compression. Microsoft offerred to purchase Stacker, and examined their source code under nondisclosure while doing due diligence. Then they canceled the acquisition and came out with their own implementation of filesystem compression. Stacker sued and won over $100 million.

For the past year I have been working with the ZooLib cross-platform application framework. It allows you to write a single set of C++ sources and build native executables for Mac OS, Windows, BeOS and POSIX flavors that provide XWindows (such as Linux).

I believe ZooLib represents one important part of a strategy for freeing ourselves from these broken promises.

Please read why I think ZooLib is good for the community

Note that I include quotes from Judge Thomas Penfield Jackson, who presided over the antitrust trial, one how Microsoft felt that it was so important to put a stop to cross-platform API's that it broke the law to interfere with their widespread use.

Jackson makes the same observation in his rulings that I have noticed in the past, that API and OS vendors work very hard to get developers to code to the native API rather than using a portability layer, as doing so locks the developer into the platform.

Michael D. Crawford
GoingWare Inc

The result is that it is very difficult for the developer to bring the product out on a competing platform, and it discourages users from moving to a different OS when they feel the vendor isn't serving their needs (because they can't get the solutions to their problems).

If the developer doesn't want to deal with the OS vendor anymore, he's really got a problem - either suffer under the vendor's thumb, or make a great deal of personal sacrifice to move to a different operating system.

I was sick of Apple so I wrote I'm worried about my future. That's why I'm a Be developer.

And in fact I shipped (and still do support) on of the first commercial applications for the BeOS, Spellswell from Working Software.

Nothing Be ever did made any sense, and while there are individuals at the company that I regard highly, on the whole I felt the company to be uniquely unresponsive and incompetent.

And just when they were showing some promise of shipping enough BeOS installations that I had some hope of making more than the measly couple hundred bucks I'd earned in royalties in the three years I'd been working on Spellswell, they announced a "change in focus" and said they weren't going to support the desktop anymore, except for the extent necessary to use it as a development platform for their new Strategy Du Jour, Internet Appliances.

After I posted on BeDevTalk that Some of Us Work for a Living, the moderator told me he was fed up with a developer who was trying to discuss business issues of concern to Be's third-party developers on Be's third-party developer mailing list. That was my last message to bedevtalk - he unsubscribed me.

I've been working on a really challenging C++ application for a few months, and after reading C++ Answers with Bjarne Stoustrup I got excited about really digging into the basics of programming - but from the perspective of a developer with 13 years of work experience and a lot of shipping products.

I bought a few books, mostly on C++ and also hit some websites and newsgroups, and I became a much better programmer as a result. And I really felt that I did better to spend my time on core architectural and language issues rather than dealing with OS-specific nits or tool issues. And so I wrote Study Fundamentals, Not APIs, Tools or OSes.

So this brings me back to being used by operating systems vendors to serve their material needs at my expense and the cost of much personal pain. If you become a better programmer by learning the basics better, to can fluidly go from OS to OS without much of a learning curve.

But there's the problem that you have to use some API to code your application to, and while Java claims to be "platform-independent" it is really a proprietary platform in itself - just try making use of platform-specific code in a Java application, yes you can do it with the Java Native Interface but it is difficult and an assault on the Java developer's senses to write a dll in C or C++ to load into the runtime.

So what you really need is a cross-platform application framework that you can write in with a language such as C++, that comes preconfigured with easy-to-use preprocessor symbols so you can drop into OS-specific code at your whim, and will compile from a single sourcebase to native machine code for multiple operating systems.

Funny that, since December '99 I've been writing a multithreaded special-purpose graphics editor that is also an HTTP client with just such a cross-platform application framework. I can develop on Mac or Windows as the need suits me and switch back and forth at a moments notice (especially now that I've got filesharing between my machines). My client only asked for Mac and Windows versions but I could port to BeOS or Linux in a few days. The framework is called ZooLib.

It was written by my friend Andrew Green of The Electric Magic Company, originally to insulate himself from Apple's API nonsense. (Do you remember when all progress on developer tools at Apple and Symantec stopped while they went off into the sunset to develop Bedrock, itself a cross-platform application framework and an immense investment of time and money - and then abandoned it? If it hadn't been for then-tiny Metrowerks Apple would have gone out of business after shipping the first PowerPC Macs, because there would have been no native PPC compilers.)

He felt that if he could code to his own layer and Apple changed their API, he'd just have to reimplement the OS-specific layer and he'd be working again. But then a little more work and he'd be cross-platform...

If you click that link today you'll just get a placeholder page. But just wait a few days...

(For practical reasons the source itself, mailing lists and so on will be provided at http://zoolib.sourceforge.net/ once it's released.)

While ZooLib is to be newly released to the public it is not new code. It has been in use in commercial products for about five years - and in development in my own since last December. Part of why Andy gave me the code and I've been working with it is to give him meaningful architectural feedback and detailed bug reports so he can prepare it for public release.

I've been urging Andy to release the source as-is for a couple of years but his standards are incredibly high for a programmer. Andy's code doesn't just work, it is correct.

Andy spares no effort or time to fix the smallest problems (this is especially important in multithreaded code - think about reference counted smart pointers that are operated on by different threads, as you can do with Zoolib), and part of why he's been delaying the release is to improve the overall architecture.

For more details, including relevant quotes from Judge Thomas Penfield Jackson's Findings of Fact and Final Judgement discussing why Microsoft felt it was more important than anything to suppress cross-platform API's, such as Netscape plug-ins, Java, Intel Native Signal Processing, Lotus Notes, Apple Quicktime (runs on Windows too!) and RealNetworks' multimedia technology, please read my early draft of:

The Cross-Platform Manifesto

Thank you for your attention.

Regards,

While they probably have hardware compressors and fancy algorithms, if you can use any PC you can use a public open-source compressor and just get a bigger hard drive.

It really wouldn't be that hard.

You'd probably get better realtime media streaming performance in the BeOS but then there'd be a chokepoint and I don't think the company is deserving of support by third party developers anymore.

Better to give people yet another reason to use Linux.

Are there any readily available hardware video compressor boards that aren't too expensive and have open source linux drivers?

I am one of the few developers to actually ship a commercial application, Spellswell from Working Software. I've kept Spellswell actively maintained over a couple of years, it is now at version 1.0.5.

So I didn't appreciate it when Be announced it was dropping active support for the desktop and "refocusing" on Internet Appliances.

Now promoting the system for Internet appliances is fine, but Be had spent years promoting its system as a platform for multimedia content creation, and in my view it is the best platform for desktop software. Check out, for instance, Gobe Software's Gobe Productive, one of the best integrated applications available.

While Be still has a desktop operating system and gives it away for free, it has made it clear that there will be no further desktop-specific development for the operating system; if a feature or bug-fix makes it into the system it will be because it is needed for Internet Appliances, and not because it is needed for the desktop.

I repeatedly tried to bring this failure to live up to its commitments on bedevtalk and beusertalk and while other professional developers supported my position, I was constantly shot down by the hobbyists and Be's own employees.

Finally I tried to point out the error of their ways in some detail by posting this to bedevtalk:

Some of Use Work For a Living

in which I pointed out that the appropriate response to criticism from developers like me would be for Be employees who subscribe to the list to communicate our concerns to senior management.

How did Be respond?

Tom Maddox, listmaster@be.com, unsubscribed me and asked the list if they'd prefer to have the entire list moderated.

Before you decide to devote time and energy to developing BeOS software, I ask you to consider whether you wish to take the risk to invest your time and money in a system that is only available from a company that has not only proved it cannot keep its commitments, it has stated repeatedly it does not want its dishonesty pointed out to it and will actively work to censor those who would work to correct its behaviour.

One of the reasons I am working to reorient my consulting business to take primarily Linux work is that I feel it is a mistake for any third party software developer to depend on any API, particularly an operating system, that they do not have the source code to.

If you feel you must support a closed-source operating system or API, I urge you to require the API vendor to sign a contract guaranteeing they will support the API forever - both in terms of maintainence and marketing - or else they will reimburse you for your lost revenue and opportunity cost if they fail to live up to their commitments.

I had much the same experience with Apple Computer which is why I became a BeOS developer.

BTW - My fiance told me that being unsubscribed from bedevtalk is like being kicked off the design committee for the Edsel. It's a beautiful OS and the engineering quality is excellent, but the sales prevention team there, uh, I mean the management, is determined to do everything they can to prevent the business from succeeding.

Perhaps Internet Appliances are a good idea, but after the galling lack of marketing cluefulness shown when they were on the desktop I seriously doubt they can get it together to succeed in the Internet Appliance arena either.

If you are an Internet Appliance manufacturer, think about whether you want to make your livelihood dependent on a company with a proven track record of failing to live up to its commitments. Consider that in many was QNX is a better OS for appliance and you can get a developer kit for free.

I don't think Linux is a very good platform either for the desktop or Internet Appliances but because it is free software that problem is capable of being addressed.

Tilting at Windmills for a Better Tomorrow

I am one of the few developers to actually ship a commercial application, Spellswell from Working Software. I've kept Spellswell actively maintained over a couple of years, it is now at version 1.0.5.

So I didn't appreciate it when Be announced it was dropping active support for the desktop and "refocusing" on Internet Appliances.

Now promoting the system for Internet appliances is fine, but Be had spent years promoting its system as a platform for multimedia content creation, and in my view it is the best platform for desktop software. Check out, for instance, Gobe Software's Gobe Productive, one of the best integrated applications available.

While Be still has a desktop operating system and gives it away for free, it has made it clear that there will be no further desktop-specific development for the operating system; if a feature or bug-fix makes it into the system it will be because it is needed for Internet Appliances, and not because it is needed for the desktop.

I repeatedly tried to bring this failure to live up to its commitments on bedevtalk and beusertalk and while other professional developers supported my position, I was constantly shot down by the hobbyists and Be's own employees.

Finally I tried to point out the error of their ways in some detail by posting this to bedevtalk:

Some of Use Work For a Living

in which I pointed out that the appropriate response to criticism from developers like me would be for Be employees who subscribe to the list to communicate our concerns to senior management.

How did Be respond?

Tom Maddox, listmaster@be.com, unsubscribed me and asked the list if they'd prefer to have the entire list moderated.

Before you decide to devote time and energy to developing BeOS software, I ask you to consider whether you wish to take the risk to invest your time and money in a system that is only available from a company that has not only proved it cannot keep its commitments, it has stated repeatedly it does not want its dishonesty pointed out to it and will actively work to censor those who would work to correct its behaviour.

One of the reasons I am working to reorient my consulting business to take primarily Linux work is that I feel it is a mistake for any third party software developer to depend on any API, particularly an operating system, that they do not have the source code to.

If you feel you must support a closed-source operating system or API, I urge you to require the API vendor to sign a contract guaranteeing they will support the API forever - both in terms of maintainence and marketing - or else they will reimburse you for your lost revenue and opportunity cost if they fail to live up to their commitments.

I had much the same experience with Apple Computer which is why I became a BeOS developer.

BTW - My fiance told me that being unsubscribed from bedevtalk is like being kicked off the design committee for the Edsel. It's a beautiful OS and the engineering quality is excellent, but the sales prevention team there, uh, I mean the management, is determined to do everything they can to prevent the business from succeeding.

Perhaps Internet Appliances are a good idea, but after the galling lack of marketing cluefulness shown when they were on the desktop I seriously doubt they can get it together to succeed in the Internet Appliance arena either.

If you are an Internet Appliance manufacturer, think about whether you want to make your livelihood dependent on a company with a proven track record of failing to live up to its commitments. Consider that in many was QNX is a better OS for appliance and you can get a developer kit for free.

I don't think Linux is a very good platform either for the desktop or Internet Appliances but because it is free software that problem is capable of being addressed.

Tilting at Windmills for a Better Tomorrow

I am one of the few developers to actually ship a commercial application, Spellswell from Working Software. I've kept Spellswell actively maintained over a couple of years, it is now at version 1.0.5.

So I didn't appreciate it when Be announced it was dropping active support for the desktop and "refocusing" on Internet Appliances.

Now promoting the system for Internet appliances is fine, but Be had spent years promoting its system as a platform for multimedia content creation, and in my view it is the best platform for desktop software. Check out, for instance, Gobe Software's Gobe Productive, one of the best integrated applications available.

While Be still has a desktop operating system and gives it away for free, it has made it clear that there will be no further desktop-specific development for the operating system; if a feature or bug-fix makes it into the system it will be because it is needed for Internet Appliances, and not because it is needed for the desktop.

I repeatedly tried to bring this failure to live up to its commitments on bedevtalk and beusertalk and while other professional developers supported my position, I was constantly shot down by the hobbyists and Be's own employees.

Finally I tried to point out the error of their ways in some detail by posting this to bedevtalk:

Some of Use Work For a Living

in which I pointed out that the appropriate response to criticism from developers like me would be for Be employees who subscribe to the list to communicate our concerns to senior management.

How did Be respond?

Tom Maddox, listmaster@be.com, unsubscribed me and asked the list if they'd prefer to have the entire list moderated.

Before you decide to devote time and energy to developing BeOS software, I ask you to consider whether you wish to take the risk to invest your time and money in a system that is only available from a company that has not only proved it cannot keep its commitments, it has stated repeatedly it does not want its dishonesty pointed out to it and will actively work to censor those who would work to correct its behaviour.

One of the reasons I am working to reorient my consulting business to take primarily Linux work is that I feel it is a mistake for any third party software developer to depend on any API, particularly an operating system, that they do not have the source code to.

If you feel you must support a closed-source operating system or API, I urge you to require the API vendor to sign a contract guaranteeing they will support the API forever - both in terms of maintainence and marketing - or else they will reimburse you for your lost revenue and opportunity cost if they fail to live up to their commitments.

I had much the same experience with Apple Computer which is why I became a BeOS developer.

BTW - My fiance told me that being unsubscribed from bedevtalk is like being kicked off the design committee for the Edsel. It's a beautiful OS and the engineering quality is excellent, but the sales prevention team there, uh, I mean the management, is determined to do everything they can to prevent the business from succeeding.

Perhaps Internet Appliances are a good idea, but after the galling lack of marketing cluefulness shown when they were on the desktop I seriously doubt they can get it together to succeed in the Internet Appliance arena either.

If you are an Internet Appliance manufacturer, think about whether you want to make your livelihood dependent on a company with a proven track record of failing to live up to its commitments. Consider that in many was QNX is a better OS for appliance and you can get a developer kit for free.

I don't think Linux is a very good platform either for the desktop or Internet Appliances but because it is free software that problem is capable of being addressed.

Tilting at Windmills for a Better Tomorrow

I am one of the few developers to actually ship a commercial application, Spellswell from Working Software. I've kept Spellswell actively maintained over a couple of years, it is now at version 1.0.5.

So I didn't appreciate it when Be announced it was dropping active support for the desktop and "refocusing" on Internet Appliances.

Now promoting the system for Internet appliances is fine, but Be had spent years promoting its system as a platform for multimedia content creation, and in my view it is the best platform for desktop software. Check out, for instance, Gobe Software's Gobe Productive, one of the best integrated applications available.

While Be still has a desktop operating system and gives it away for free, it has made it clear that there will be no further desktop-specific development for the operating system; if a feature or bug-fix makes it into the system it will be because it is needed for Internet Appliances, and not because it is needed for the desktop.

I repeatedly tried to bring this failure to live up to its commitments on bedevtalk and beusertalk and while other professional developers supported my position, I was constantly shot down by the hobbyists and Be's own employees.

Finally I tried to point out the error of their ways in some detail by posting this to bedevtalk:

Some of Use Work For a Living

in which I pointed out that the appropriate response to criticism from developers like me would be for Be employees who subscribe to the list to communicate our concerns to senior management.

How did Be respond?

Tom Maddox, listmaster@be.com, unsubscribed me and asked the list if they'd prefer to have the entire list moderated.

Before you decide to devote time and energy to developing BeOS software, I ask you to consider whether you wish to take the risk to invest your time and money in a system that is only available from a company that has not only proved it cannot keep its commitments, it has stated repeatedly it does not want its dishonesty pointed out to it and will actively work to censor those who would work to correct its behaviour.

One of the reasons I am working to reorient my consulting business to take primarily Linux work is that I feel it is a mistake for any third party software developer to depend on any API, particularly an operating system, that they do not have the source code to.

If you feel you must support a closed-source operating system or API, I urge you to require the API vendor to sign a contract guaranteeing they will support the API forever - both in terms of maintainence and marketing - or else they will reimburse you for your lost revenue and opportunity cost if they fail to live up to their commitments.

I had much the same experience with Apple Computer which is why I became a BeOS developer.

BTW - My fiance told me that being unsubscribed from bedevtalk is like being kicked off the design committee for the Edsel. It's a beautiful OS and the engineering quality is excellent, but the sales prevention team there, uh, I mean the management, is determined to do everything they can to prevent the business from succeeding.

Perhaps Internet Appliances are a good idea, but after the galling lack of marketing cluefulness shown when they were on the desktop I seriously doubt they can get it together to succeed in the Internet Appliance arena either.

If you are an Internet Appliance manufacturer, think about whether you want to make your livelihood dependent on a company with a proven track record of failing to live up to its commitments. Consider that in many was QNX is a better OS for appliance and you can get a developer kit for free.

I don't think Linux is a very good platform either for the desktop or Internet Appliances but because it is free software that problem is capable of being addressed.

Tilting at Windmills for a Better Tomorrow

There are several issues here: peer review, architecture, algorithm and implementation.

Peer Review: At each step in the process (architecture, algorithm, and implementation), you should publish your ideas for criticism by experts. slashdot, Advogato, the Cypherpunks mailing list, sci.crypt, and the Crypto++ mailing list might (or might not) be good places to find such people.

Architecture: You should do a public key architecture where every participant has a public/private key pair and the public keys are used to sign and encrypt symmetric keys that are then used for encryption and authentication of messages. There are three feasible architectures for public key distribution. You have to choose one based upon your threat model. Almost all realistic threat models should be handled using the first option: "opportunistic public key distribution". If you don't have a threat model in mind at all then you might as well use the first option. If you do have a threat model which precludes using the first option then I'd like to hear about it -- you must be doing something very interesting indeed.

• Option one: "opportunistic public key distribution". The first time any pair of people talk to one another, they exchange public keys in an un-authenticated exchange. (Also: you could just do Diffie-Hellman key generation here.) After that, they remember each other's public keys for future use. This is susceptible to an active attack (a "Man In The Middle Attack"), during the first step (though not afterwards). However the cost to the attacker of executing a MITM attack is probably far more than the payoff. This depends on your threat model.
• Option two: make it the user's problem; Each user decides whether to use a given key to talk to another user or not. This is the user interface nightmare that single-handedly prevented strong crypto from becoming standard in e-mail, but for a few applications it might be the right thing.
• Option three: hardcoded; Generate key pairs yourself and include them in the application. For example if you are going to have a single central server in your system which you operate then you can generate a key pair for it, put the secret key on the server, and put a copy of the public key into each copy of the client (e.g. include the public key hardcoded into the client source code). This doesn't work as well if you want to distribute copies of your server for other people to operate, but refer to "Option one"...

Algorithm: You probably just want Triple-DES and RSA (after September of this year, when RSA becomes free of patents) or else Triple-DES and Diffie-Hellman. It should be easy to switch to a different symmetric cipher later after the new ones have been peer-reviewed and tried by fire, but for starters you want the old standbys that have already withstood the test of time. They will be fast enough for you at first and if you need more speed later you can switch.

Implementation: Your first choice should be to use an extant implementation. Don't try to implement it yourself no matter how simple it looks. Satan's Computer is deceptively subtle to people who are used to hacking Murphy's Computer.

I prefer Wei Dai's Crypto++ library, but that is because I'm doing complex non-standard crypto tricks. If you just want simple "encrypt/authenticate a stream" functionality then use a TLS implementation like OpenSSL. By the way, if anyone wants to make Python wrappers for Crypto++ (possibly with the aid of Swig) then I would love to hear about it!

Okay that's my advice. Specific pitfalls to avoid are: skipping peer-review, trying to design a generalized perfect public key architecture to handle all possible threat models, using a newfangled or non-standard algorithm ("In open source hackery, newfangled is good. In crypto, not."), and implementing it yourself instead of using a library.

Please direct all flames and accolades to: zooko@schowto.mad-scientist.com

[the ESS 1868 chipset]. It pains me to throw away a perfectly good full-duplex 16-bit sound card and go buy SBLives.

(the Be Adventure was also worth reading).

[the ESS 1868 chipset]. It pains me to throw away a perfectly good full-duplex 16-bit sound card and go buy SBLives.

(the Be Adventure was also worth reading).

[the ESS 1868 chipset]. It pains me to throw away a perfectly good full-duplex 16-bit sound card and go buy SBLives.

(the Be Adventure was also worth reading).

It's already in progress as per John Carmac's 5-19-99 plan file:

I know SMP is a que for all the BeOS folks to ask about ports, so I'm going to head that off: Be has all the code for Q3 (and Q2, for that matter), and a version of Q3test should be available by the time they ship a release OS with OpenGL hardware acceleration.

A quote from Andrew Kimpton, the fellow doing the BeOS port (from an email to the BeUserTalk Mailing list 5-28-99):

On the matter of release dates it's important to remember that what has currently been released for Linux, Windows, MacOS et al is Q3Test this NOT Quake 3: Arena. It's a test program to explore hardware compatibility issues and the like. The final release date for Quake 3:Arena has not been set (to the best of my knowledge) however I believe it's expected it to be later in the year perhaps late Summer/Fall or there abouts. By which time Genki will have been released and undoubtedly installed in many a system.

Quake 2 has been released (gotta have a 3dfx video card though). Genki's shiped but the buzz is Q3 won't be released until Be's OpenGL supports multitexturing.

I guess tuning makes all the difference.