If you're designing a system from scratch and have a pretty good idea of the bounds of the system, then yeah, you can go with lower-level protocols and writing the code directly to that level.
If you're piecing something together from pre-existing parts or there's a good possibility that the use of the system will extend beyond the bounds you have direct control over, then it helps to have a few adapters and higher level protocols in the toolkit. It may also be that those higher-level toolkits have a level of robustness and ease-of-use beyond what hand-rolling your own to a lower level might have.
But you may have a point. Why do people see the need to layer extra levels of abstraction on top of raw machine code? What was wrong with assembler, Fortran and C that required Python, Perl or Java to fix?;)
it was taken over by his former bosses who didn't really have much of a business before.
I'm not familiar with that stage of the company's history or who exactly you mean, but if you mean the likes of the current Chairman and/or CEO -- well, it has been some years since I worked with them at GeoVision, but as far as, say, Perry goes, I wouldn't call MapQuest "not much of a business".
If you have something specific to say then say it: vague negative statements about one's former employer may leave an impression you didn't intend. But at least you posted the disclaimer.
Not any more. The XBox has been in production long enough that they cost less to make than they sell for. And Microsoft wrote off the development costs against taxes a year ago.
I have some ideas for an experimental groupware system that I would like to play with. One problem that I was anticipating was to sync-up system users when they are online.
I'm not sure I entirely get your point here -- by "sync-up" do you mean giving late-comers the opportunity to catch up on messages that went before?
If so you might want a back-end designed for such a purpose, something like an asynchronous conferencing system like CoSy. That won't fit the bill as-is, but a while back I did some work on separating out the user and storage interface pieces (some documentation/code on that here. Lately I've been thinking that wrapping it all into a Jabber server (with extensions) makes more sense.
Combine a Jabber client with an HTML-renderer and you've got an ideal "universal client"
Actually for command-line type apps you don't even need the HTML renderer. You just plug stdout and stdin into some sort of adapter process that converts them to/from Jabber send and receive streams (something like how inetd fires up server processes with stdin and stdout pointing at the socket connection.)
There's probably something like that already out there, I haven't looked. (It'd be pretty easy to write.)
One of the cool things about the Jabber protocol is its growing ubiquity (hence likelihood for piercing firewalls along with HTTP) and the fact that it is session oriented rather than HTTP's default "connectionless" mode. Alright, the two cool things about the Jabber protocol are...
Anyway, this makes for easier programming of services that would, if based on HTTP ("web services"), require the usual sorts of messing with session ids and cookies or URL-encoding to work properly. Jabber can be viewed as a high-level transport protocol; it's easy enough to wrap it around whatever data you want transported, especially since it's XML based. Don't forget, the "user" at the other end of that Jabber session doesn't have to be a human at a keyboard, it can be a process. (Okay, the three cool things about Jabber...) Combine a Jabber client with an HTML-renderer and you've got an ideal "universal client" for certain classes of application.
Actually it was Java's success that caused many of the problems you mention.
When introduced, Java had (and still does) many things going for it: portability ("write once, run everywhere" be damned, in those days most developers were happy if you could even write once, compile anywhere); immunity from the causes of zillions of programmer-hours of debug time and crashed C/C++ programs (with garbage collection and run-time checks on array bounds, etc.); elimination of huge design headaches (and cause of yet more bugs and problems by less-than-expert developers) by going to multiple inheritence only of interface, not implementation, and by elminating operator overloading.
All these wonderful attributes triggered a huge surge in Java's popularity -- with corresponding demands on Sun's time to both fix existing problems and to extend it and standardize new APIs. Basically, Sun couldn't keep up with the demand.
Now that Sun has had a few years to catch up, and the Java Community Process has expanded the base of people to work on the above problems and and extensions, the Java platform is -- as you point out -- a pretty decent application platform.
Microsoft didn't kill Java on the client. [...] Java was sitting on the edge of its coffin. All Microsoft did was use its toe to push it in.
"Your Honor, my client did not kill the victim. Why, he crawled out on that ledge all by himself and was ready to jump. All my client did was give him a little push."
Okay, bucko, that's SIX times now you've posted that same excerpt from the EULA. Can we get some (-1, Redundant) modification in here?
Oh, and to answer your question: "you explicitly authorize Microsoft or its designated agent to access and utilize the necessary information for updating purposes."
Note that that says NOTHING about how they will access the information. By the letter of the EULA, they'd be within their rights (which you authorized) to just have a couple of goons march into your computer room and haul the machine back to Redmond for them to update there.
Improbable? Sure. But you explicitly authorized "access", period, not "access over a network connection using a specified protocol on a specified port".
Remember, this is Microsoft legalese we're talking about -- their view of contracts (of wich the EULA is one) is that anything not expressly forbidden to them is allowed.
1.Asteroids that will hit us are not travelling straight at us. [...] In fact, an asteroid coming straight along our line of sight would almost surely miss us.
Nope. The concern is the net vector, not the individual vectors of Earth and asteroid. For it to hit us, the net vector has to be toward us -- therefore straight along our line of sight. Same principle flying or driving -- the vehicles that are moving relative to a spot on the windshield are not the ones you have to worry about, it's the ones that look like a spot on the windshield (and getting bigger) that are the ones that'll hit. (Ditto for side windows.)
Now, if you're talking about months or years in advance, then yes, because of the curvature of the orbits it won't be on a direct vector at that time. Just when it's too close to do much about it.
Then you can ask mean questions to see how far their depth goes ("You can't use the keyword synchronized on a static method. Why?")
The problem with questions like that is that you come across looking stupid to someone who does know their stuff. (You can use the keyword synchronized on a static method.) You might lose your best candidates right there -- not because they can't answer the question, but because they won't want to work for a bozo.
I had a co-worker who liked to ask a really obscure technical question (typically something about determining the convex hull bounding a set of points in 3-space), not to see if they knew the answer, but to see how they reacted to the question. If you tried to bullshit your way through it, you were out. An honest "I don't have any idea, but here's how I'd research it" type answer was about as good as actually knowing what he was talking about (the question had nothing to do with the kind of work) and giving a technically correct answer.
Be that as it may, the fact remains that several versions of Windows contain an "ftp.exe" that includes (if you run 'strings' on it) the string "Copyright (c) 1983 The Regents of the University of California."
That doesn't come from merely "working from the reference implementation".
could make X anywhere from 12% to 37% faster on the average platform
So, did you just pull those numbers out of your asterisk, or can you actually point to some analysis to back that up?
Even assuming that were true, on most machines (ie, anything better than a 386 with 4 MB memory), the difference won't be noticeable because even a 200% improvement in event response is lost in the noise of human reaction/perception times.
U Waterloo has always been in the computer industry's pockets, it seems. Back in the 80's it was IBM, now it's Microsoft. Ho hum. UW does produce good engineers, but they tend not to think outside the box. (Which may not be a quality you want in all your engineers, anyway.)
(Disclaimer: while I've never attended UW, I used to live a block from campus, my (now ex-) wife worked there, and I once worked at a company where there were only two other (out of about fifty) non-UW grads on the tech staff. I also worked at the computer center of another university a few miles down the road from UW, we were pretty familiar with things at that campus.)
Well, not quite no-one. My wife's Mac has VirtualPC with DOS 3.3 on it, and a 30 MB image file of the hard drive from her 286 AT-clone that we scrapped years ago (actually, I replaced the mobo and drive and it was my first Linux machine). There are a couple of old Q&A databases and a bunch of Write files on there that, every once in a while (like, a couple of years between uses), it's useful to refer to.
A lot easier than going to the hassle of converting the data to a more modern format -- although I should probably do that one of these days.
AND WHAT ARE THEY DOING SPENDING $600 ON A HAMMER???
It's $10 for the hammer, $590 for the paperwork to go with it. And no, I'm not kidding (although the exact numbers may be off).
A friend of mine who worked at Martin-Marietta (before it merged with Lockheed) told me a story about a case of duct tape. Seems that some govt agency -- either NASA or Air Force, I don't remember the details -- needed to buy some duct tape. Now, government purchasing regulations (at the time, they're a tiny bit more sane now) required that purchases favor American-made goods, from companies that are Equal Opportunity Employers, etc, etc. This required paperwork to prove that the goods are American made, by EOE companies, etc. Let's face it, most hardware stores can't be bothered with that sort of nonsense (this is why Home Depot has refused for years to sell to the feds).
So this gov't agency gave Martin-Marietta a contract to find an appropriate supplier of duct tape and do the investigation required to fill out the paperwork. Not that big a deal, probably took somebody a few days of phone calls, letters and checking around. But that time and expenses get rolled into the cost of the duct tape -- result, one case of duct tape at about $200 a roll.
Your government at work, making sure they do what's good for the taxpayer, no matter how much of the taxpayers' money they have to spend to do it.
Wow, I'd never heard of that. Thanks for the link.
Interesting use of hologram technology, too -- although sounds like a bit of a kludge. It's almost like combining a movie viewer with a video camera so you can play movies on your TV -- the difference being that the holotapes were mechanically stamped from a master (like the hologram stickers on credit cards and Microsoft license stickers), rather than chemically-processed photographic film, so they'd be much cheaper.
I think largely it was a chicken-and-egg problem. None of the major browser players included VRML as a native format (sure, there were plugins, but people hate downloading plugins) because there wasn't much content. And the content providers weren't interested because it wasn't natively supported by any of the major browsers.
Now, if things had gone a little differently in the browser wars (which were peaking around the time VRML might have taken off), and one of the major browser vendors had rolled in VRML (or included a plugin) instead of trying to come up with yet another non-standard HTML tag, we might all be viewing Slash3D.
The Moon is slowly getting a little bit further from Earth with each orbit (has to do with gravitational effects of tidal bulges, but I digress). Knowing the rate (carefully determined by measurments using the laser reflectors left on the Moon by the Apollo missions), we can extrapolate backwards to determine that, approximately 65 million years ago, the Moon orbited at a distance of about 35 feet.
As for Cinelerra being destined for HDTV, I'd have to agree that it has the capability to go there.
Actually I wrote designed for HDTV -- and I see you agree with that.
Destined for? Who knows. As you say, not many folks out there shooting HD video these days. As for free -- I believe that Heroine Virtual has a package they sell that includes support and/or hardware. They've had a booth at the National Broadcasters Exhibition in the past. (This info gleaned from past versions of their web site, I have no personal contact with them, and my own involvement with video technology has been on the custom tape production side, not broadcast. Hence my interest in modifying the product (whether Premiere or Cinerella or whatever), so that I could automate production of a tape from a library of clips without ever having to use the GUI.)
Slashdot Mirror
If you're designing a system from scratch and have a pretty good idea of the bounds of the system, then yeah, you can go with lower-level protocols and writing the code directly to that level.
;)
If you're piecing something together from pre-existing parts or there's a good possibility that the use of the system will extend beyond the bounds you have direct control over, then it helps to have a few adapters and higher level protocols in the toolkit. It may also be that those higher-level toolkits have a level of robustness and ease-of-use beyond what hand-rolling your own to a lower level might have.
But you may have a point. Why do people see the need to layer extra levels of abstraction on top of raw machine code? What was wrong with assembler, Fortran and C that required Python, Perl or Java to fix?
it was taken over by his former bosses who didn't really have much of a business before.
I'm not familiar with that stage of the company's history or who exactly you mean, but if you mean the likes of the current Chairman and/or CEO -- well, it has been some years since I worked with them at GeoVision, but as far as, say, Perry goes, I wouldn't call MapQuest "not much of a business".
If you have something specific to say then say it: vague negative statements about one's former employer may leave an impression you didn't intend. But at least you posted the disclaimer.
Not any more. The XBox has been in production long enough that they cost less to make than they sell for. And Microsoft wrote off the development costs against taxes a year ago.
They make a profit on the boxes, now.
I have some ideas for an experimental groupware system that I would like to play with. One problem that I was anticipating was to sync-up system users when they are online.
I'm not sure I entirely get your point here -- by "sync-up" do you mean giving late-comers the opportunity to catch up on messages that went before?
If so you might want a back-end designed for such a purpose, something like an asynchronous conferencing system like CoSy. That won't fit the bill as-is, but a while back I did some work on separating out the user and storage interface pieces (some documentation/code on that here. Lately I've been thinking that wrapping it all into a Jabber server (with extensions) makes more sense.
OTOH maybe I missed your point.
Combine a Jabber client with an HTML-renderer and you've got an ideal "universal client"
Actually for command-line type apps you don't even need the HTML renderer. You just plug stdout and stdin into some sort of adapter process that converts them to/from Jabber send and receive streams (something like how inetd fires up server processes with stdin and stdout pointing at the socket connection.)
There's probably something like that already out there, I haven't looked. (It'd be pretty easy to write.)
One of the cool things about the Jabber protocol is its growing ubiquity (hence likelihood for piercing firewalls along with HTTP) and the fact that it is session oriented rather than HTTP's default "connectionless" mode. Alright, the two cool things about the Jabber protocol are...
Anyway, this makes for easier programming of services that would, if based on HTTP ("web services"), require the usual sorts of messing with session ids and cookies or URL-encoding to work properly. Jabber can be viewed as a high-level transport protocol; it's easy enough to wrap it around whatever data you want transported, especially since it's XML based. Don't forget, the "user" at the other end of that Jabber session doesn't have to be a human at a keyboard, it can be a process. (Okay, the three cool things about Jabber...) Combine a Jabber client with an HTML-renderer and you've got an ideal "universal client" for certain classes of application.
sounds like Sun was very stupid and Thomson was very cunning.
Or that Thomson is plain lying about the licensing rules having always been clear.
Given the recent change and the furor it generated, I'm inclined to the latter view myself.
Actually it was Java's success that caused many of the problems you mention.
When introduced, Java had (and still does) many things going for it: portability ("write once, run everywhere" be damned, in those days most developers were happy if you could even write once, compile anywhere); immunity from the causes of zillions of programmer-hours of debug time and crashed C/C++ programs (with garbage collection and run-time checks on array bounds, etc.); elimination of huge design headaches (and cause of yet more bugs and problems by less-than-expert developers) by going to multiple inheritence only of interface, not implementation, and by elminating operator overloading.
All these wonderful attributes triggered a huge surge in Java's popularity -- with corresponding demands on Sun's time to both fix existing problems and to extend it and standardize new APIs. Basically, Sun couldn't keep up with the demand.
Now that Sun has had a few years to catch up, and the Java Community Process has expanded the base of people to work on the above problems and and extensions, the Java platform is -- as you point out -- a pretty decent application platform.
Microsoft didn't kill Java on the client. [...] Java was sitting on the edge of its coffin. All Microsoft did was use its toe to push it in.
"Your Honor, my client did not kill the victim. Why, he crawled out on that ledge all by himself and was ready to jump. All my client did was give him a little push."
Microsoft didn't kill anything. Why in God's name do you need cross-platform compatibility when 98% of the client world runs on the same platform?!
"Your Honor, my client didn't kill anyone. Why, she would have died of old age eventually anyway!"
Okay, bucko, that's SIX times now you've posted that same excerpt from the EULA. Can we get some (-1, Redundant) modification in here?
Oh, and to answer your question: "you explicitly authorize Microsoft or its designated agent to access and utilize the necessary information for updating purposes."
Note that that says NOTHING about how they will access the information. By the letter of the EULA, they'd be within their rights (which you authorized) to just have a couple of goons march into your computer room and haul the machine back to Redmond for them to update there.
Improbable? Sure. But you explicitly authorized "access", period, not "access over a network connection using a specified protocol on a specified port".
Remember, this is Microsoft legalese we're talking about -- their view of contracts (of wich the EULA is one) is that anything not expressly forbidden to them is allowed.
1.Asteroids that will hit us are not travelling straight at us. [...] In fact, an asteroid coming straight along our line of sight would almost surely miss us.
Nope. The concern is the net vector, not the individual vectors of Earth and asteroid. For it to hit us, the net vector has to be toward us -- therefore straight along our line of sight. Same principle flying or driving -- the vehicles that are moving relative to a spot on the windshield are not the ones you have to worry about, it's the ones that look like a spot on the windshield (and getting bigger) that are the ones that'll hit. (Ditto for side windows.)
Now, if you're talking about months or years in advance, then yes, because of the curvature of the orbits it won't be on a direct vector at that time. Just when it's too close to do much about it.
Then you can ask mean questions to see how far their depth goes ("You can't use the keyword synchronized on a static method. Why?")
The problem with questions like that is that you come across looking stupid to someone who does know their stuff. (You can use the keyword synchronized on a static method.) You might lose your best candidates right there -- not because they can't answer the question, but because they won't want to work for a bozo.
I had a co-worker who liked to ask a really obscure technical question (typically something about determining the convex hull bounding a set of points in 3-space), not to see if they knew the answer, but to see how they reacted to the question. If you tried to bullshit your way through it, you were out. An honest "I don't have any idea, but here's how I'd research it" type answer was about as good as actually knowing what he was talking about (the question had nothing to do with the kind of work) and giving a technically correct answer.
Xenix
Sold it to SCO, actually. And yes, it was their (MS's) first operating system. Then they came out with DOS. Then Windows.
The trend does not look good...
Be that as it may, the fact remains that several versions of Windows contain an "ftp.exe" that includes (if you run 'strings' on it) the string "Copyright (c) 1983 The Regents of the University of California."
That doesn't come from merely "working from the reference implementation".
Heh, wondered if that would get a comment.
The answer is "yes".
could make X anywhere from 12% to 37% faster on the average platform
So, did you just pull those numbers out of your asterisk, or can you actually point to some analysis to back that up?
Even assuming that were true, on most machines (ie, anything better than a 386 with 4 MB memory), the difference won't be noticeable because even a 200% improvement in event response is lost in the noise of human reaction/perception times.
U Waterloo has always been in the computer industry's pockets, it seems. Back in the 80's it was IBM, now it's Microsoft. Ho hum. UW does produce good engineers, but they tend not to think outside the box. (Which may not be a quality you want in all your engineers, anyway.)
(Disclaimer: while I've never attended UW, I used to live a block from campus, my (now ex-) wife worked there, and I once worked at a company where there were only two other (out of about fifty) non-UW grads on the tech staff. I also worked at the computer center of another university a few miles down the road from UW, we were pretty familiar with things at that campus.)
VirtualPC for Mac [...] No-one wants PC-DOS,
Well, not quite no-one. My wife's Mac has VirtualPC with DOS 3.3 on it, and a 30 MB image file of the hard drive from her 286 AT-clone that we scrapped years ago (actually, I replaced the mobo and drive and it was my first Linux machine). There are a couple of old Q&A databases and a bunch of Write files on there that, every once in a while (like, a couple of years between uses), it's useful to refer to.
A lot easier than going to the hassle of converting the data to a more modern format -- although I should probably do that one of these days.
AND WHAT ARE THEY DOING SPENDING $600 ON A HAMMER???
It's $10 for the hammer, $590 for the paperwork to go with it. And no, I'm not kidding (although the exact numbers may be off).
A friend of mine who worked at Martin-Marietta (before it merged with Lockheed) told me a story about a case of duct tape. Seems that some govt agency -- either NASA or Air Force, I don't remember the details -- needed to buy some duct tape. Now, government purchasing regulations (at the time, they're a tiny bit more sane now) required that purchases favor American-made goods, from companies that are Equal Opportunity Employers, etc, etc. This required paperwork to prove that the goods are American made, by EOE companies, etc. Let's face it, most hardware stores can't be bothered with that sort of nonsense (this is why Home Depot has refused for years to sell to the feds).
So this gov't agency gave Martin-Marietta a contract to find an appropriate supplier of duct tape and do the investigation required to fill out the paperwork. Not that big a deal, probably took somebody a few days of phone calls, letters and checking around. But that time and expenses get rolled into the cost of the duct tape -- result, one case of duct tape at about $200 a roll.
Your government at work, making sure they do what's good for the taxpayer, no matter how much of the taxpayers' money they have to spend to do it.
Wow, I'd never heard of that. Thanks for the link.
Interesting use of hologram technology, too -- although sounds like a bit of a kludge. It's almost like combining a movie viewer with a video camera so you can play movies on your TV -- the difference being that the holotapes were mechanically stamped from a master (like the hologram stickers on credit cards and Microsoft license stickers), rather than chemically-processed photographic film, so they'd be much cheaper.
I think largely it was a chicken-and-egg problem. None of the major browser players included VRML as a native format (sure, there were plugins, but people hate downloading plugins) because there wasn't much content. And the content providers weren't interested because it wasn't natively supported by any of the major browsers.
Now, if things had gone a little differently in the browser wars (which were peaking around the time VRML might have taken off), and one of the major browser vendors had rolled in VRML (or included a plugin) instead of trying to come up with yet another non-standard HTML tag, we might all be viewing Slash3D.
Perhaps it's just as well...
Which reminds me...
The Moon is slowly getting a little bit further from Earth with each orbit (has to do with gravitational effects of tidal bulges, but I digress). Knowing the rate (carefully determined by measurments using the laser reflectors left on the Moon by the Apollo missions), we can extrapolate backwards to determine that, approximately 65 million years ago, the Moon orbited at a distance of about 35 feet.
Which explains the extinction of the dinosaurs.
Or at least, the tall ones.
Constraints are the source of genius.
Absolutely. It's easy to do something if there are no limits.
As for Cinelerra being destined for HDTV, I'd have to agree that it has the capability to go there.
Actually I wrote designed for HDTV -- and I see you agree with that.
Destined for? Who knows. As you say, not many folks out there shooting HD video these days. As for free -- I believe that Heroine Virtual has a package they sell that includes support and/or hardware. They've had a booth at the National Broadcasters Exhibition in the past. (This info gleaned from past versions of their web site, I have no personal contact with them, and my own involvement with video technology has been on the custom tape production side, not broadcast. Hence my interest in modifying the product (whether Premiere or Cinerella or whatever), so that I could automate production of a tape from a library of clips without ever having to use the GUI.)