I find such summarizations of interchanges much more enlightening and worthwhile than sanitized press releases. I learned more from that one email about the things I see wrong in Fedora than I've learned in the past 6 months.
That's not a very good excuse for writing a program that everybody (including me) dislikes using because it has a confusing interface.
Also, the word 'intuitive' is not being abused. That bolded statement there is true, but we're quickly filled with a whole host of mental tools for dealing with cultural artifacts (like image manipulation programs). New artifacts that we create should make use of those mental tools most people in that culture are equipped with. That's what 'intuitive' means in this context.
Have you ever built anything electronically more involved than an oscillator, with no instructions?
Yes, I built the circuitry for translating control signals from a joystick port into a robot's motor starting, stopping, or changing direction.
Building anything more complicated than that by the seat-of-your-pants counts as 'scratch' in my book. If you can take discrete components, some theory, and through an iterative [build, test, scratch head, fix, repeat] process build something that does what you set out to do, that is essentially scratch.
Interesting. The definition of 'from scratch' with software is much more nebulous, IMHO. And now with software radio, it's possible to build an HDTV with nothing but software.
Where's your benchmark from 'from scratch' then? Does the person have to start out naked in a forest. then build from there? I mean, there's an awful lot of manufacturing that goes into making a transistor, resistor, capacitor, or even a wire. Doesn't seem to me like using those should be thought of as 'from scratch'. You couldn't even really have gotten anything more than the wire 200 years ago.
Personally, I think the definition of 'from scratch' has to evolve over time to keep pace with the available tools.
I like them showing advertisements for movies. I don't watch TV, read the newspaper, or listen to the radio. So the only way I learn about new movies is word-of-mouth, the few news sites (like Slashdot) that I do look at, or movie trailers. I therefor consider the trailers a service.:-)
I don't think the guy should've been thrown in jail for the camcorder, he should've just been ejected.
I think actually that he should've been ejected from the theater, not sent to jail. It's not police-state behavior if the person who owns the theater is the person doing the spying, and it's not because any state agency is forcing or encouraging them to.
If the MPAA were requiring that theater owners have projectionists with night vision goggles, that would be a different thing, and I'd be more inclined to cry "Police state!".
So, shoplifting's fine because the proprietor has posted signs stating that shoplifting isn't allowed? There are little constracts we participate in. They're often contextual and implicit.
An excellent use of technology to catch a criminal. The contract for entering a movie theatre is clear about not having recording devices or food. It was so obviously wrong that even a projectionist had no qualms about wearing some night vision goggles to notice someone with a camera and eject them. This doesn't even need to invoke copyright law to be considered wrong.
That's not necessarily true. The style in which I write blog entries might not be as formal as I might use for a book, but it's not the style in which I speak either.
For some bizarre reason, some group of people thought this was flamebait. Perhaps they find the concept of someone not owning a TV too much for them or something.
I don't even have a TV to connect a console up to, and haven't had one in years. The idea of buying a piece of hardware just to play games on is mildly offensive to me. But the high levels of DRM (note, that I have purchased every single game I've played in the past 5 years) on them is extremely offensive to me.
So, no console games for me. If they can't make them for a PC (and preferably Linux) then, as far as I'm concerned, they don't exist.
I don't even have a TV to connect a console up to, and haven't had one in years. The idea of buying a piece of hardware just to play games on is mildly offensive to me. But the high levels of DRM (note, that I have purchased every single game I've played in the past 5 years) on them is extremely offensive to me.
So, no console games for me. If they can't make them for a PC (and preferably Linux), I don't need to play them.
I know this as well. The real place that these context switches (otherwise known as round-trip requests) kill you is when you have a remote X session. I expect that it could also start to be a problem on a UI with a lot of 'active' elements that woke up and did things whenever the mouse moved over them.
Also, the droppings temporarily left behind by a window you're dragging are also telling as that requires many applications to suddenly wake up and draw their little bits.
Lastly, the X event model seems to be something a lot of toolkits want to bypass. I've noticed several toolkits that decide that they want to recieve every mouse event in every window. The X server ends up deluging them with information every time the user moves the mouse across the screen. And that's also slow.
All of these things could be fixed if X had a way to securely run toolkit code in a local context. If you had a way to do that, you could even start implementing real window transparency and other fun tricks and still have it be responsive, even over a network.
Having real backing store, as the other poster mentioned, might be helpful. But, that feels to me like a kludgey solution that's not applicable in all cases (like the 'active' UI element case).
I like X11. But it has problems. I think it's better than most of the other solutions out there even. But that doesn't mean the problems shouldn't be addressed.
OK, yes, that's true, and that reduces context switches. And most people do not have dual processor machines, so the second thing, while true, is a special case at this point in time.
But, the basic problem is still there. In order for the user to see the visible effect of some action they perform, there has to be at least two context switches.
There is a way to accomplish it, but it's a little scary, and I'm not sure if it's at all a good idea. You can let clients send code to the server, and have the server execute the code in its own address space. That way, the client can upload a lot of the more common graphical tasks to the server and just trigger them with short commands. This would reduce context switching, and also lighten network load.
But, of course, it comes at the cost of possible security holes. A Java sandbox model type thing on the server side might help, but I'm skeptical.
You ARE a clueless idiot. Wow! I thought for a minute you might be an intelligent person temporarily masquerading as one. Or maybe you're just a troll.
What do you think XOrg is, but a solution to the problem you just stated? It's not like any Linux distributions with ship without an X11 implementation. That's pretty amazingly stupid to say.
No, actually, there is a performance loss because every graphics operation involves a context switch from the process to the X server, even if there is no copying from user space to kernel space and back again.
Also, there has been some internal strife with the XFree86 organization. From my external viewpoint, it seems like the people own largely control the organization are somewhat slow about changing things or adopting new ideas into XFree86.
XFree86, up to this point, has been a defining implementation of the X11 protocol. Most new things in the X11 protocol have come from the XFree86 project. But, I suspect that's no longer going to be the case.
To expand more helpfully on the previous poster's comment...
XFree86 and XOrg are both implementations of X11. X11 is technically a protocol, not a particular program. This is why X11 has persisted for so long despite repeated attempts to dislodge it. Everybody who tries to do something better forgets that X11 is a protocol, and that's actually why it's so popular. They usually end up implementing something that's an API, which is just all wrong.
The XOrg implementation of X11 is a fork of the XFree86 codebase, just before XFree86 changed its license to be not quite free enough for most people to be comfortable using it.
Slashdot Mirror
Wow, a sane comment! From an AC no less.
The easiest answer is actually to not run Windows.
Who put a broomstick up your behind?
I find such summarizations of interchanges much more enlightening and worthwhile than sanitized press releases. I learned more from that one email about the things I see wrong in Fedora than I've learned in the past 6 months.
That's not a very good excuse for writing a program that everybody (including me) dislikes using because it has a confusing interface.
Also, the word 'intuitive' is not being abused. That bolded statement there is true, but we're quickly filled with a whole host of mental tools for dealing with cultural artifacts (like image manipulation programs). New artifacts that we create should make use of those mental tools most people in that culture are equipped with. That's what 'intuitive' means in this context.
Yes, I built the circuitry for translating control signals from a joystick port into a robot's motor starting, stopping, or changing direction.
Building anything more complicated than that by the seat-of-your-pants counts as 'scratch' in my book. If you can take discrete components, some theory, and through an iterative [build, test, scratch head, fix, repeat] process build something that does what you set out to do, that is essentially scratch.
Interesting. The definition of 'from scratch' with software is much more nebulous, IMHO. And now with software radio, it's possible to build an HDTV with nothing but software.
Where's your benchmark from 'from scratch' then? Does the person have to start out naked in a forest. then build from there? I mean, there's an awful lot of manufacturing that goes into making a transistor, resistor, capacitor, or even a wire. Doesn't seem to me like using those should be thought of as 'from scratch'. You couldn't even really have gotten anything more than the wire 200 years ago.
Personally, I think the definition of 'from scratch' has to evolve over time to keep pace with the available tools.
Everything fits the Christian faith if you try hard enough.
I tried that. It was much funnier that way. :-) The Monty Python cast would've managed to sound cheerful and upbeat about it. :-)
Yeah, when you discover it violates the laws of thermodynamics, you can safely ignore it because it doesn't really exist. :-)
I agree. I won't go back to theaters that do that.
I like them showing advertisements for movies. I don't watch TV, read the newspaper, or listen to the radio. So the only way I learn about new movies is word-of-mouth, the few news sites (like Slashdot) that I do look at, or movie trailers. I therefor consider the trailers a service. :-)
I don't think the guy should've been thrown in jail for the camcorder, he should've just been ejected.
I think actually that he should've been ejected from the theater, not sent to jail. It's not police-state behavior if the person who owns the theater is the person doing the spying, and it's not because any state agency is forcing or encouraging them to.
If the MPAA were requiring that theater owners have projectionists with night vision goggles, that would be a different thing, and I'd be more inclined to cry "Police state!".
So, shoplifting's fine because the proprietor has posted signs stating that shoplifting isn't allowed? There are little constracts we participate in. They're often contextual and implicit.
An excellent use of technology to catch a criminal. The contract for entering a movie theatre is clear about not having recording devices or food. It was so obviously wrong that even a projectionist had no qualms about wearing some night vision goggles to notice someone with a camera and eject them. This doesn't even need to invoke copyright law to be considered wrong.
That's not necessarily true. The style in which I write blog entries might not be as formal as I might use for a book, but it's not the style in which I speak either.
For some bizarre reason, some group of people thought this was flamebait. Perhaps they find the concept of someone not owning a TV too much for them or something.
I don't even have a TV to connect a console up to, and haven't had one in years. The idea of buying a piece of hardware just to play games on is mildly offensive to me. But the high levels of DRM (note, that I have purchased every single game I've played in the past 5 years) on them is extremely offensive to me.
So, no console games for me. If they can't make them for a PC (and preferably Linux) then, as far as I'm concerned, they don't exist.
I don't even have a TV to connect a console up to, and haven't had one in years. The idea of buying a piece of hardware just to play games on is mildly offensive to me. But the high levels of DRM (note, that I have purchased every single game I've played in the past 5 years) on them is extremely offensive to me.
So, no console games for me. If they can't make them for a PC (and preferably Linux), I don't need to play them.
Slashdot has no IPv6 address. It would be pretty trivial for you to set one up too. All of my systems are on IPv6.
I know this as well. The real place that these context switches (otherwise known as round-trip requests) kill you is when you have a remote X session. I expect that it could also start to be a problem on a UI with a lot of 'active' elements that woke up and did things whenever the mouse moved over them.
Also, the droppings temporarily left behind by a window you're dragging are also telling as that requires many applications to suddenly wake up and draw their little bits.
Lastly, the X event model seems to be something a lot of toolkits want to bypass. I've noticed several toolkits that decide that they want to recieve every mouse event in every window. The X server ends up deluging them with information every time the user moves the mouse across the screen. And that's also slow.
All of these things could be fixed if X had a way to securely run toolkit code in a local context. If you had a way to do that, you could even start implementing real window transparency and other fun tricks and still have it be responsive, even over a network.
Having real backing store, as the other poster mentioned, might be helpful. But, that feels to me like a kludgey solution that's not applicable in all cases (like the 'active' UI element case).
I like X11. But it has problems. I think it's better than most of the other solutions out there even. But that doesn't mean the problems shouldn't be addressed.
OK, yes, that's true, and that reduces context switches. And most people do not have dual processor machines, so the second thing, while true, is a special case at this point in time.
But, the basic problem is still there. In order for the user to see the visible effect of some action they perform, there has to be at least two context switches.
There is a way to accomplish it, but it's a little scary, and I'm not sure if it's at all a good idea. You can let clients send code to the server, and have the server execute the code in its own address space. That way, the client can upload a lot of the more common graphical tasks to the server and just trigger them with short commands. This would reduce context switching, and also lighten network load.
But, of course, it comes at the cost of possible security holes. A Java sandbox model type thing on the server side might help, but I'm skeptical.
You ARE a clueless idiot. Wow! I thought for a minute you might be an intelligent person temporarily masquerading as one. Or maybe you're just a troll.
What do you think XOrg is, but a solution to the problem you just stated? It's not like any Linux distributions with ship without an X11 implementation. That's pretty amazingly stupid to say.
No, actually, there is a performance loss because every graphics operation involves a context switch from the process to the X server, even if there is no copying from user space to kernel space and back again.
Also, there has been some internal strife with the XFree86 organization. From my external viewpoint, it seems like the people own largely control the organization are somewhat slow about changing things or adopting new ideas into XFree86.
XFree86, up to this point, has been a defining implementation of the X11 protocol. Most new things in the X11 protocol have come from the XFree86 project. But, I suspect that's no longer going to be the case.
To expand more helpfully on the previous poster's comment...
XFree86 and XOrg are both implementations of X11. X11 is technically a protocol, not a particular program. This is why X11 has persisted for so long despite repeated attempts to dislodge it. Everybody who tries to do something better forgets that X11 is a protocol, and that's actually why it's so popular. They usually end up implementing something that's an API, which is just all wrong.
The XOrg implementation of X11 is a fork of the XFree86 codebase, just before XFree86 changed its license to be not quite free enough for most people to be comfortable using it.