There was a 128MB stick of SDRAM I had once that killed every motherboard I ever put it in. Lost three before I figured it out, and after that I kept it around just to kill old boards.
Yeah, this is what I get for posting when I should be sleeping.:-)
You can run SLIP just fine on an 11/20.
I forgot about SLIP. So yes, it could be done on the 11/20. Is there any software that implements HTTP/TCP/IP/SLIP on the 11/20? If not, it sounds like an idea for a future project (I have an 11/20).
But it was very common to add BA11 expansion boxes of various sorts to the 11/20.
But wouldn't they be BA11-Es with the same wierd backplanes as the 11/20 chassis? Or did they have BA11-Ks in 1970?
I'm not sure what you mean by timing issues, as the 11/20 uses standard Unibus timing.
I was worried about what assumptions the ethernet adapter might make about the speed at which incoming data could the processed by the memory or CPU, since the DEUNA/DELUA were introduced several PDP-11 generations after the 11/20. Maybe the core cycle time or ISR processing time are too long. I just don't know enough about the UNIBUS or the DEUNA/DELUA to pass definite judgement.
It's entirely possible to run Unix on several models that predate the 11/70, including the 11/40 and 11/45.
Of course, but most unices with TCP/IP will not fit on a 11/40 or 11/45.
The PDP-11/70 isn't that difficult to run and maintain. But it is rather large (physically).
It also has the best front panel.:-)
The BA23 is a terrible case. Aside from having only two drive bays and an anemic power supply, it is difficult to run cabling for options, especially if you want disks other than the RD5x. Also, many of the BA23s available surplus have not had the power supply cable retrofit, and the old power supply cables are prone to burning up. If you have a choice, get the BA123 "World Box" instead. It's a much nicer case, and will work with the 11/23, 11/53, 11/83, and 11/93 processors.
If you've got the newer power harness and just want to run a RD5x and a RX50, then the BA23 works well. It makes a nice, small, easy PDP for the entry level. I know there are at least 11/23, 11/73, and 11/83 processors that you can put in a BA23. Plus, an average person can pick up and carry a BA23, and a full BA23 can be shipped UPS with minimal hassle.
The first PDP-11, the 11/20, was introduced in 1970. It supported up to 28KW (that's 56KB, for the uninitiated) of memory and could multitask. I'm sure that some sort of web browser could be implemented within those constraints. However, I don't think there are any UNIBUS (a PDP-11 bus) ethernet adapters compatible with the 11/20's strange backplanes. You could theoretically put a DEUNA or DELUA ethernet adapter in an BA11-K expansion box with more regular backplanes, but both components are out of period for the 11/20 (especially the DELUA!). Timing issues could also be a problem.
The earliest -11 you can run a web browser on today is probably the 11/70, released (IIRC) in 1975. You can install 2.11BSD on an 11/70 with enough memory, and your browser can run from within that. If there's no browser, then there's at least telnet to port 80.:-)
PDP-11/70s are difficult to run and maintain. I would suggest that the intrepid reader use a 11/44 instead. Nearly 100% software-compatible with the 11/70 but not quite as huge and not quite as expensive to obtain, the 11/44 is a good collector machine. If you get one, read up about its power supply. If you touch the wrong places (and the're easy to touch), you WILL be killed!
Less intrepid but still interested readers shoudl go with a MicroPDP-11/73 in a BA23 tower. They look like skinny tower PCs and are relatively uncomplicated.
Dropping X11 would be a HUGE mistake. X11 as a system is far more flexible than the gui system of windows
You are assuming that the X11 replacement would be Windows-ish. I don't think that's a safe assumption. What needs to be done is a refactoring of the idea of X11. Drop the old and busted design and create a new hotness one, using things we've learned since then.
What causes slowness more than X11 itself, is the programs running on top of it
Yes, X11 does nothing very fast if you don't run any programs in it.
While I hate species hubris more, I still greatly despise species anti-hubris as exemplified by your post. You are correct in the observation that many biotechnological developments have adverse side-effects, but you are dead wrong in implying that the adversity is sufficiently severe to negate the benefits obtained through the sacrifice. I'll attack your statements point by point:
We introduce species into an environment as pest control, and they become new, toughter pests.
And then we create better pest control. This is a cyclical process. There's nothing wrong with that. Computer security is similar. When the white hats plug a hole, the black hats will find another (new, tougher) one. Yet the necessity of hole-plugging is virtually undebated.
We pop pills with the latest and greatest chemicals only to discover they cause deaths in people with a previously unknown genetic trait.
Would you rather us not have pills, or more exactly, the drugs contained in the pills? I personally find it discomforting to think of life without Tylenol, Ex-Lax, Benadryl, or antibiotics. The truth is that the number of deaths due to bad pills is negligible in comparison to the number of deaths that are prevented with good pills.
We split the atom, and proceed to use it to threaten our own existence.
We have also proceeded to use the atom to (relatively) cleanly generate electricity and to greatly advance physics. The Manhattan Project created the phenomenon of "big science",
which now enables billions of dollars to be funneled into scientific endeavors. Soon, our spacecraft may propel themselves with atomic engines.
We eradicate diseases ( Smallpox, the most virulent strains of Influenza, etc ), but this simply means that is any one of them were ro resurge, it would have the same deadly effect as the Black Plague due to no resistance in the population.
Are you seriously suggesting that diseases such as smallpox should not have been eradicated? If so, you should become more acquainted with history, specifically the history of disease. Perhaps we should invent a time machine and send you back to 18th century urban Europe. Duh: disease used to be a major problem. If resistance has decreased, it is most certainly a fair price to pay for significantly improved quality of life and life expectancy.
The fact that "Superman" is in a wheelchair only serves to remind us how foolish we are as a race.
ICYHN, Superman was a fictional character.
While I don't believe that we'll ever perfectly know how to know things and thus not occasially shoot ourselves in the foot, I do believe that our epistomological self-consciousness is increasing.
ACHTUNG! Alles Lookenspeepers! Das computermachinen ist nicht fuer gefingerpoken und mittengraben...
The above should be enough to get you started. Remember, Google is your friend. Then, when you are ready for some real blinkenlights (hint: your hub/switch is not enough), get yourself a PDP-11.
Anyone remember when Caldera swiched all the really old UNIX releases to a BSD-style license last year? Now we know what they were really thinking when they wrote the specific exclusion for SysIII and SysV. Here's what we saw back then:
Caldera
240 West Center Street
Orem, Utah 84057
801-765-4999 Fax 801-765-4481
January 23, 2002
Dear UNIX enthusiasts,
Caldera International, Inc. hereby grants a fee free license that includes the rights use, modify and distribute this named
source code, including creating derived binary products created from the source code. The source code for which Caldera
International, Inc. grants rights are limited to the following UNIX Operating Systems that operate on the 16-Bit PDP-11
CPU and early versions of the 32-Bit UNIX Operating System, with specific exclusion of UNIX System III and UNIX
System V and successor operating systems:
32-bit 32V UNIX
16 bit UNIX Versions 1, 2, 3, 4, 5, 6, 7
Caldera International, Inc. makes no guarantees or commitments that any source code is available from Caldera
International, Inc.
The following copyright notice applies to the source code files for which this license is granted.
Copyright(C) Caldera International Inc. 2001-2002. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
following conditions are met:
Redistributions of source code and documentation must retain the above copyright notice, this list of conditions and the
following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the distribution.
All advertising materials mentioning features or use of this software must display the following acknowledgement:
This product includes software developed or owned by Caldera International, Inc.
Neither the name of Caldera International, Inc. nor the names of other contributors may be used to endorse or promote
products derived from this software without specific prior written permission.
USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA INTERNATIONAL, INC.
AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE FOR
ANY DIRECT, INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
Very truly yours,
/signed/ Bill Broderick
Bill Broderick
Director, Licensing Services
* UNIX is a registered trademark of The Open Group in the US and other countries.
It seems like every proposal I hear for a solution to the spam problem concludes with "If enough people did this, then...". That highlights the main problem with tarpits and similar mechanisms that only work when used en masse. Guess what? There's not a icicle's chance in hell of there being enough people to make any of these schemes work. As long as Johnny Sixpack and Patricia Partygirl (who probably outnumber the geeks at this point) keep using their spam-magnet Hotmail accounts and engage in activities conducive to having their addies harvested, spam will survive.
Personally, the spam solution I like the best is to have procmail+formail or some other tool sitting on your mail server and making unknown senders go through a confirmation step. It doesn't work for everyone (for instance, people expecting email replies to résumés! NAGI...), but if it works for you it tends to work very well. It inconveniences everyone else, but hey, everyone else is not me. I can whitelist all the people I truly care about.
Either that or we should throw out SMTP, email RFCs, sendmail, etc. and build a spam-free system from the ground up. Yeah, right.
I was actually referring to the BSD mascot: a red daemon holding a big fork. The mascot itself refers to the fork() system call, which was one of Unix's wow-cool features back in the day.
Just don't watch the last two episodes, or end of eva. They make the whole series suck
Well, you need to watch something to tie everything together; all the loose ends left by just watching up to episode 24 would be unbearable. Any curious human would want more. And I don't think it is too farfetched to think that End of Evangelion provides the better ending of the two. So I'm must disagree and recommend that the reader at least watch EoE.
It was a stupid idea, anyway
on
MicroBSD Is No More
·
· Score: 3, Interesting
MicroBSD was an embedded-Linux-like approach at making a smaller BSD. Now I'm not trying to sound high and mighty here; I'm merely trying to point out factual differences between the Linux way and the BSD way. Linux and BSD are both great, but they are different from each other.
One of the distinctive things to note about Linux is that its code base is rather distributed. The kernel comes from here, cc comes from there, and the $other_thing comes from somewhere else. The boundary between the base Linux OS and additionally-installed software is sometimes not very defined. The BSDs' code bases are organized differently, each BSD having its own (mostly) centralized, integrated code repository and build system. BSDs do include some "contrib" software (e.g. Less or OpenSSH) that comes from other sources, but contrib releases are still merged and adapted into the main repository. BSDs have a very definite boundary between what is the base OS and what is a third-party package, or "port".
Either way is a great way to structure an OS code base. However, the organizational differences do have some effect upon what is the best way to make a small or embedded version of the OS. With Linux, it's good to fork off a separate distribution, so that packages and a build system can be most effectively engineered. Granted, I never looked at MicroBSD closely (so I could be totally wrong), but that seems to be the approach they took. With BSD, however, it just doesn't make sense to do it that way. If I just wanted to recompile the entire FreeBSD OS, I would do this:
# cd/usr/src # make world
Yadda yadda yadda, similarly in the other BSDs. To expand from this, I could build a fully functional embedded system with a measly few hundred lines of sh(1) script. Note how this did not require me to create another, entirely separate open-source OS project. I just piggybacked on BSD's existing, highly-integrated code base and build system.
To conclude: making it easy to make a small BSD is at most a minor job, easily (and best) doable within the fold of one of the existing BSDs. Forking BSD doesn't make sense for this.
And before someone flames me, let me say this: I prefer BSD, but both Linux and BSD make great small or embedded OSes. Each has its own strengths and weaknesses. I don't wish to knock Linux; my only argument concerns the lack of necessity to fork BSD.
the part right before a certain female pilot went into a multi-episode coma.
Hallelujah! Errr, I mean I think that whole sequence is probably the best 5 minutes of animation ever animated. Quite possibly the best 5 minutes of anything you can play on a screen. People ask me "What is anime?", and I'll pop in DVD #7 and play the Hallelujah sequence. It's so good I'll burn all my karma with no regrets by posting this inane message.
If you've never seen anime or Neon Genesis Evangelion, then run, don't walk, to the nearest video rental and rent DVD #7. Watch the middle episode. Warning: may cause serious addiction.
I have to hand it to Apple. It seems that all too often these days everything is a dot-oh release, especially from our good friends in Redmond. And that's when they're not calling things letters (XP) or giving them year numbers (2000). It's nice to see a real three-field version number for a change.
Now you can hide those duplicate servers in one box! Yeah, scalable and 7/24/365.25 reliability
Wait a second. I thought one of the reasons for failover technology was to protect against OS and hardware failures. If you put your servers virtually on one machine, you aren't protected when the machine's underlying OS fails, or when the machine's hardware fails.
an old Pentium 133 system that stores stamp club membership details in a DOS program
Have you ever run DOS 6.22 on a P133? It's blazing fast. If you must run a DOS app, it would almost be folly to run it on anything more than a P133! Of course, the P133 was not the processor of DOS's heyday; the 80386 was. By the time of the P133, the industry had already begun to migrate to Win95 (or OS/2, or Linux, or you favorite OS - no flames needed here):-)
in "real-time mode"
Sorry to pick nits on Slashdot, but you probably meant "real mode", though I could be wrong. Real-time and real mode are very different animals.
If you get into embedded systems programming, which has a component of electronic engineering, you'll use calculus, including differential equations, to understand how electronics work.
BTW, when I'm talking about 'embedded' here, I'm talking about the traditional embedded industry: industrial control, security systems, fuel injectors, medical instruments, satellites, etc. There's another so-called embedded industry that's all about set-top boxes and PDAs, but it's a lot less electronics-oriented and less hard-core. Most of the time, when people talk on Slashdot about 'embedded', they refer to the second form. However, if you go buy a magazine about embedded systems (Circuit Cellar, Embedded Systems Programming), it will deal mostly with the first one.
In a math class at MIT, a professor had just spent the last forty minutes working an extremely complicated problem. As he neared completion, he said "...and from here, it is obvious that--"
He stopped and looked at the blackboard with a puzzled expression. "Is it obvious?" he asked himself, loudly enough that the students heard him. "Hmf," he said as he left the room.
Now mind you, this was MIT, so the students sat patiently in their seats. Twenty minutes later, the professor returned and cleared his throat.
"Yes, from here it is obvious that V equals..." The professor continued his presentation.
Currently Personal Names Ltd. handle that functionality via e-mail to customer service
Arggggh! We left the Stone Age quite some time ago. Email as a domain management interface is not the way to attract customers. There's certainly something to like about web-based administration, like that available at my favorite registrar. With such an interface, I can make changes instantly. I can check the status of all my domains instantly. With email, I would would have to wait on a customer service monkey to go do my requests for me, which would probably get botched the first three times around, anyway. And if I sent an email saying "What's the status of my domains?", I would surely not receive a response.
Once someone gets used to web-based domain administration, they'll never go back to email. That means they won't be your customers either.
Botched launch, bad pricing, complicated product, inane business plan... you guys are fixing to party like it's 1999.
So far, however, our research indicate that people aren't particularly bothered about the price - either they want it and the price isn't an object, or they don't.
Then the logical conclusion is that you should increase the price of the service to infinity. Saying that the price "isn't an object" futher convinces me that your firm is already dead. There are very few, if any, customer-oriented business ventures where price is not important. Your research is wrong.
Slashdot Mirror
Hello?! Those don't go in your PCI slots!
I wish I had read this article before I began installing Gentoo on the only device I have with a TV tuner! Sigh... I guess there's always P2P. :-/
The earliest -11 you can run a web browser on today is probably the 11/70, released (IIRC) in 1975. You can install 2.11BSD on an 11/70 with enough memory, and your browser can run from within that. If there's no browser, then there's at least telnet to port 80. :-)
PDP-11/70s are difficult to run and maintain. I would suggest that the intrepid reader use a 11/44 instead. Nearly 100% software-compatible with the 11/70 but not quite as huge and not quite as expensive to obtain, the 11/44 is a good collector machine. If you get one, read up about its power supply. If you touch the wrong places (and the're easy to touch), you WILL be killed!
Less intrepid but still interested readers shoudl go with a MicroPDP-11/73 in a BA23 tower. They look like skinny tower PCs and are relatively uncomplicated.
You are assuming that the X11 replacement would be Windows-ish. I don't think that's a safe assumption. What needs to be done is a refactoring of the idea of X11. Drop the old and busted design and create a new hotness one, using things we've learned since then.
What causes slowness more than X11 itself, is the programs running on top of it
Yes, X11 does nothing very fast if you don't run any programs in it.
While I don't believe that we'll ever perfectly know how to know things and thus not occasially shoot ourselves in the foot, I do believe that our epistomological self-consciousness is increasing.
Caldera
240 West Center Street
Orem, Utah 84057
801-765-4999 Fax 801-765-4481
January 23, 2002
Dear UNIX enthusiasts, Caldera International, Inc. hereby grants a fee free license that includes the rights use, modify and distribute this named source code, including creating derived binary products created from the source code. The source code for which Caldera International, Inc. grants rights are limited to the following UNIX Operating Systems that operate on the 16-Bit PDP-11 CPU and early versions of the 32-Bit UNIX Operating System, with specific exclusion of UNIX System III and UNIX System V and successor operating systems:
- 32-bit 32V UNIX
- 16 bit UNIX Versions 1, 2, 3, 4, 5, 6, 7
Caldera International, Inc. makes no guarantees or commitments that any source code is available from Caldera International, Inc.The following copyright notice applies to the source code files for which this license is granted.
Copyright(C) Caldera International Inc. 2001-2002. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code and documentation must retain the above copyright notice, this list of conditions and the
following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the distribution.
- All advertising materials mentioning features or use of this software must display the following acknowledgement:
- Neither the name of Caldera International, Inc. nor the names of other contributors may be used to endorse or promote
products derived from this software without specific prior written permission.
USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA INTERNATIONAL, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE FOR ANY DIRECT, INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.Very truly yours,
Bill Broderick Director, Licensing Services
* UNIX is a registered trademark of The Open Group in the US and other countries.
Personally, the spam solution I like the best is to have procmail+formail or some other tool sitting on your mail server and making unknown senders go through a confirmation step. It doesn't work for everyone (for instance, people expecting email replies to résumés! NAGI...), but if it works for you it tends to work very well. It inconveniences everyone else, but hey, everyone else is not me. I can whitelist all the people I truly care about.
Either that or we should throw out SMTP, email RFCs, sendmail, etc. and build a spam-free system from the ground up. Yeah, right.
Or maybe you're installing FreeBSD. They make ISOs available for download. So do a bunch of other free OS projects.
I was actually referring to the BSD mascot: a red daemon holding a big fork. The mascot itself refers to the fork() system call, which was one of Unix's wow-cool features back in the day.
Well, you need to watch something to tie everything together; all the loose ends left by just watching up to episode 24 would be unbearable. Any curious human would want more. And I don't think it is too farfetched to think that End of Evangelion provides the better ending of the two. So I'm must disagree and recommend that the reader at least watch EoE.
One of the distinctive things to note about Linux is that its code base is rather distributed. The kernel comes from here, cc comes from there, and the $other_thing comes from somewhere else. The boundary between the base Linux OS and additionally-installed software is sometimes not very defined. The BSDs' code bases are organized differently, each BSD having its own (mostly) centralized, integrated code repository and build system. BSDs do include some "contrib" software (e.g. Less or OpenSSH) that comes from other sources, but contrib releases are still merged and adapted into the main repository. BSDs have a very definite boundary between what is the base OS and what is a third-party package, or "port".
Either way is a great way to structure an OS code base. However, the organizational differences do have some effect upon what is the best way to make a small or embedded version of the OS. With Linux, it's good to fork off a separate distribution, so that packages and a build system can be most effectively engineered. Granted, I never looked at MicroBSD closely (so I could be totally wrong), but that seems to be the approach they took. With BSD, however, it just doesn't make sense to do it that way. If I just wanted to recompile the entire FreeBSD OS, I would do this:
Yadda yadda yadda, similarly in the other BSDs. To expand from this, I could build a fully functional embedded system with a measly few hundred lines of sh(1) script. Note how this did not require me to create another, entirely separate open-source OS project. I just piggybacked on BSD's existing, highly-integrated code base and build system.To conclude: making it easy to make a small BSD is at most a minor job, easily (and best) doable within the fold of one of the existing BSDs. Forking BSD doesn't make sense for this.
And before someone flames me, let me say this: I prefer BSD, but both Linux and BSD make great small or embedded OSes. Each has its own strengths and weaknesses. I don't wish to knock Linux; my only argument concerns the lack of necessity to fork BSD.
BTW, no puns intended by "forking BSD". :-)
I don't see how, considering that the advertising clause was removed some time ago.
Hallelujah! Errr, I mean I think that whole sequence is probably the best 5 minutes of animation ever animated. Quite possibly the best 5 minutes of anything you can play on a screen. People ask me "What is anime?", and I'll pop in DVD #7 and play the Hallelujah sequence. It's so good I'll burn all my karma with no regrets by posting this inane message.
If you've never seen anime or Neon Genesis Evangelion, then run, don't walk, to the nearest video rental and rent DVD #7. Watch the middle episode. Warning: may cause serious addiction.
I have to hand it to Apple. It seems that all too often these days everything is a dot-oh release, especially from our good friends in Redmond. And that's when they're not calling things letters (XP) or giving them year numbers (2000). It's nice to see a real three-field version number for a change.
I call it driver. Time to go get a trademark and start suing people!
Wait a second. I thought one of the reasons for failover technology was to protect against OS and hardware failures. If you put your servers virtually on one machine, you aren't protected when the machine's underlying OS fails, or when the machine's hardware fails.
Have you ever run DOS 6.22 on a P133? It's blazing fast. If you must run a DOS app, it would almost be folly to run it on anything more than a P133! Of course, the P133 was not the processor of DOS's heyday; the 80386 was. By the time of the P133, the industry had already begun to migrate to Win95 (or OS/2, or Linux, or you favorite OS - no flames needed here) :-)
in "real-time mode"
Sorry to pick nits on Slashdot, but you probably meant "real mode", though I could be wrong. Real-time and real mode are very different animals.
Huh? A sector on a disk does not contain other sectors. Therefore, there cannot be a sector 33 of the boot sector.
Perhaps you mean that that sector 33 in the boot-information track or cylinder is overwritten. That would seem to make more sense.
BTW, when I'm talking about 'embedded' here, I'm talking about the traditional embedded industry: industrial control, security systems, fuel injectors, medical instruments, satellites, etc. There's another so-called embedded industry that's all about set-top boxes and PDAs, but it's a lot less electronics-oriented and less hard-core. Most of the time, when people talk on Slashdot about 'embedded', they refer to the second form. However, if you go buy a magazine about embedded systems (Circuit Cellar, Embedded Systems Programming), it will deal mostly with the first one.
Great! Maybe we will all start using enum instead of #defined constants!
He stopped and looked at the blackboard with a puzzled expression. "Is it obvious?" he asked himself, loudly enough that the students heard him. "Hmf," he said as he left the room.
Now mind you, this was MIT, so the students sat patiently in their seats. Twenty minutes later, the professor returned and cleared his throat.
"Yes, from here it is obvious that V equals ..." The professor continued his presentation.
Arggggh! We left the Stone Age quite some time ago. Email as a domain management interface is not the way to attract customers. There's certainly something to like about web-based administration, like that available at my favorite registrar. With such an interface, I can make changes instantly. I can check the status of all my domains instantly. With email, I would would have to wait on a customer service monkey to go do my requests for me, which would probably get botched the first three times around, anyway. And if I sent an email saying "What's the status of my domains?", I would surely not receive a response.
Once someone gets used to web-based domain administration, they'll never go back to email. That means they won't be your customers either.
Botched launch, bad pricing, complicated product, inane business plan... you guys are fixing to party like it's 1999.
Then the logical conclusion is that you should increase the price of the service to infinity. Saying that the price "isn't an object" futher convinces me that your firm is already dead. There are very few, if any, customer-oriented business ventures where price is not important. Your research is wrong.