Samba *does not use Microsoft's APIs*. It does not call Net$whatever() and the like. It's an independent implementation of the same specifications (to the extent that the *real* specifications can be divined). That has nothing to do with a specific collection of functions and their parameter lists.
"Imposing antitrust liability on the basis of product enhancements and imposing 'code removal' remedies may produce unintended consequences," Pate said. "Sound antitrust policy must avoid chilling innovation and competition even by 'dominant' companies. A contrary approach risks protecting competitors, not competition, in ways that may ultimately harm innovation and the consumers that benefit from it."
This is a very interesting quote, as it can be read two ways. I agree that we should avoid chilling innovation and competition even by 'dominant' companies, and Microsoft has been doing an excellent job of chilling innovation and competition by trying to lock everyone else out. It's time to put a stop to that.
It is actually related to the stack, but the result is not much like a stack trace. You get *explanations*, not addresses. I guess you could think of it as a "semantic traceback".
Fine for you. I *hate* friendly goop. Gimme power.
The computer is not my friend; it is a tool. I do not want to be its best buddy, but its master. And that argues for a UI somewhat different from one aimed at people who seem to secretly believe that the computer is the master.
I *love* app.s that look like they've been designed by programmers. I don't find myself always running into things that I should be able to do, but which I have no power to express to the program. I can chain them together and make the app. that I really wanted. I'm not forever having to slap down "are you sure?" dialogs -- if I wasn't sure, I wouldn't have commanded it!
Indeed, XP looks very fetching after I turn off the wallpaper, set it for classic window decorations, and turn off the swoopy "effects". Deselect all of the "hide stuff Bill doesn't want me to think about" switches in Explorer and it's usable too.
The problem is getting people to chunk at the right level. For example, in the real world, I could look all 'round the room for that CD, but it's way easier to just ask for it by name of someone who knows where it is.
The computer knows where to find everything you put into it, and what those things' names are. That's a large part of what it's for. Don't bother yourself with hunting through stacks or arrays of stuff; ask the computer where it is.
I'm reminded of the guy with the photographic memory who uses the well known trick of "taking a walk" in his mind and placing things he wants to know along an imaginary street. Only *this* guy's imagery is so realistic that if he puts the thing to be remembered in a shadow, he may not be able to find it later. The basic ability is useful, but in this case its very perfection (in terms of being just like the real world) is unuseful.
I don't want a UI to be just like the real world; I want it to be *better*.
So how is that better than "just shove it off to one side"? If it's in my way, I pick it up and move it out of my way. That's one of the things about the desktop paradigm that *works*.
BTW I've never seen this "normal" roll-it-up-like-a-blind thing on *my* Linux box. I click the little downward-pointing triangle and the window disappears, replaced by a little picture in the area I've designated for icons. I guess you're not using the "normal" Linux window manager, FVWM.:-)
Oh, yeah, and I once saw a *really* cool WM where you could shrink the window to just a tiny button with its *name* on it! I think it was TWM.:-)
[You are at a complex junction. There is a point here.]
Time to hear from the VMS fanboy again. If you want to see what error messages *should* be, find a way to make a VMS application fail. Paraphrased, a typical VMS error stack might look like this:
"I couldn't open that window you asked for"
"because I couldn't initialize SOME-SUBSYSTEM"
"because I couldn't read SOME-SPECIFIC-FILE"
"because you are denied access to it"
Sure beats the stuffing out of "OUT OF MEMORY" or "invalid parameter". You could think of it as various layers of the program catching the error and re-throwing it with annotations. Each layer contributes its "understanding" of the failure and, if it is well done, the user gets the complete story of what went wrong and usually has enough information to understand and correct the problem without diving into the books.
Wasn't that some sort of covert op. to drive someone insane? It sounds like this could do it. A large part of my satisfaction with my virtual desktop is all the ways in which it does *not* work like the real one.
My guess is that this is one of those kewl things that have to be done, even though the market will wind up saying "no, thanks." I'm happy that the people who think it's important are getting a chance to do it.
I think the point was that if you see an attachment which turns out to be a virus, chances are extremely good that it's a Windows-specific virus and thus nonviable on Linux (or anything else that doesn't use MZ executable format).
Mind you, I don't *rely* solely on that. There is malware for other OSes. Anybody else remember CHRISTMA EXEC (VM/CMS)? or WANK (VMS)? But the current population statistics for malware in the wild do make it a lot easier for Linux fans to sleep.
I always wonder when I see that seemingly redundant expression. I mean, what would a hardware program look like?
Okay, *theoretically* there could be a need to distinguish a computer program from, say, a TV program or a spending program or a concert program, but really, how likely is it that a computer programmer is threatening an information service company with information about who's playing second violin tonight?
Notice that the planets are not powered either, so their influences are also predictable. They add some fuzz to estimated paths, but we can cope with that. (I'm not up to date on the current status of the N-Body Problem -- it may be that all feasible methods are estimates. Nevertheless we should be able to come up with a reasonable watch list and schedule.)
A more serious objection is that I hadn't realized this was all done visually. Somehow I thought we ran regular radar surveys or something. Maybe we should start.
If there's a net positive result *at all* then it's better than no profit at all, and we have to put the rock *somewhere*. Besides, compare the effort to recover iron from a nickel-iron asteroid to the effort involved in recovering the same amount from a pile of taconite hiding under a mountain. High-grade iron ore is becoming harder to find, and nearly-free metal has been unavailable, short of tapping the core, for aeons. Consider also the relative environmental impact (which can be expressed in dollars, if you wish) of the two operations. Maybe the economics don't work in our favor, but maybe they do -- we should find out.
And in the longer term, construction projects *in space* would do well to consider consuming the more bothersome asteroids, since they are the *only* source of iron and nickel that doesn't have to be dragged out of a planetary gravity well.
After all, if you're gonna talk about astroengineering, the first thing you gotta do is *think big*.
Actually I think I'd prefer a nice chassis with multichannel AV centerplane, into which I can plug mix'n'match blades for broadcast TV tuning, broadcast radio tuning, cable, satellite, control of the switching fabric, general input buffers, output buffers, etc. as needed. Add a nice amp, some speakers, and a dumb monitor with no tuner or audio at all, plus the usual ever-growing pile of AV sources in various media, and you'd have a nice setup that can view on one channel, record on another, feed different streams to different rooms, etc. without any duplication.
Nah, since they're *monkeys*, they'd be smart enough, once they've escaped and reached the Millennium Falcon, to just nuzzle the ship up to the entryport force-field and turn the main reaction thrusters on full. A couple of tW of directed energy ought to gut a Death Star quite handily.
Imperial Stormtroopers in the boat bay, you say? I don't see any now.
Then they fly out through the wreckage and go collect their medals from the Princess.
Well, if they give us 10-20 years' warning (which is not at all absurd, given that these rocks are not under power and thus utterly predictable) we can mount an expedition to deflect the thing, crush it to small pieces that shouldn't cause serious trouble, or just mine it out of existence.
(Hey, a few megatons of nickel-iron might not make us all rich, but it could defray at least *some* of the expense of saving our lives. Cost recovery is good.)
Well, I *just said* that I'm not annoyed by normal small static banner ad.s. I took out Flash, which has no purpose I can see other than to make advertising more distracting, and that took care of 95% of the annoyances without *adding* anything.
I'm wondering how much more stuff I could take out, and never miss it, and improve my experience by toning down the ad.s some more. Probably all that audio gunk I never use would be the best place to start. Then read up on the replaceable Java security monitor class and see what Java features I can turn off or conditionalize. Hmmm, this could actually be fun.
"You are looking at a web page, with links leading off in *all* directions.
"But you are still harboring and shielding students from their illegal actions...."
Sez who? You are talking about two different situations, and they call for different strategies:
o Student shares stuff he is allowed to share. It becomes popular and sucks lots of bandwidth. Limiting his bandwidth ensures that some is available for others. Blanket port blocking is not necessary.
o Student shares stuff he is not allowed to share. Content owner complains. You disable student's network drop and inform him why. It is now his problem, and he won't get his drop back until he satisfies you that there will be no more illegal content coming through it. Blanket port blocking is not necessary.
The problem people are having with your approach is that you try to lump the careless and the criminal together and treat them the same way.
Actually the correct answer is "not until the entertainment industry understands this." Otherwise the U's lawyers are going to keep trying to nix P2P in order to keep their clients out of trouble, whether said trouble actually makes sense or not.
Samba *does not use Microsoft's APIs*. It does not call Net$whatever() and the like. It's an independent implementation of the same specifications (to the extent that the *real* specifications can be divined). That has nothing to do with a specific collection of functions and their parameter lists.
"Imposing antitrust liability on the basis of product enhancements and imposing 'code removal' remedies may produce unintended consequences," Pate said. "Sound antitrust policy must avoid chilling innovation and competition even by 'dominant' companies. A contrary approach risks protecting competitors, not competition, in ways that may ultimately harm innovation and the consumers that benefit from it."
This is a very interesting quote, as it can be read two ways. I agree that we should avoid chilling innovation and competition even by 'dominant' companies, and Microsoft has been doing an excellent job of chilling innovation and competition by trying to lock everyone else out. It's time to put a stop to that.
It is actually related to the stack, but the result is not much like a stack trace. You get *explanations*, not addresses. I guess you could think of it as a "semantic traceback".
"Router MTBF increased by 50%"
:-)
So, at least something improved.
Fine for you. I *hate* friendly goop. Gimme power.
The computer is not my friend; it is a tool. I do not want to be its best buddy, but its master. And that argues for a UI somewhat different from one aimed at people who seem to secretly believe that the computer is the master.
I *love* app.s that look like they've been designed by programmers. I don't find myself always running into things that I should be able to do, but which I have no power to express to the program. I can chain them together and make the app. that I really wanted. I'm not forever having to slap down "are you sure?" dialogs -- if I wasn't sure, I wouldn't have commanded it!
Indeed, XP looks very fetching after I turn off the wallpaper, set it for classic window decorations, and turn off the swoopy "effects". Deselect all of the "hide stuff Bill doesn't want me to think about" switches in Explorer and it's usable too.
The problem is getting people to chunk at the right level. For example, in the real world, I could look all 'round the room for that CD, but it's way easier to just ask for it by name of someone who knows where it is.
The computer knows where to find everything you put into it, and what those things' names are. That's a large part of what it's for. Don't bother yourself with hunting through stacks or arrays of stuff; ask the computer where it is.
I'm reminded of the guy with the photographic memory who uses the well known trick of "taking a walk" in his mind and placing things he wants to know along an imaginary street. Only *this* guy's imagery is so realistic that if he puts the thing to be remembered in a shadow, he may not be able to find it later. The basic ability is useful, but in this case its very perfection (in terms of being just like the real world) is unuseful.
I don't want a UI to be just like the real world; I want it to be *better*.
So how is that better than "just shove it off to one side"? If it's in my way, I pick it up and move it out of my way. That's one of the things about the desktop paradigm that *works*.
:-)
:-)
BTW I've never seen this "normal" roll-it-up-like-a-blind thing on *my* Linux box. I click the little downward-pointing triangle and the window disappears, replaced by a little picture in the area I've designated for icons. I guess you're not using the "normal" Linux window manager, FVWM.
Oh, yeah, and I once saw a *really* cool WM where you could shrink the window to just a tiny button with its *name* on it! I think it was TWM.
[You are at a complex junction. There is a point here.]
Time to hear from the VMS fanboy again. If you want to see what error messages *should* be, find a way to make a VMS application fail. Paraphrased, a typical VMS error stack might look like this:
"I couldn't open that window you asked for"
"because I couldn't initialize SOME-SUBSYSTEM"
"because I couldn't read SOME-SPECIFIC-FILE"
"because you are denied access to it"
Sure beats the stuffing out of "OUT OF MEMORY" or "invalid parameter". You could think of it as various layers of the program catching the error and re-throwing it with annotations. Each layer contributes its "understanding" of the failure and, if it is well done, the user gets the complete story of what went wrong and usually has enough information to understand and correct the problem without diving into the books.
Wasn't that some sort of covert op. to drive someone insane? It sounds like this could do it. A large part of my satisfaction with my virtual desktop is all the ways in which it does *not* work like the real one.
My guess is that this is one of those kewl things that have to be done, even though the market will wind up saying "no, thanks." I'm happy that the people who think it's important are getting a chance to do it.
Of course that's very nearly the same list as the list of file types that most people want to attach for perfectly legitimate reasons.
I think the point was that if you see an attachment which turns out to be a virus, chances are extremely good that it's a Windows-specific virus and thus nonviable on Linux (or anything else that doesn't use MZ executable format).
Mind you, I don't *rely* solely on that. There is malware for other OSes. Anybody else remember CHRISTMA EXEC (VM/CMS)? or WANK (VMS)? But the current population statistics for malware in the wild do make it a lot easier for Linux fans to sleep.
A hollow voice says, "Pine."
(or Elm/mutt/etc.)
I always wonder when I see that seemingly redundant expression. I mean, what would a hardware program look like?
Okay, *theoretically* there could be a need to distinguish a computer program from, say, a TV program or a spending program or a concert program, but really, how likely is it that a computer programmer is threatening an information service company with information about who's playing second violin tonight?
Notice that the planets are not powered either, so their influences are also predictable. They add some fuzz to estimated paths, but we can cope with that. (I'm not up to date on the current status of the N-Body Problem -- it may be that all feasible methods are estimates. Nevertheless we should be able to come up with a reasonable watch list and schedule.)
A more serious objection is that I hadn't realized this was all done visually. Somehow I thought we ran regular radar surveys or something. Maybe we should start.
If there's a net positive result *at all* then it's better than no profit at all, and we have to put the rock *somewhere*. Besides, compare the effort to recover iron from a nickel-iron asteroid to the effort involved in recovering the same amount from a pile of taconite hiding under a mountain. High-grade iron ore is becoming harder to find, and nearly-free metal has been unavailable, short of tapping the core, for aeons. Consider also the relative environmental impact (which can be expressed in dollars, if you wish) of the two operations. Maybe the economics don't work in our favor, but maybe they do -- we should find out.
And in the longer term, construction projects *in space* would do well to consider consuming the more bothersome asteroids, since they are the *only* source of iron and nickel that doesn't have to be dragged out of a planetary gravity well.
After all, if you're gonna talk about astroengineering, the first thing you gotta do is *think big*.
Yes, I am.
Actually I think I'd prefer a nice chassis with multichannel AV centerplane, into which I can plug mix'n'match blades for broadcast TV tuning, broadcast radio tuning, cable, satellite, control of the switching fabric, general input buffers, output buffers, etc. as needed. Add a nice amp, some speakers, and a dumb monitor with no tuner or audio at all, plus the usual ever-growing pile of AV sources in various media, and you'd have a nice setup that can view on one channel, record on another, feed different streams to different rooms, etc. without any duplication.
(Did I mention that I'm a control freak?)
Maybe we'll be extremely lucky and it's locked on Hollywood instead.
Nah, since they're *monkeys*, they'd be smart enough, once they've escaped and reached the Millennium Falcon, to just nuzzle the ship up to the entryport force-field and turn the main reaction thrusters on full. A couple of tW of directed energy ought to gut a Death Star quite handily.
Imperial Stormtroopers in the boat bay, you say? I don't see any now.
Then they fly out through the wreckage and go collect their medals from the Princess.
Well, if they give us 10-20 years' warning (which is not at all absurd, given that these rocks are not under power and thus utterly predictable) we can mount an expedition to deflect the thing, crush it to small pieces that shouldn't cause serious trouble, or just mine it out of existence.
(Hey, a few megatons of nickel-iron might not make us all rich, but it could defray at least *some* of the expense of saving our lives. Cost recovery is good.)
Well, I *just said* that I'm not annoyed by normal small static banner ad.s. I took out Flash, which has no purpose I can see other than to make advertising more distracting, and that took care of 95% of the annoyances without *adding* anything.
I'm wondering how much more stuff I could take out, and never miss it, and improve my experience by toning down the ad.s some more. Probably all that audio gunk I never use would be the best place to start. Then read up on the replaceable Java security monitor class and see what Java features I can turn off or conditionalize. Hmmm, this could actually be fun.
"You are looking at a web page, with links leading off in *all* directions.
There is a Flash animation here.
There is a web bug here.
There is a cookie here.
>"
"But you are still harboring and shielding students from their illegal actions...."
Sez who? You are talking about two different situations, and they call for different strategies:
o Student shares stuff he is allowed to share. It becomes popular and sucks lots of bandwidth. Limiting his bandwidth ensures that some is available for others. Blanket port blocking is not necessary.
o Student shares stuff he is not allowed to share. Content owner complains. You disable student's network drop and inform him why. It is now his problem, and he won't get his drop back until he satisfies you that there will be no more illegal content coming through it. Blanket port blocking is not necessary.
The problem people are having with your approach is that you try to lump the careless and the criminal together and treat them the same way.
"...there is a no way of distinguishing between a legitimate torrent (of say, a Linux distro) and a torrent of "unauthorised copyright material"."
Sure, there is. The content owner will tell you which material is unauthorized.
Actually the correct answer is "not until the entertainment industry understands this." Otherwise the U's lawyers are going to keep trying to nix P2P in order to keep their clients out of trouble, whether said trouble actually makes sense or not.