Yes, Americans can sit around and watch to see how well the Europeans and Chinese do something that NASA achieved over four decades ago - and repeated dozens of times since.
It's funny to see how cold war thinking still infects US minds. The "space race" was only a "race" because the US desparately wanted to prove that US society was superior; in part, this was because right after WWII, the Soviet model actually seemed to be working pretty well in terms of economics and science, and it looked for a while as if the Soviets were going to take over pretty much the rest of the world. In contrast, after WWII, Europeans didn't really care about anybody proving superiority to anyone anymore, they just wanted to live in peace and prosperity. Big guns, big rockets, or big words stopped impressing Europeans. This is perhaps also why Bush finds it so hard to get much support for his current adventures.
The moon isn't going anywhere. Missions to it (as all space exploration) should be driven by available technology, resources, and scientific goals, not by some horse race mentality.
What happened was that a huge number of people programmed in something *like* the standard (i.e., were programming in UNIX and Windows, using the most well-supported definition of the APIs, with the tools that existed at the time).
Of course, that's what happened, and that's one way of building a successful standard. The ANSI C and ANSI C++ standards still have had, and continue to have, a profound impact on C and C++ programming. In fact, the standardization process itself was going on for long enough and involved enough people in the community that many bugs got worked out.
Another reason for the wild success of C and C++ is what they didn't standardize: the language creators tried to refrain from trying to standardize things they did not understand or could not understand at the time, and focused on giving developers the tools with which they could build entirely new sets of efficient standard libraries themselves.
Think about how much code is out there that wasn't written using the features of C90, how much C code actually makes assumptions about endianess and the size of pointers, and how long it took most commercial C++ compilers to actually implement the spec.
Yup, but pretty much all that code has been migrated to ANSI standards compliance: because of careful design of the standard, that conversion can be automated in almost all cases. What can't be fixed automatically usually is an easy-to-fix compile-time error.
As for about "assumptions about endianness and the size of pointers", those are perfectly valid: they are implementation defined or unspecified features. It's a valid choice in a language standard, even though I don't particularly like them. Note that CommonLisp is full of implementation-defined and unspecified effects, too.
Your last comment means that your definition of "real" certainly differs from mine. Just for curiosity, what do you consider to be a real software project implemented in Scheme (not including Scheme implementations)?
Guile alone has a significant number of desktop applications that are largely written in it (see here). There are also many other systems where Scheme is used as an extension language. Also, compilers like Bigloo are actually both quite nice and reasonably efficient; I have never found anything comparable for CommonLisp.
Overall, I think your last point is pretty key to understanding why CommonLisp never took off more widely: its community often had a disdain for the applications and concerns of people outside their community, considering anything that didn't fit into their little world "not real".
Linux doesn't need such an application because it is such an application: FTP, Apache, DAV, talk, etc. are all peer-to-peer, direct-conect applications for file sharing and messaging. You can plug in new services, connect them, etc., all easily and robustly.
I suppose you would argue that the C and C++ standards have equal problems with being practical languages?
The C and C++ standards have enormous numbers of problems. However, when all is said and done, the C/C++ standards have succeeded in the real world: there are huge numbers of libraries available and it is easy to write efficient C/C++ code that runs on a wide varietly of platforms and implementations. Unfortunately, for whatever reasons, the same cannot be said for CommonLisp.
In fact, virtually every decision behind the standard was based on proven [Lisp] programming practice.
True, and that's probably one of its problems: CommonLisp was in use by a narrow slice of the software development community, and their narrow interests got codified in the standard.
It succeeded, in that most real Lisp programming now happens in Common Lisp.
Most real Lisp programming these days probably is happening in Scheme and EmacsLisp.
No matter what happens, these people can claim victory. I mean, P2P basically could be anything where one machine sometimes acts as a client and sometimes as a server. You know, like workstations used to before the advent of dial-up Internet access, when people started needing servers because they weren't always on or their IP addresses kept changing. And for grid computing, well, machines sometimes need to act as clients and sometimes as servers.
Here, I'll go out on a limb and make an even more daring prediction: grid computing will use Rendezvous-like services. Some of the machines may do that at boot time, to load customized and specialized machine configuration (you know, like BOOTP/DHCP followed by NFS), and others will use it at the application level to discover potential clients and servers.
All this stuff was designed into the Internet in decades ago. People are just giving fancy names to very traditional usages of sockets, servers, and broadcast packets. "Grid computing", too, is pretty much what people have been doing on networks of workstations for years: sometimes you push the jobs, sometimes available machines pull the jobs, sometimes you have a workflow manager, sometimes it's done through NFS, etc.
All of this reminds me of some teenager thinking that they are the first person on the planet to have discovered "sex".
I think the point is that using imaging, while a technically superior alternative, is NOT an option due to the variance of hardware
That's a bad point. With drive imaging, at least you can put all the boot code, kernels, and drivers you might ever need onto the drive, as well as enough intelligence for the thing to figure out what it needs to do by itself.
Fiddling around with floppies, you are going to spend hours per machine just picking and choosing among the drivers by hand.
Is there some way of booting the PS/2 into Linux without a HD (from DVD or the network)? That way, it might make a decent component of a compute cluster, or one could develop PS2 games in Linux for wide distribution. But a PS2 with the Linux kit just doesn't seem worth it.
Same thing happens in C/C++, perhaps more frequently:
Programmer 1:
struct Part { int number; string name; string description; int count; };
Programmer 2:
Oh, how inefficient; let's just replace that with integers and put the strings into a "resource table" somewhere.
typedef int Part[4];
In fact, by using atoms rather than strings, the Lisp programmer can achieve the efficiency of C++ Program 2 while essentially preserving the appearance of Program 1.
Note that the correct way of defining the data structure would be with DEFSTRUCT or as a CLOS object.
As for the parentheses, people who sit in glass houses shouldn't throw stones: C/C++ syntax has numerous flaws. Is syntax like this really better?
a[((unsigned)*(short*)b)]
What about expressions like "a = b << c + d"; do you really know how the precedences work out?
Lisp syntax, with the right editor, is easy to input and easy to read. And unlike C/C++ syntax, it doesn't have any precedence issues and it is extensible.
Actually, AOP and CLOS are related; it's not clear that if you have CLOS, you still want AOP.
As for Java and Lisp, yes, it would be great to be able to use Lisp. Unfortunately, CommonLisp implementations and libraries simply don't work out to be as practical. That's not a problem with Lisp, it's a problem with the CommonLisp standard, the CommonLisp community, and CommonLisp history. Someone could still create a great Lisp-based language and implementation, but it doesn't exist right now.
Microsoft can choose to sue whoever they like over this. They could selectively go after only OpenGL friendly companies, and their terms could be "we drop the lawsuit if you drop OpenGL".
Capitalism is a self correcting system. Its just sometimes we are too impatient and want the results unreasonably quick.
Oh? Who has ever shown that capitalism is a self-correcting system? Under specific assumptions, a competitive, free market system will self-correct. But capitalism does not necessarily meet those assumptions.
Besides, if we didn't have BIG corporations, we would not have ships, planes, affordable computers, cars, etc.
There is nothing wrong with BIG corporations, as long as they are BIG corporations in competition with each other. There is everything wrong with having one company (or even a handful of companies) dominate one sector of the market. Like Microsoft does.
That doesn't look all that different from the screen of a Titanium Powerbook. I know, my desktop LCD is much thicker as well, but apparently that's not an intrinsic constraint of LCDs, it's just the way desktop displays tend to be built.
IM may look like a service being offered by AOL, but it really isn't. IM could be provided in the same way that E-mail is: through our ISPs. That is, each ISP would run an IM server, just like they are running an SMTP server, they'd use an open protocol, and your IM id could be the same as your e-mail (or maybe not, if you don't like that). That's, effectively, how IM started out on UNIX and mainframe systems, long before AOL or any of the other players.
It's a historical accident that, instead, we have this kludgy, centralized, closed infrastructure that's owned by AOL and a few other players. If AOL goes away and takes their "free service" with them, all the better, as far as I'm concerned. But we'll probably have to listen to this kind of whining over and over again.
Since Microsoft is doing their own 3D APIs no matter what, and since non-Microsoft platforms can't implement Microsoft's APIs anyway, we will be stuck with two low-level APIs anyway, whether Microsoft supports OpenGL or not.
In reality, neither OpenGL nor Direct3D are particularly nice APIs, and the future will likely belong to software layers on top of them. Once you have those, it matters less whether there are one or two backends.
SMB is fine for office and simple day-to-day activities, but it does not preserve UNIX file system semantics. SMB is also fine for accessing files on a Windows file server because, no matter what you run on the file server, it already won't behave like a UNIX file system.
However, if you are serving files from a UNIX/Linux server to UNIX/Linux clients, SMB is not the way to go. NFS and a few other network file systems were designed for UNIX and they do a better job at preserving UNIX file system semantics. That really does matter in more "heavy-duty" applications.
"Solid" in what way? Faster? Crashes less? Easier to manage? Fewer bugs? Those are all different criteria. At some point, Sun's NFS implementation was the fastest and just didn't crash, but it mangled data occasionally--is that more "solid" than a slower implementation that crashes but doesn't mangle data?
(Note, incidentally, that Sun is sponsoring an implementation of NFSv4 for Linux (here).)
Overall, given over a decade of experience with Sun NFS, to me, it is not obviously preferable to other NFS offerings. I suspect that whatever your needs are, you can probably do just as well based on one of the open source implementations.
32-bit memory limited our max customer size dramatically.
There is no "32 bit memory limit" for OODBMSs on 32 bit processors. There isn't even for ObjectStore. If ObjectStore did have such a limit in 1999, you picked a bad system: people have known how to map very large OODBMSs into a 32bit address space for much, much longer than that.
OODBMSs are not a step backward, nor a step forward, they are just different from RDBMSs. Both are complex, kludgy, and messy designs. We probably need something better than either of them in the long run. In the short term, RDBMSs mostly predominate because of inertia and availability. If it were just a technical choice, you'd probably see them share the market fairly equally.
How do you propose to peform Hubble-style repair missions or on-orbit space station construction if you do not have a shuttle-like vehicle? These tasks cannot be done with "dumb rockets". Specific applications necessitate specific vehicle configurations.
Well, you build the specific vehicle or tool you need, you shoot it into orbit, and you leave it there for future use. Once you dispense with the need of having that specialized vehicle be able to withstand reentry, its design should become a lot simpler. Of course, that's provided something like the ISS or a Hubble repair even make sense.
I think the Hubble cost about $1.5b to build and launch, and the second one would likely be cheaper. Each shuttle launch is about $470m, and you really have to attribute many shuttle launches to the Hubble repair if that's the kind of reason you are maintaining a shuttle program. You also have to take into account the substantial costs of actual repairs, and the cost of having the Hubble being operated in space while broken ($25m/mo). Overall, not having a shuttle program and dealing with occasional failures like the Hubble by replacement would probably be much cheaper. And even if you have to design a repair vehicle and send up up with some astronauts (who will return in a capsule), you can still do that without a shuttle.
Let's not even get into whether the ISS is a sensible thing to spend money on...
No, I'm thinking of years of painful experience backing up Sun workstations on 8mm and DAT tape and trying to get the data back. I'm also thinking of having old tape coating just crumble off in front of me.
Am I supposed to drop an IDE disk in my safety deposit box occasionally?
Yes. If the size bothers you, pay a little more and get laptop drive or a bus-powered USB2 drive. There are about half the size of a VHS cassette.
Or, alternatively, simplify your life, stick the disk into an old computer and do backups over the network (the link doesn't have to be very fast). You can do wireless and put it somewhere reasonably far away from the main computer (garage?), put it at a friend's house, or colocate.
As far as DVD-R goes, so far the media cost seems kind of high to be running full backups very often.
Media are down to under $2 per disk for both "R" and "RW" (2-3x that at your local CompUSA). You can use DVD-RW if you want to reuse backups.
that's funny, DLT magnetic tapes have a guarenteed life of 50 years,
Yeah, right. And if it doesn't last 50 years, the manufacturer will gladly replace the media for you, which is the degree of their liability. And DLT's are at least designed for data and backups, MiniDV are consumer media for video. Get the difference?
and we have some 9 track magnetic tapes we found in the basement from the late 70's along with a 9 track tape reader that had an ISA card from the mid 80's and dos drivers (on a 5 1/4 inch floppy) to read that tape last week... it read fine..
I have had 8mm and DAT tapes fail after a few months. Tapes develop a lot of cross-talk between loops if they sit around for too long (you can hear it on audio). The coating used for tapes becomes brittle and just falls off sooner or later.
Yes, you can get lucky. And 9 track tapes are probably the most robust given that the data density is so low. But it's not something I would trust important backup data to.
Slashdot Mirror
It's funny to see how cold war thinking still infects US minds. The "space race" was only a "race" because the US desparately wanted to prove that US society was superior; in part, this was because right after WWII, the Soviet model actually seemed to be working pretty well in terms of economics and science, and it looked for a while as if the Soviets were going to take over pretty much the rest of the world. In contrast, after WWII, Europeans didn't really care about anybody proving superiority to anyone anymore, they just wanted to live in peace and prosperity. Big guns, big rockets, or big words stopped impressing Europeans. This is perhaps also why Bush finds it so hard to get much support for his current adventures.
The moon isn't going anywhere. Missions to it (as all space exploration) should be driven by available technology, resources, and scientific goals, not by some horse race mentality.
Of course, that's what happened, and that's one way of building a successful standard. The ANSI C and ANSI C++ standards still have had, and continue to have, a profound impact on C and C++ programming. In fact, the standardization process itself was going on for long enough and involved enough people in the community that many bugs got worked out.
Another reason for the wild success of C and C++ is what they didn't standardize: the language creators tried to refrain from trying to standardize things they did not understand or could not understand at the time, and focused on giving developers the tools with which they could build entirely new sets of efficient standard libraries themselves.
Think about how much code is out there that wasn't written using the features of C90, how much C code actually makes assumptions about endianess and the size of pointers, and how long it took most commercial C++ compilers to actually implement the spec.
Yup, but pretty much all that code has been migrated to ANSI standards compliance: because of careful design of the standard, that conversion can be automated in almost all cases. What can't be fixed automatically usually is an easy-to-fix compile-time error.
As for about "assumptions about endianness and the size of pointers", those are perfectly valid: they are implementation defined or unspecified features. It's a valid choice in a language standard, even though I don't particularly like them. Note that CommonLisp is full of implementation-defined and unspecified effects, too.
Your last comment means that your definition of "real" certainly differs from mine. Just for curiosity, what do you consider to be a real software project implemented in Scheme (not including Scheme implementations)?
Guile alone has a significant number of desktop applications that are largely written in it (see here). There are also many other systems where Scheme is used as an extension language. Also, compilers like Bigloo are actually both quite nice and reasonably efficient; I have never found anything comparable for CommonLisp.
Overall, I think your last point is pretty key to understanding why CommonLisp never took off more widely: its community often had a disdain for the applications and concerns of people outside their community, considering anything that didn't fit into their little world "not real".
Linux doesn't need such an application because it is such an application: FTP, Apache, DAV, talk, etc. are all peer-to-peer, direct-conect applications for file sharing and messaging. You can plug in new services, connect them, etc., all easily and robustly.
The difficulty with this is not doing it, it's doing it on top of Windows.
The C and C++ standards have enormous numbers of problems. However, when all is said and done, the C/C++ standards have succeeded in the real world: there are huge numbers of libraries available and it is easy to write efficient C/C++ code that runs on a wide varietly of platforms and implementations. Unfortunately, for whatever reasons, the same cannot be said for CommonLisp.
In fact, virtually every decision behind the standard was based on proven [Lisp] programming practice.
True, and that's probably one of its problems: CommonLisp was in use by a narrow slice of the software development community, and their narrow interests got codified in the standard.
It succeeded, in that most real Lisp programming now happens in Common Lisp.
Most real Lisp programming these days probably is happening in Scheme and EmacsLisp.
when people started needing chat and file exchange servers because they weren't always on
On always-on workstations, this was traditionally handled via things like "talk" and "ftp".
Here, I'll go out on a limb and make an even more daring prediction: grid computing will use Rendezvous-like services. Some of the machines may do that at boot time, to load customized and specialized machine configuration (you know, like BOOTP/DHCP followed by NFS), and others will use it at the application level to discover potential clients and servers.
All this stuff was designed into the Internet in decades ago. People are just giving fancy names to very traditional usages of sockets, servers, and broadcast packets. "Grid computing", too, is pretty much what people have been doing on networks of workstations for years: sometimes you push the jobs, sometimes available machines pull the jobs, sometimes you have a workflow manager, sometimes it's done through NFS, etc.
All of this reminds me of some teenager thinking that they are the first person on the planet to have discovered "sex".
That's a bad point. With drive imaging, at least you can put all the boot code, kernels, and drivers you might ever need onto the drive, as well as enough intelligence for the thing to figure out what it needs to do by itself.
Fiddling around with floppies, you are going to spend hours per machine just picking and choosing among the drivers by hand.
Sounds like some sort of Morrowind expansion pack.
Is there some way of booting the PS/2 into Linux without a HD (from DVD or the network)? That way, it might make a decent component of a compute cluster, or one could develop PS2 games in Linux for wide distribution. But a PS2 with the Linux kit just doesn't seem worth it.
Same thing happens in C/C++, perhaps more frequently:
Programmer 1:
struct Part {
int number;
string name;
string description;
int count;
};
Programmer 2:
Oh, how inefficient; let's just replace that
with integers and put the strings into a
"resource table" somewhere.
typedef int Part[4];
In fact, by using atoms rather than strings,
the Lisp programmer can achieve the efficiency
of C++ Program 2 while essentially preserving
the appearance of Program 1.
Note that the correct way of defining the
data structure would be with DEFSTRUCT or
as a CLOS object.
As for the parentheses, people who sit in
glass houses shouldn't throw stones: C/C++
syntax has numerous flaws. Is syntax like this
really better?
a[((unsigned)*(short*)b)]
What about expressions like "a = b << c + d";
do you really know how the precedences work out?
Lisp syntax, with the right editor, is easy
to input and easy to read. And unlike C/C++
syntax, it doesn't have any precedence issues
and it is extensible.
As for Java and Lisp, yes, it would be great to be able to use Lisp. Unfortunately, CommonLisp implementations and libraries simply don't work out to be as practical. That's not a problem with Lisp, it's a problem with the CommonLisp standard, the CommonLisp community, and CommonLisp history. Someone could still create a great Lisp-based language and implementation, but it doesn't exist right now.
Microsoft can choose to sue whoever they like over this. They could selectively go after only OpenGL friendly companies, and their terms could be "we drop the lawsuit if you drop OpenGL".
Oh? Who has ever shown that capitalism is a self-correcting system? Under specific assumptions, a competitive, free market system will self-correct. But capitalism does not necessarily meet those assumptions.
Besides, if we didn't have BIG corporations, we would not have ships, planes, affordable computers, cars, etc.
There is nothing wrong with BIG corporations, as long as they are BIG corporations in competition with each other. There is everything wrong with having one company (or even a handful of companies) dominate one sector of the market. Like Microsoft does.
That doesn't look all that different from the screen of a Titanium Powerbook. I know, my desktop LCD is much thicker as well, but apparently that's not an intrinsic constraint of LCDs, it's just the way desktop displays tend to be built.
It's a historical accident that, instead, we have this kludgy, centralized, closed infrastructure that's owned by AOL and a few other players. If AOL goes away and takes their "free service" with them, all the better, as far as I'm concerned. But we'll probably have to listen to this kind of whining over and over again.
In reality, neither OpenGL nor Direct3D are particularly nice APIs, and the future will likely belong to software layers on top of them. Once you have those, it matters less whether there are one or two backends.
However, if you are serving files from a UNIX/Linux server to UNIX/Linux clients, SMB is not the way to go. NFS and a few other network file systems were designed for UNIX and they do a better job at preserving UNIX file system semantics. That really does matter in more "heavy-duty" applications.
(Note, incidentally, that Sun is sponsoring an implementation of NFSv4 for Linux (here).)
Overall, given over a decade of experience with Sun NFS, to me, it is not obviously preferable to other NFS offerings. I suspect that whatever your needs are, you can probably do just as well based on one of the open source implementations.
There is no "32 bit memory limit" for OODBMSs on 32 bit processors. There isn't even for ObjectStore. If ObjectStore did have such a limit in 1999, you picked a bad system: people have known how to map very large OODBMSs into a 32bit address space for much, much longer than that.
OODBMSs are not a step backward, nor a step forward, they are just different from RDBMSs. Both are complex, kludgy, and messy designs. We probably need something better than either of them in the long run. In the short term, RDBMSs mostly predominate because of inertia and availability. If it were just a technical choice, you'd probably see them share the market fairly equally.
Well, you build the specific vehicle or tool you need, you shoot it into orbit, and you leave it there for future use. Once you dispense with the need of having that specialized vehicle be able to withstand reentry, its design should become a lot simpler. Of course, that's provided something like the ISS or a Hubble repair even make sense.
I think the Hubble cost about $1.5b to build and launch, and the second one would likely be cheaper. Each shuttle launch is about $470m, and you really have to attribute many shuttle launches to the Hubble repair if that's the kind of reason you are maintaining a shuttle program. You also have to take into account the substantial costs of actual repairs, and the cost of having the Hubble being operated in space while broken ($25m/mo). Overall, not having a shuttle program and dealing with occasional failures like the Hubble by replacement would probably be much cheaper. And even if you have to design a repair vehicle and send up up with some astronauts (who will return in a capsule), you can still do that without a shuttle.
Let's not even get into whether the ISS is a sensible thing to spend money on...
And for the privilege of using a sequential access storage medium, you end up paying more per gigabyte than if you just bought an IDE derive.
All of that fiddling with DLT may still make sense for enterprises, but it makes no sense for someone considering using MiniDV for backups.
No, I'm thinking of years of painful experience backing up Sun workstations on 8mm and DAT tape and trying to get the data back. I'm also thinking of having old tape coating just crumble off in front of me.
Yes. If the size bothers you, pay a little more and get laptop drive or a bus-powered USB2 drive. There are about half the size of a VHS cassette.
Or, alternatively, simplify your life, stick the disk into an old computer and do backups over the network (the link doesn't have to be very fast). You can do wireless and put it somewhere reasonably far away from the main computer (garage?), put it at a friend's house, or colocate.
As far as DVD-R goes, so far the media cost seems kind of high to be running full backups very often.
Media are down to under $2 per disk for both "R" and "RW" (2-3x that at your local CompUSA). You can use DVD-RW if you want to reuse backups.
Yeah, right. And if it doesn't last 50 years, the manufacturer will gladly replace the media for you, which is the degree of their liability. And DLT's are at least designed for data and backups, MiniDV are consumer media for video. Get the difference?
and we have some 9 track magnetic tapes we found in the basement from the late 70's along with a 9 track tape reader that had an ISA card from the mid 80's and dos drivers (on a 5 1/4 inch floppy) to read that tape last week... it read fine..
I have had 8mm and DAT tapes fail after a few months. Tapes develop a lot of cross-talk between loops if they sit around for too long (you can hear it on audio). The coating used for tapes becomes brittle and just falls off sooner or later.
Yes, you can get lucky. And 9 track tapes are probably the most robust given that the data density is so low. But it's not something I would trust important backup data to.