Assuming everything else (like, raw materials) were completely free, somebody still has to pay the electric bill...
Also practice, simple economics would mean that the price of "Ethiopian compost" and other suitable raw materials would rise due to increased demand.
That's not to say it wouldn't have some interesting economic effects, though. Totally different classes of products would potentially become convertable...
The NT lineage kernels owe their design to VMS, not Unix. This was largely a consequence of Microsoft hiring Dave Cutler, one of VMS's architects.
There are commandline tools in most windows versions (e.g. ftp, ping, etc) that DO have a definite BSD lineage, but it doesn't go very deep. Superficial similarities do not deeper borrowing make.
Microsoft's justification (not, I think, their real primary reason) for licensing was actually the rather misnamed Windows services for Unix.
(Which, by the way, consists in large part of GPLed software... and, yes, Microsoft has indeed scrupulously obeyed the terms of the GPL, in case you were wondering.)
Probably not; certainly not here. One of the effects of the Industrial Revolution was to consume nearly all of the accessible (with Industrial Revolution or earlier technology) mineral resources.
Industrialization can really only ever happen once in a planet's history.
Actually, believe it or not Luna's orbit is also more influenced by the Sun than the Earth -- if you trace out its path relative to the Sun, it makes an ellipse, not a... bleah, forget the name of the shape. Anyway, there aren't any loops in evidence.
From a mathematical standpoint, it would be more appropriate to say that Luna orbits the Sun, rather than that it orbits the Earth.
That said, the Earth+Luna system still has a combined center of gravity which lies beneath the Earth's surface, so in that sense at least Luna is still Earth's satelite.
I wish the grandparent poster would bother posting something more informative than simple assertions.
In the strictest sense, he is correct. SQL is based on relational calculus, but manages to mangle it pretty badly.
Suffice to say that employing many relational concepts in SQL is not really possible, and SQL makes the remainder a lot more complicated than they need to be.
this thread manages to cover the bases, I think...
I'm coming at this from the perspective of someone whose relevent background here is mostly in monolithic SVG editor applications, and I guess my biases are showing.
It is, however, too late to amend the XML specification to address those concerns, so an optimizied local format is the best an application can do.
Agreed. And, also, I think the optimized local format needs a very different design from XML's.
My criticisms in the GP do apply to most of the "binary XML" proposals that have been made, because they do little more than replace string tokens with shorter bit sequences, retaining the bad random-access characteristics of XML.
I erroneously thought that was where you were coming from too, and also I obviously didn't think about the log time thing very carefully.
Animation is certainly part of our charter. At the moment our architectural changes aren't directed at animation specifically, though they should make animation easier to implement.
I'm not expecting to see any serious movement on animation for another few quarters yet (there's still some serious design work to do in that area), but OTOH my colleagues keep surprising me, so you never know... ^_^
That isn't really true -- the binary format does save you some parsing work, but that's about it.
Traversing down into the tree is still going to be logarithmic time, at best -- in most real applications you will have to visit the parent nodes to get relevent context information. Unless you've got an index of each node's children in there, you'll still have to resort to some linear scanning...
That's assuming you work directly with the data in serialized form, though, which is not generally a realistic assumption.
Any application using XML data interactively is going to parse the file _once_, into an AST, and use that instead of parsing/writing text over and over. As a result, the application's performance will be dominated by the performance characteristics of the AST representation, not the deserialization costs of the original data.
Binary formats make more sense for e.g. streaming situations, since there you're spending the majority of your time serializing/deserializing data rather than doing transformations on it (i.e. constructing an AST in those cases would be a waste of effort).
Also, in a case where Federal Law and treaties conflict, the most recently enacted wins.
Whether Federal Law trumps State Law in all cases is a different (and interesting) question.
[ Someone please correct me if I'm wrong, I've gotten myself in trouble in this area before. The below is my understanding though... ]
In theory any powers not explicitly granted the Federal government by the constitution are reserved for the states. An exception is made for issues of interstate commerce, so in practice everything is pretty much done under that banner.
That, and since the States take a lot of Federal money, the Federal government can effectively just say "Do what we say, or we're taking away your allowance."
As a developer who just participated in a large fork of a GPLed project (Inkscape from Sodipodi), I would concur it most certainly does permit (and encourage) forking.
I do generally use the GPL on my own code as well; I figure if someone can do a better job managing a project built around it than I can, they should go for it.
Forking at some level is actually very common, but a lot of the little forks are more civil and come and go, and generally get re-integrated.
Emacs/XEmacs and gcc/egcs are just the most famous and "hostile" (and actually, egcs was re-integrated after a fashion... it effectively ended up replacing the old gcc project and took its name). I can think of a _lot_ of other examples too.
It can be implemented on top of X, but that doesn't stop stupid coders who wrote SWF code on Win32 getting HWINs and the like and using pinvoke to access Win32 directly because that's they way they were used to doing something.
A non-negligable amount of people's SWF code does that, sadly.
Even in C, if you want to you can catch SIGSEGV and silently keep running/attempt some recovery. Free software programmers rightly have some aversion to this, but it's common enough in the commercial world.
What you describe is also a problem for Unix applications that are separated into several processes -- ignore SIGCHLD if something bad happens, and you get the precise same symptoms you describe. I've seen that happen quite a bit in Free Software. If you don't have exceptions, you have to get very religious about checking _every_ return value or you will write bad code.
It's really just about appropriateness of error handling on the part of the programmer. There are some errors that the program absolutely should not try to continue after, and others that don't invalidate the state of the process.
In general exceptions are nicer than crashes because they give you more choices than "UNKNOWN STATE MUST DIE" (SIGSEGV/SIGBUS) and "oh, that didn't work" (an [sadly often unchecked] return value), so it becomes pratical to make things like failure to open a file a slightly "harder" error that can't be silently ignored without explicit effort on the part of the programmer.
Exceptions are also nice in that they can be used to carry descriptive error messages. I wish more programmers took advantage of that.
So, in short, all the problems you describe are due to poor error handling practices on the part of the programmer, and already occur all too frequently in C.
It turns out most S.W.F client code relies too much on poking around "behind the scenes" way of pinvoke badness and the like that there needs to be a real Win32 implementation behind it.
(which is also why Microsoft is backing off of S.W.F themselves; the whole point of them going with.NET was so they could cast off the shackles of Win32 backwards-compatability, for good and bad reasons both)
That said, mono is in fact working on a S.W.F implementation in conjunction with Wine.
Slashdot Mirror
That was what that choreographed bit was depicting, though.
It was bad enough without having accidentally turned from the "stage kiss" version into the real thing.
Most Americans I've talked to don't so much love freedom as take it for granted...
Assuming everything else (like, raw materials) were completely free, somebody still has to pay the electric bill...
Also practice, simple economics would mean that the price of "Ethiopian compost" and other suitable raw materials would rise due to increased demand.
That's not to say it wouldn't have some interesting economic effects, though. Totally different classes of products would potentially become convertable...
The NT lineage kernels owe their design to VMS, not Unix. This was largely a consequence of Microsoft hiring Dave Cutler, one of VMS's architects.
... and, yes, Microsoft has indeed scrupulously obeyed the terms of the GPL, in case you were wondering.)
There are commandline tools in most windows versions (e.g. ftp, ping, etc) that DO have a definite BSD lineage, but it doesn't go very deep. Superficial similarities do not deeper borrowing make.
Microsoft's justification (not, I think, their real primary reason) for licensing was actually the rather misnamed Windows services for Unix.
(Which, by the way, consists in large part of GPLed software
Common fencepost error. Twelve regenerations means thirteen incarnations, as you correctly note.
You're probably understating it a little:
s/orbit/orbits/
s/one of the smaller satellites/large chunks of one of the smaller satellites/
Probably not; certainly not here. One of the effects of the Industrial Revolution was to consume nearly all of the accessible (with Industrial Revolution or earlier technology) mineral resources.
Industrialization can really only ever happen once in a planet's history.
Actually, believe it or not Luna's orbit is also more influenced by the Sun than the Earth -- if you trace out its path relative to the Sun, it makes an ellipse, not a ... bleah, forget the name of the shape. Anyway, there aren't any loops in evidence.
From a mathematical standpoint, it would be more appropriate to say that Luna orbits the Sun, rather than that it orbits the Earth.
That said, the Earth+Luna system still has a combined center of gravity which lies beneath the Earth's surface, so in that sense at least Luna is still Earth's satelite.
Actually the horseshoe shape is only its path relative to Earth. Its path relative to the sun is much more mundane.
Actually, there are probably more informative links. That's the best I could do with a quick googling (I'm at work) though.
I wish the grandparent poster would bother posting something more informative than simple assertions.
In the strictest sense, he is correct. SQL is based on relational calculus, but manages to mangle it pretty badly.
Suffice to say that employing many relational concepts in SQL is not really possible, and SQL makes the remainder a lot more complicated than they need to be.
this thread manages to cover the bases, I think...
Like when turning.
Actually if you don't mind making reeeeeeealllly slow turns it's not too bad, but you do have to be very careful at those speeds.
MD5 is standardized and portable.
Perhaps some of the utilities you are using consider file metadata when generating the checksum?
Also beware of implicit conversions being done to your data by your I/O libraries, as other posters have noted.
This is true.
I'm coming at this from the perspective of someone whose relevent background here is mostly in monolithic SVG editor applications, and I guess my biases are showing.
Agreed. And, also, I think the optimized local format needs a very different design from XML's.
My criticisms in the GP do apply to most of the "binary XML" proposals that have been made, because they do little more than replace string tokens with shorter bit sequences, retaining the bad random-access characteristics of XML.
I erroneously thought that was where you were coming from too, and also I obviously didn't think about the log time thing very carefully.
Animation is certainly part of our charter. At the moment our architectural changes aren't directed at animation specifically, though they should make animation easier to implement.
I'm not expecting to see any serious movement on animation for another few quarters yet (there's still some serious design work to do in that area), but OTOH my colleagues keep surprising me, so you never know... ^_^
...and of course, XDR is primarily used for situations where serialization/deserialization costs dominate (i.e. RPC).
You'll notice it's the RPC folks who are most interested in a binary XML representation.
That isn't really true -- the binary format does save you some parsing work, but that's about it.
Traversing down into the tree is still going to be logarithmic time, at best -- in most real applications you will have to visit the parent nodes to get relevent context information. Unless you've got an index of each node's children in there, you'll still have to resort to some linear scanning...
That's assuming you work directly with the data in serialized form, though, which is not generally a realistic assumption.
Any application using XML data interactively is going to parse the file _once_, into an AST, and use that instead of parsing/writing text over and over. As a result, the application's performance will be dominated by the performance characteristics of the AST representation, not the deserialization costs of the original data.
Binary formats make more sense for e.g. streaming situations, since there you're spending the majority of your time serializing/deserializing data rather than doing transformations on it (i.e. constructing an AST in those cases would be a waste of effort).
This is correct.
Also, in a case where Federal Law and treaties conflict, the most recently enacted wins.
Whether Federal Law trumps State Law in all cases is a different (and interesting) question.
[ Someone please correct me if I'm wrong, I've gotten myself in trouble in this area before. The below is my understanding though... ]
In theory any powers not explicitly granted the Federal government by the constitution are reserved for the states. An exception is made for issues of interstate commerce, so in practice everything is pretty much done under that banner.
That, and since the States take a lot of Federal money, the Federal government can effectively just say "Do what we say, or we're taking away your allowance."
As a developer who just participated in a large fork of a GPLed project (Inkscape from Sodipodi), I would concur it most certainly does permit (and encourage) forking.
... it effectively ended up replacing the old gcc project and took its name). I can think of a _lot_ of other examples too.
I do generally use the GPL on my own code as well; I figure if someone can do a better job managing a project built around it than I can, they should go for it.
Forking at some level is actually very common, but a lot of the little forks are more civil and come and go, and generally get re-integrated.
Emacs/XEmacs and gcc/egcs are just the most famous and "hostile" (and actually, egcs was re-integrated after a fashion
Actually it's because the XFree86 project never bothered to implement X11 backing stores properly.
Hopefully X.org/freedesktop.org will rectify this.
OS X ships with an X server by default now.
It can be implemented on top of X, but that doesn't stop stupid coders who wrote SWF code on Win32 getting HWINs and the like and using pinvoke to access Win32 directly because that's they way they were used to doing something.
A non-negligable amount of people's SWF code does that, sadly.
...or paint it with rocket fuel, for that matter.
That's just a choice of the programmer, though.
Even in C, if you want to you can catch SIGSEGV and silently keep running/attempt some recovery. Free software programmers rightly have some aversion to this, but it's common enough in the commercial world.
What you describe is also a problem for Unix applications that are separated into several processes -- ignore SIGCHLD if something bad happens, and you get the precise same symptoms you describe. I've seen that happen quite a bit in Free Software. If you don't have exceptions, you have to get very religious about checking _every_ return value or you will write bad code.
It's really just about appropriateness of error handling on the part of the programmer. There are some errors that the program absolutely should not try to continue after, and others that don't invalidate the state of the process.
In general exceptions are nicer than crashes because they give you more choices than "UNKNOWN STATE MUST DIE" (SIGSEGV/SIGBUS) and "oh, that didn't work" (an [sadly often unchecked] return value), so it becomes pratical to make things like failure to open a file a slightly "harder" error that can't be silently ignored without explicit effort on the part of the programmer.
Exceptions are also nice in that they can be used to carry descriptive error messages. I wish more programmers took advantage of that.
So, in short, all the problems you describe are due to poor error handling practices on the part of the programmer, and already occur all too frequently in C.
It turns out most S.W.F client code relies too much on poking around "behind the scenes" way of pinvoke badness and the like that there needs to be a real Win32 implementation behind it.
.NET was so they could cast off the shackles of Win32 backwards-compatability, for good and bad reasons both)
(which is also why Microsoft is backing off of S.W.F themselves; the whole point of them going with
That said, mono is in fact working on a S.W.F implementation in conjunction with Wine.