I presume that MS will try to break compatibility the way they did with Win32s to put an end to new Windows apps running seamlessly under OS/2. To that extent, the original posters have a point. Do the WINE developers have plans to deal with such actions?
Why not? Because I don't want any of my money to go to support the Evil Empire. Admittedly, using WINE has the potential of miscommunicating my wishes to the market--if I buy a Windows app, I'm encouraging the current bogus situation. I expect to stick to freeware and, if absolutely necessary, used software, though, to avoid doing anything to reward people who write Windows apps.
I hope that's a troll. Man has tinkered with the natural order of things for millions of years; seeing someone use a computer (probably by artificial light, given the time) to post rants against "tinkering with the natural order" is dumbfounding in its inconsistency. I'm all for tinkering with the natural order of things--we just need to do a better job of it.
Having said that, um...so when can we expect the giant women?:-)
Katz has put a huge pile of issues in a blender and somehow wants to label the melange American corporatism, and label trade protectionism as "American"? Sorry, but I don't get it.
I'm sorry, but it doesn't speak too well for the SDK if it not only requires Red Hat, but a specific release of Red Hat--OK, I could understand requiring version x.y or later, but this... I can't say I feel inclined to drop back a release, bringing back a list of known bugs and security holes, to accomodate the SDK. I guess we'll see whether Amiga/Tao can get rid of whatever it is that's tied to a specific version of a specific distribution of Linux.
Amazing. Got the SDK today. I have Red Hat 6.2. Installation went without a hitch, but intent_shell and intent_media both hang. This is not an impressive beginning.
Just got a copy of the SDK, and I'm looking over the license agreement. One thing of interest: if you write and distribute a "Value Added Solution" (would that be an application?), then you agree to pay Amiga max($3 * # copies sold, 10% of gross revenue) each quarter, and also send them a report each quarter on what you've distributed, and keep records that they can audit at will. You can ask for permission to distribute a "Value Added Solution" as freeware.
Re:A long slippery slope down to Hell
on
Frankenstein Time
·
· Score: 1
I should know better than to reply to such a blatant troll, but: [enormous sigh] here we go again with the old, bogus "playing God" objection. People "play God" all the time; what this line really means is that some new technology is coming up, and the writer doesn't like it for that reason, unlike all the old methods of "playing God" that he's used to now (but that his ancestors berated with exactly the same pointless line).
I'll bite. What about the US do you think makes us "ill-prepared" to deal with genetic engineering technology? Oh, I don't know, could it be...what little freedom we have left? </Church Lady> Seriously, what country do you think is better able to handle it?
The canonical place to look for explorations of the consequences of technology is, of course, SF.
I'm not sure whom I trust less: governments, organizations such as Microsoft, or apparently well-meaning folks wanting to suppress knowledge a la Bill Joy.
I think the foot picture was intentional, to record the incongruity of the footwear and the rest of the outfit. I would say that a goodly number of the photos are <PC>differently focused and lit </PC>, though.
Remember, at most one person should send a grit heater as a wedding gift...
Hmmm...that's a good point. Having everyone's data in a centralized location would mean that they not only could upgrade the app to use an incompatible format, but could make sure everyone's data were upgraded too, to make absolutely sure that anyone attempting to write a program interoperable with a MS app is screwed. Of course, that would be advertised as a feature.
I have to admit that I still like the way Lloyd Biggle, Jr. put it: given a bunch of people stuck in the bottom of a sewer, mainstream literature will describe in great detail those who remain; SF will write about those trying to get out. (And if you're out there somewhere, Mr. Biggle, thanks for "The Tunesmith," The Still, Small Voice of Trumpets, and the anthology from which the above approximate quote comes; they helped me get through adolescence without deciding to stay in the sewer.)
So, are we talking vo-tech school here, or serious programming? If you just teach the language or tool du jour, the student will be lost when the Next Big Thing comes along. I had enough of those courses that had impressive titles but really turned out to be "Syntax of [fill in the blank]," and would prefer that others not waste their time. What's important are the underlying principles, and the best vehicle for those might not be whatever is currently fashionable.
I agree that PL/I is easier to learn than C++...but it was the huge, all-singing, all-dancing, shove together a huge pile of every possible feature language of its time. Implicit conversion from anything to anything, with very counterintuitive results--the standard example is 25 + 5 / 3, where the rules for FIXED DECIMAL arithmetic preserve less significant digits at the expense of more significant digits. A sleazily-typed language like C, maybe more so, since PL/I has a single POINTER type. (I guess the BASED storage attribute implemented stacks for you, but I never actually used it.)
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
Hmmm. By that logic, the proper teaching language is assembly language. I wouldn't wish C++ as a teaching language on anybody, but not because it hides a von Neumann machine model of computation from the user.
MS has the money to burn, and to them it's worth more to have Bungie not writing games for non-MS platforms than anything Bungie might ever write for them.
Re:x86 is popular to hate, but not that bad really
on
Is The x86 Obsolete?
·
· Score: 1
Those are two different things. Both are outdated; we know how to do things far better now. Both remain, and have layer upon layer piled on them, for the sake of backwards compatibility, because (almost) nobody wants to bite the bullet and make a large switch. (Of course, that applies to software as well, vide the continued existence of Windows and JCL.)
Re:x86 is popular to hate, but not that bad really
on
Is The x86 Obsolete?
·
· Score: 1
I beg to differ. Try shifting, dividing, unsigned multiplication, string operations, I/O operations, the countdown loop operations, LAHF...all require special registers. (Let's not even think about the RPN calculator nature of the floating point instructions, OK?) If you're worried about code size--and the varying length instruction encoding indicates that somebody is--then a diligent generator of code will note that there are special shorter encodings for some instructions when one of the operands happens to be the "accumulator" (al/ax/eax). I admit that the 80386 et seq. are not as horrible as their predecessors, but they're by no means orthogonal.
Slashdot Mirror
I presume that MS will try to break compatibility the way they did with Win32s to put an end to new Windows apps running seamlessly under OS/2. To that extent, the original posters have a point. Do the WINE developers have plans to deal with such actions?
Why not? Because I don't want any of my money to go to support the Evil Empire. Admittedly, using WINE has the potential of miscommunicating my wishes to the market--if I buy a Windows app, I'm encouraging the current bogus situation. I expect to stick to freeware and, if absolutely necessary, used software, though, to avoid doing anything to reward people who write Windows apps.
Having said that, um...so when can we expect the giant women? :-)
Katz has put a huge pile of issues in a blender and somehow wants to label the melange American corporatism, and label trade protectionism as "American"? Sorry, but I don't get it.
Hmmm...evidently it's Red Hat that has the problem, so it's time to go pester Red Hat. I apologize to Amiga and Tao.
I'm sorry, but it doesn't speak too well for the SDK if it not only requires Red Hat, but a specific release of Red Hat--OK, I could understand requiring version x.y or later, but this... I can't say I feel inclined to drop back a release, bringing back a list of known bugs and security holes, to accomodate the SDK. I guess we'll see whether Amiga/Tao can get rid of whatever it is that's tied to a specific version of a specific distribution of Linux.
Amazing. Got the SDK today. I have Red Hat 6.2. Installation went without a hitch, but intent_shell and intent_media both hang. This is not an impressive beginning.
Just got a copy of the SDK, and I'm looking over the license agreement. One thing of interest: if you write and distribute a "Value Added Solution" (would that be an application?), then you agree to pay Amiga max($3 * # copies sold, 10% of gross revenue) each quarter, and also send them a report each quarter on what you've distributed, and keep records that they can audit at will. You can ask for permission to distribute a "Value Added Solution" as freeware.
I should know better than to reply to such a blatant troll, but: [enormous sigh] here we go again with the old, bogus "playing God" objection. People "play God" all the time; what this line really means is that some new technology is coming up, and the writer doesn't like it for that reason, unlike all the old methods of "playing God" that he's used to now (but that his ancestors berated with exactly the same pointless line).
I'll bite. What about the US do you think makes us "ill-prepared" to deal with genetic engineering technology? Oh, I don't know, could it be...what little freedom we have left? </Church Lady> Seriously, what country do you think is better able to handle it?
I'm not sure whom I trust less: governments, organizations such as Microsoft, or apparently well-meaning folks wanting to suppress knowledge a la Bill Joy.
Remember, at most one person should send a grit heater as a wedding gift...
Hmmm...that's a good point. Having everyone's data in a centralized location would mean that they not only could upgrade the app to use an incompatible format, but could make sure everyone's data were upgraded too, to make absolutely sure that anyone attempting to write a program interoperable with a MS app is screwed. Of course, that would be advertised as a feature.
Looks like for all the nonmusicians the C# has gone flat.
The reason is that the Constitution prohibits states from imposing tariffs on interstate trade, IIRC.
Get a life!
I'm trying to hang on to the life I have; it's just that the government keeps taking more of it all the time.
I have to admit that I still like the way Lloyd Biggle, Jr. put it: given a bunch of people stuck in the bottom of a sewer, mainstream literature will describe in great detail those who remain; SF will write about those trying to get out. (And if you're out there somewhere, Mr. Biggle, thanks for "The Tunesmith," The Still, Small Voice of Trumpets, and the anthology from which the above approximate quote comes; they helped me get through adolescence without deciding to stay in the sewer.)
So, are we talking vo-tech school here, or serious programming? If you just teach the language or tool du jour, the student will be lost when the Next Big Thing comes along. I had enough of those courses that had impressive titles but really turned out to be "Syntax of [fill in the blank]," and would prefer that others not waste their time. What's important are the underlying principles, and the best vehicle for those might not be whatever is currently fashionable.
That's why Paul Hudek wrote The Haskell School of Expression. I'm looking forward to digging into Haskell with this book.
I agree that PL/I is easier to learn than C++...but it was the huge, all-singing, all-dancing, shove together a huge pile of every possible feature language of its time. Implicit conversion from anything to anything, with very counterintuitive results--the standard example is 25 + 5 / 3, where the rules for FIXED DECIMAL arithmetic preserve less significant digits at the expense of more significant digits. A sleazily-typed language like C, maybe more so, since PL/I has a single POINTER type. (I guess the BASED storage attribute implemented stacks for you, but I never actually used it.)
Hmmm. By that logic, the proper teaching language is assembly language. I wouldn't wish C++ as a teaching language on anybody, but not because it hides a von Neumann machine model of computation from the user.
Sigh...I wish I could rate that both as "flamebait" and "insightful." I'll go put on my "C++:C::PL/I:FORTRAN" T-shirt instead. :-)
I have to disagree. MS doing anything significant for Linux legitimates it in people's minds, and that's something MS will avoid at all costs.
MS has the money to burn, and to them it's worth more to have Bungie not writing games for non-MS platforms than anything Bungie might ever write for them.
Those are two different things. Both are outdated; we know how to do things far better now. Both remain, and have layer upon layer piled on them, for the sake of backwards compatibility, because (almost) nobody wants to bite the bullet and make a large switch. (Of course, that applies to software as well, vide the continued existence of Windows and JCL.)
I beg to differ. Try shifting, dividing, unsigned multiplication, string operations, I/O operations, the countdown loop operations, LAHF...all require special registers. (Let's not even think about the RPN calculator nature of the floating point instructions, OK?) If you're worried about code size--and the varying length instruction encoding indicates that somebody is--then a diligent generator of code will note that there are special shorter encodings for some instructions when one of the operands happens to be the "accumulator" (al/ax/eax). I admit that the 80386 et seq. are not as horrible as their predecessors, but they're by no means orthogonal.