That's like asking if Linux runs Photoshop or World of Warcraft.
It's in poor taste at the very least.;)
(not to mention that C++ is such an appallingly horrid language that no compiler with any sense of propriety would dream or admitting it knows about such things. One might as well ask if it's got a front end for Visual Basic. The very idea!)
Re:In the name of the user, make the user shave ya
on
The GIMP UI Redesign
·
· Score: 1
Rather, IMO, if the user needs different behavior from different apps, then the user needs to specify to the window manager which behavior it needs. Having the app do it is backwards.
Why? The user is not a computer expert. The user is a graphic artist.
Honestly, I don't understand what people's hangup about editing config files is.
I've been a command line guy for 30 years, so don't expect me to explain it. It doesn't matter what the hangup is, because whatever you or I think it's a good idea or not is irrelevant... it's a real hangup, and it has to be accommodated for free UNIX to succeed on the desktop.
In such a case, the user should request it [an unmanaged window] himself, without having to go through the app.
And yet in X11 THE APPLICATION REQUESTS IT, NOT THE USER. Look up overrideRedirect.
Where's the harm in that, anyhow?
Finding a couple years from now that the open source app you're looking at on freshmeat only runs on Windows.
I whole heartedly agree that music should be free, and not just belong to the artist but be free for all the fans to enjoy.
Nope, that's not what I said either.
I said that the artist should retain the rights. That they don't is due to the massive imbalance of power between the labels and the artists that the labels have built up over the years.
Music production and book production aren't that different, but authors don't have to sign over their rights forever to get published. At most they sign over a SPECIFIC set of publication rights for a SPECIFIC time. If book printing had started in the laissez-faire capitalism of the early 20th century, instead of growing along with copyright and related laws over the centuries prior, things would be different.
So the current legal situation is purely accident, bad luck for the artists, and there's no moral or ethical reason to treat it as a fait accompli rather than oppose it.
You shouldn't expect anymore than that when you sign with major record labels.
Just because it's in the contract, that doesn't mean it's not a legal fiction, or (in this case) that the baker isn't telling you to steal someone else's bread.
There's plenty of precedent for 'take it or leave it' contracts being nullified. There's plenty of precedent for unreasonable terms being overturned. So if you want to support that "baker" analogy you have to explain why this is not merely in the contract, but something that should be considered reasonable by the people you're talking to. Who, I might remind you, are slashdot readers.
But if you aren't even willing to TRY supporting it, you're just trolling.
Think about it. Getting a new compiler into free UNIX and the open source community is going to be as hard as getting a new platform on the desktop to compete with Windows. And for similar reasons.
You're not going to supplant GCC until you get all the code that depends on GCC-specific features modified to be standard portable C. That's a barrier to entry as steep as Microsoft's application barrier to entry. Now it's not as bad as it was in the early '90s when GCC was sprouting new C extensions everywhere (like the ability to have declarations not at the start of blocks, or the ability to leave the second element out of the trinary conditional operator, or things like alloca), and a lot of those features have now become common and even standardized (and others, like the shortcut trinary, have been deprecated). But it's not as easy as just having a good compiler, or even a good language translating ecosystem like Tendra... the playing field is anything but level.
Files from SpiralFrog are digitally protected and can be played on mp3 players, but cannot be burned to CDs.
If they can be played on MP3 players, they can be burned to CDs, and played on the iPod.
If they can't be burned to CDs, or played on the iPod, then they're not MP3 files, and whatever you're playing them on is something other than an MP3 player.
I assume they're WMA, these things usually are.
So this is basically just Rhapsody with even more restrictions. Not a story.
So you're all right with the fiction the labels use that artists are just working for hire and the labels really deserve to own the copyright to their music?
In the name of the user, make the user shave yaks!
on
The GIMP UI Redesign
·
· Score: 1
It's not supposed to be about what the app needs, but what the user needs.
That's a jesuitical argument if ever I read one. So let me try and put this in words that fit your bible: If the user needs different behavior from different apps, then the user needs the app to be able to specify which behavior it needs.
AFAIK, if by "select," you mean "select from a menu," then no.
No, I mean "select in any way, through any preference, in any window manager, anywhere." Not through writing a program in Scheme or other configuration language, or by editing a text file, but by doing something that the target market for the program (artists) would be expected to do when you're trying to convince them that they should be able to switch from Photoshop on Windows or Mac to Gimp on free UNIX.
And note that I am not saying that's the desirable situation. I'm saying that's the absolute most yak shaving I can imagine people being willing to put up with.
X supplies "mechanism, not policy."
I know. I thought that was a pretty cool idea too, 20 years ago, when I first ran into it. The flipside is that it means that the application and the window manager DO provide policy, for the parts of the interface that they're responsible for. So the fact that X doesn't is irrelevant, and that argument is a complete red herring. We're not arguing about whether X provides policy, we're arguing about whether the application or the window manager should be doing so in this case.
If the protocol doesn't allow the application to specify the policy the window manager should be implementing, then that's a flaw that needs to be addressed.
A user ought to be able to maintain a single set of configurations applicable to all applications (employing specific rules if neccessary), without worrying about certain apps not listening.
And if the user needs the application to request specific behavior (such as not having a title bar) then it can request it. The window manager may or may not grant that request, but IT CAN REQUEST IT. In this case the user needs the application be able to request whether a set of windows are to be treated as a unit for layering, because that's how the equivalent applications on Windows and Mac OS behave. If it can't do that, then the user has to go through a bunch of yak shaving... and they won't DO that. They'll stick to Photoshop on their Wintel boxes and Macs.
You are, in the name of the user, demanding the users that this whole argument is about NOT get what they need.
No, I don't surf with javascript disabled. I've read all the articles about how I should, haven't found them compelling. But I agree with you that it's reasonable to ask/. to put "warning: javascript required" on the article. You also should have made that your subject, so people reading here would get the picture quicker.:)
Can the app specify without ignoring the user's choices? I'm not sure.
If the app can't specify what it needs through the window manager, there's not much of an alternative.
The idea is that the app isn't supposed to care - it's supposed to be user-configurable.
If it is user-configurable, then the default behavior still needs to be the one that provides the most appropriate user interface, because most users will use the default. Hell, most users will probably never investigate whether there are alternatives. Therefore if the best default depends on the application, it must be specifiable by the application.
That's why Windows has MDI, and why the Mac has two kinds of child windows.
If there's no mechanism in the window manager to specify the right behavior, applications WILL do it in an ad-hoc fashion themselves. Especially in this case where I doubt very much that there's a way for the user to select "child windows are hidden unless a member of this group of windows has focus" in any window manager.
This is not a flaw unique to X11, by the way. There are analogues to this problem in every window system. And in every window system applications hack workarounds.
You know perfectly well that's a straw man. The two situations are, first, switching from one Linux distro to another and, second, switching from Windows to Linux. The difference in cost (or time and effort) between these two situations is enormous.
That is why I wrote that it was (comparatively) a more capable member of the product line than the intel one.
But neither has a full size hard drive and enough room in the case for proper cooling, and both have underpowered USB ports. I needed an external USB hub to even charge an iPod Shuffle from my mini.
Obviously they aren't going to set a hard limit. If they say everyone can download 90GB a month and everyone does that, their network will screech to a halt.
If they say everyone can download 30,000 songs... and everyone downloads 20,000 songs of 3MB each (60GB)... their network will screech to a halt too. Specifying the amount in terms like this doesn't protect them from people gaming the overcommitment level if everyone does it... what protects them is that most people have no interest in doing that, no matter what the level is.
And, you now, there's companies that have hard quota limits for services, AND overcommitment for quotas, AND they don't come to a screeching halt.
No, this kind of quota overcommitment is too common and too effective for this to be a reasonable argument against actually putting the limit in quantifiable terms.
Properly designed window managers not only know the difference between a parent window and a child window, they also allow the user to set both default and special behaviors for focus and layering, according to their own preferences.
The problem is that some applications need that relationship between parent and child windows, and others don't. Can the *application* request special behavior, so that in general it will get that behavior unless the user has requested otherwise, or is this yet another bit of yak shaving that people have to put up with if they don't want to just pay someone else to take care of it (one way or another) that drives people away from FOSS?
Focus behavior is (or is supposed to be) handled by the window manager, not the individual program. In Windows, giving the focus to a window doesn't bring all the windows belonging to that program forward.
A program, however, needs to maintain window layering and focus in an organized fashion in certain circumstances... such as in the case of child dialogs, particularly blocking child dialogs. If there is no way in the X11 window manager API to say that certain windows need to maintain a layering or focus relationship then the application has to be able to step in.
In Windows, this is handled by MDI, where the child windows are contained inside the parent window. In the Mac this is handled by shelves and sheets and panels. In X11, this is all too often handled by various ad-hoc rules in the application, which leads to conflicts with window managers, which leads to comments like the one above.
If multiple dependent windows really aren't acceptable, then use sidebars.
There's lots of evidence that isn't admissible but is still useful in an investigation. If X tells you that Y will be committing a crime at point A at time T, that's hearsay, not evidence. If X found out while burgling Y's office, that's even less useful. But you'd still have someone at point A and time T if you believe the odds are good that they'll be there.
How applicable that is for this case, well, how hard is it to look at DNS records and IP addresses?
Hey, I like Linux too, but there's nothing about open source software that prevents a software distributor from being able to do this exact same thing.
Assuming an open source software project tried this. What would happen?
* The code to download the update is published. They would have to risk having the backdoor discovered by someone working on the download code. Microsoft doesn't have that problem.
* The first time the code is used, and the unexpected downloads are detected, the downloader will be fixed and submitted back to the source. If they don't accept the change, it will be forked. They can't do the same thing a second time. Microsoft doesn't have that problem.
Microsoft could have released their source code prior to this update and still been just as able to install this upgrade on computers worldwide without user consent.
Assuming nobody noticed this exception in the code before the update, which is hardly something to depend on, they'd be able to fix it afterwards.
If the people who maintain the apt-get repositories wanted to install a program on practically every Ubuntu computer in the world, they could do it too.
But, and this is the key point, it would not be installed on the computers that had automatic updates disabled, unless there's a backdoor in apt-get.
Microsoft can still use this to sneak in a patch without notification and without permission.
Ubuntu might (and that's a might) be able to, once. But only once.
Slashdot Mirror
Just let the battery die. My iPod Shuffle's battery has died, but it still works fine on external power.
That's like asking if Linux runs Photoshop or World of Warcraft.
;)
It's in poor taste at the very least.
(not to mention that C++ is such an appallingly horrid language that no compiler with any sense of propriety would dream or admitting it knows about such things. One might as well ask if it's got a front end for Visual Basic. The very idea!)
Rather, IMO, if the user needs different behavior from different apps, then the user needs to specify to the window manager which behavior it needs. Having the app do it is backwards.
Why? The user is not a computer expert. The user is a graphic artist.
Honestly, I don't understand what people's hangup about editing config files is.
I've been a command line guy for 30 years, so don't expect me to explain it. It doesn't matter what the hangup is, because whatever you or I think it's a good idea or not is irrelevant... it's a real hangup, and it has to be accommodated for free UNIX to succeed on the desktop.
In such a case, the user should request it [an unmanaged window] himself, without having to go through the app.
And yet in X11 THE APPLICATION REQUESTS IT, NOT THE USER. Look up overrideRedirect.
Where's the harm in that, anyhow?
Finding a couple years from now that the open source app you're looking at on freshmeat only runs on Windows.
I whole heartedly agree that music should be free, and not just belong to the artist but be free for all the fans to enjoy.
Nope, that's not what I said either.
I said that the artist should retain the rights. That they don't is due to the massive imbalance of power between the labels and the artists that the labels have built up over the years.
Music production and book production aren't that different, but authors don't have to sign over their rights forever to get published. At most they sign over a SPECIFIC set of publication rights for a SPECIFIC time. If book printing had started in the laissez-faire capitalism of the early 20th century, instead of growing along with copyright and related laws over the centuries prior, things would be different.
So the current legal situation is purely accident, bad luck for the artists, and there's no moral or ethical reason to treat it as a fait accompli rather than oppose it.
You shouldn't expect anymore than that when you sign with major record labels.
Just because it's in the contract, that doesn't mean it's not a legal fiction, or (in this case) that the baker isn't telling you to steal someone else's bread.
There's plenty of precedent for 'take it or leave it' contracts being nullified. There's plenty of precedent for unreasonable terms being overturned. So if you want to support that "baker" analogy you have to explain why this is not merely in the contract, but something that should be considered reasonable by the people you're talking to. Who, I might remind you, are slashdot readers.
But if you aren't even willing to TRY supporting it, you're just trolling.
Think about it. Getting a new compiler into free UNIX and the open source community is going to be as hard as getting a new platform on the desktop to compete with Windows. And for similar reasons.
You're not going to supplant GCC until you get all the code that depends on GCC-specific features modified to be standard portable C. That's a barrier to entry as steep as Microsoft's application barrier to entry. Now it's not as bad as it was in the early '90s when GCC was sprouting new C extensions everywhere (like the ability to have declarations not at the start of blocks, or the ability to leave the second element out of the trinary conditional operator, or things like alloca), and a lot of those features have now become common and even standardized (and others, like the shortcut trinary, have been deprecated). But it's not as easy as just having a good compiler, or even a good language translating ecosystem like Tendra... the playing field is anything but level.
Files from SpiralFrog are digitally protected and can be played on mp3 players, but cannot be burned to CDs.
If they can be played on MP3 players, they can be burned to CDs, and played on the iPod.
If they can't be burned to CDs, or played on the iPod, then they're not MP3 files, and whatever you're playing them on is something other than an MP3 player.
I assume they're WMA, these things usually are.
So this is basically just Rhapsody with even more restrictions. Not a story.
What happens depends on the license. Can you fork Zimbra, or is the license effectively tied up with them?
If they've got proprietary control that can't be picked up by anyone willing to create a fork, it's not really open source in the BSD sense.
So you're all right with the fiction the labels use that artists are just working for hire and the labels really deserve to own the copyright to their music?
It's not supposed to be about what the app needs, but what the user needs.
That's a jesuitical argument if ever I read one. So let me try and put this in words that fit your bible: If the user needs different behavior from different apps, then the user needs the app to be able to specify which behavior it needs.
AFAIK, if by "select," you mean "select from a menu," then no.
No, I mean "select in any way, through any preference, in any window manager, anywhere." Not through writing a program in Scheme or other configuration language, or by editing a text file, but by doing something that the target market for the program (artists) would be expected to do when you're trying to convince them that they should be able to switch from Photoshop on Windows or Mac to Gimp on free UNIX.
And note that I am not saying that's the desirable situation. I'm saying that's the absolute most yak shaving I can imagine people being willing to put up with.
X supplies "mechanism, not policy."
I know. I thought that was a pretty cool idea too, 20 years ago, when I first ran into it. The flipside is that it means that the application and the window manager DO provide policy, for the parts of the interface that they're responsible for. So the fact that X doesn't is irrelevant, and that argument is a complete red herring. We're not arguing about whether X provides policy, we're arguing about whether the application or the window manager should be doing so in this case.
If the protocol doesn't allow the application to specify the policy the window manager should be implementing, then that's a flaw that needs to be addressed.
A user ought to be able to maintain a single set of configurations applicable to all applications (employing specific rules if neccessary), without worrying about certain apps not listening.
And if the user needs the application to request specific behavior (such as not having a title bar) then it can request it. The window manager may or may not grant that request, but IT CAN REQUEST IT. In this case the user needs the application be able to request whether a set of windows are to be treated as a unit for layering, because that's how the equivalent applications on Windows and Mac OS behave. If it can't do that, then the user has to go through a bunch of yak shaving... and they won't DO that. They'll stick to Photoshop on their Wintel boxes and Macs.
You are, in the name of the user, demanding the users that this whole argument is about NOT get what they need.
A fine example of using multiple accounts to add an air of legitimacy to your mindless waste of bandwidth.
Not me, spod. I don't have any sock puppets here. Want to explain what made you think I did, 'cos I don't see it.
Interesting hack.
/. to put "warning: javascript required" on the article. You also should have made that your subject, so people reading here would get the picture quicker. :)
No, I don't surf with javascript disabled. I've read all the articles about how I should, haven't found them compelling. But I agree with you that it's reasonable to ask
mod topic down overrated? :)
Can the app specify without ignoring the user's choices? I'm not sure.
If the app can't specify what it needs through the window manager, there's not much of an alternative.
The idea is that the app isn't supposed to care - it's supposed to be user-configurable.
If it is user-configurable, then the default behavior still needs to be the one that provides the most appropriate user interface, because most users will use the default. Hell, most users will probably never investigate whether there are alternatives. Therefore if the best default depends on the application, it must be specifiable by the application.
That's why Windows has MDI, and why the Mac has two kinds of child windows.
If there's no mechanism in the window manager to specify the right behavior, applications WILL do it in an ad-hoc fashion themselves. Especially in this case where I doubt very much that there's a way for the user to select "child windows are hidden unless a member of this group of windows has focus" in any window manager.
This is not a flaw unique to X11, by the way. There are analogues to this problem in every window system. And in every window system applications hack workarounds.
Windows users can switch to Linux today
You know perfectly well that's a straw man. The two situations are, first, switching from one Linux distro to another and, second, switching from Windows to Linux. The difference in cost (or time and effort) between these two situations is enormous.
That is why I wrote that it was (comparatively) a more capable member of the product line than the intel one.
But neither has a full size hard drive and enough room in the case for proper cooling, and both have underpowered USB ports. I needed an external USB hub to even charge an iPod Shuffle from my mini.
Obviously they aren't going to set a hard limit. If they say everyone can download 90GB a month and everyone does that, their network will screech to a halt.
If they say everyone can download 30,000 songs... and everyone downloads 20,000 songs of 3MB each (60GB)... their network will screech to a halt too. Specifying the amount in terms like this doesn't protect them from people gaming the overcommitment level if everyone does it... what protects them is that most people have no interest in doing that, no matter what the level is.
And, you now, there's companies that have hard quota limits for services, AND overcommitment for quotas, AND they don't come to a screeching halt.
No, this kind of quota overcommitment is too common and too effective for this to be a reasonable argument against actually putting the limit in quantifiable terms.
Beg pardon, I assumed that ffmpeg was working from a spec rather than reverse-engineering the format.
Properly designed window managers not only know the difference between a parent window and a child window, they also allow the user to set both default and special behaviors for focus and layering, according to their own preferences.
The problem is that some applications need that relationship between parent and child windows, and others don't. Can the *application* request special behavior, so that in general it will get that behavior unless the user has requested otherwise, or is this yet another bit of yak shaving that people have to put up with if they don't want to just pay someone else to take care of it (one way or another) that drives people away from FOSS?
You assume that users care, or even understand what you're talking about
No sir. I'm saying that with Windows EVEN IF YOU CARE, you can't do anything, because you can't find out.
With open source, you CAN protect yourself in ways that you can't with a closed source system.
The mini is actually more expensive and comparatively (in terms of their product line) less powerful than the original Mac mini when it came out.
They need a mini "pro". Full sized hard drive, enough room inside for decent cooling, full power USB ports, a real GPU.
Focus behavior is (or is supposed to be) handled by the window manager, not the individual program. In Windows, giving the focus to a window doesn't bring all the windows belonging to that program forward.
A program, however, needs to maintain window layering and focus in an organized fashion in certain circumstances... such as in the case of child dialogs, particularly blocking child dialogs. If there is no way in the X11 window manager API to say that certain windows need to maintain a layering or focus relationship then the application has to be able to step in.
In Windows, this is handled by MDI, where the child windows are contained inside the parent window. In the Mac this is handled by shelves and sheets and panels. In X11, this is all too often handled by various ad-hoc rules in the application, which leads to conflicts with window managers, which leads to comments like the one above.
If multiple dependent windows really aren't acceptable, then use sidebars.
There's lots of evidence that isn't admissible but is still useful in an investigation. If X tells you that Y will be committing a crime at point A at time T, that's hearsay, not evidence. If X found out while burgling Y's office, that's even less useful. But you'd still have someone at point A and time T if you believe the odds are good that they'll be there.
How applicable that is for this case, well, how hard is it to look at DNS records and IP addresses?
There are many good reasons why people who build mission critical systems steer clear of Microsoft OSes
Oh, were that only true.
Hey, I like Linux too, but there's nothing about open source software that prevents a software distributor from being able to do this exact same thing.
Assuming an open source software project tried this. What would happen?
* The code to download the update is published. They would have to risk having the backdoor discovered by someone working on the download code. Microsoft doesn't have that problem.
* The first time the code is used, and the unexpected downloads are detected, the downloader will be fixed and submitted back to the source. If they don't accept the change, it will be forked. They can't do the same thing a second time. Microsoft doesn't have that problem.
Microsoft could have released their source code prior to this update and still been just as able to install this upgrade on computers worldwide without user consent.
Assuming nobody noticed this exception in the code before the update, which is hardly something to depend on, they'd be able to fix it afterwards.
If the people who maintain the apt-get repositories wanted to install a program on practically every Ubuntu computer in the world, they could do it too.
But, and this is the key point, it would not be installed on the computers that had automatic updates disabled, unless there's a backdoor in apt-get.
Microsoft can still use this to sneak in a patch without notification and without permission.
Ubuntu might (and that's a might) be able to, once. But only once.