Re:Any chance we can draw circles and boxes now
on
GIMP 2.6 Released
·
· Score: 1
Except Gimp is primarily an image manipulation program, not a drawing program. As an image manipulation program, ellipse select is a far more useful tool than ellipse drawing. Having two different ellipse tools would just be confusing.
On the other hand, in a program like Inkscape (which is a drawing program) the ellipse tool really is for drawing ellipses. They don't even have an ellipse selection tool.
Just look at your average business man. He goes to work while texting on his "Blackberry" and reading the newspaper in "Acrobat" format on his "Kindle". When he gets to work he checks in email on "Outlook" and prepares a presentation in "Powerpoint".
There's a certain amount of logic to giving your apps unique, memorable names, rather than using generic names. As contemptible as they are, Apple's iBrand manages to come up with names that are unique, memorable, and obvious. Granted, its brand power might be diluted if something like gPhoto became popular.
Polygonal support in the freehand select tool is a purely redundant feature in Gimp. For ages Gimp has had a competent paths tool, and you can create selections from paths.
the japanese pronunciation of which is more like "buruu" because of a lack of an L sound.
Eh, they don't really lack an L sound, but they do lack an L letter. Japanese Rs sound an awful lot like English Ls.
So if you wanted to write "blue" in (Romanized) Japanese, you would write it as "buruu", but it would sound more like "buluu" (and if you keep repeating it long enough it starts to sound like "baloo").
(For the discerning readers, I'm being simplistic; the Japanese R syllables do still have a little bit of the English R sound in them. Imagine trying to say R and L at the same time, followed by any vowel.)
Instead of looking at the rules of an artform, we should instead look at the piece as a whole; as we do for any other form of art.
That was exactly my point: if the "rules" don't support the piece of art as a whole, then the piece of art would be better expressed in a different medium.
But do mechanics of Prince of Persia (the "rules") actually benefit the game as a piece of art? The answer, I think, depends on what you mean by "art".
I generally put art in two categories: art as aesthetic, and it's more pretentious sibling, art as an exploration of the human condition; so called "high art".
(As a quick aside, despite the fact that I called high art pretentious, I think both kinds of art are very important. I also think that the best pieces of art fall in both categories.)
I think we can all agree that games easily count as aesthetic art. In Prince of Persia, the models, textures, animations, music, even the way the prince responds to your input is all very aesthetic. The story is a great representation of the aesthetic of the Arabian Nights. And most importantly, the aesthetic of each component works with every other component to create a cohesive work.
But what about high art? Well, an argument can be made for the story as high art. I don't actually think the games were intended to be more than entertainment, so this is going to require a bit of BS on my part, but let's say that the story is about our tenuous relationship with time. (I'm not going to go any deeper than that, because as I said, I'm just bull shitting here.)
The question is, do the other components of the game support that idea? Well, you can try to claim that the dagger supports the story, by giving the player direct control over time. A counter-argument could be made that the story is more pure without the distraction of the gameplay, but that's alright; the dagger is arguably important, and that's good enough.
It falls apart much further than that, though. The combat and acrobatic puzzles are hard to justify, as are their repetitive nature. Part of the reasons for these things are because of market expectations, but if we're going to take Prince of Persia as high art, then these things only serve to dilute the message.
The fact that we're this close with Prince of Persia (or Ico, or Portal...) is great, though! Sure, we don't have a Citizen Kane of videogames yet, but there's no reason such a thing is impossible. The key is going to be finding things to express that are more difficult to express with any other medium, and interactivity is going to be central to that endeavor. One of my favourite examples of this is the Tales of the Black Freighter portion of Watchmen, and how the story melds with the news-vendor's ramblings. This is a technique which would be, at best, very diluted if attempted in any other medium.
Re:Run with more threads than processors
on
Clean Code
·
· Score: 1
Let's look closer at what the OP wrote:
"Run with more threads than processors" to flush out problems.
So what you're saying is that you should run with more threads than processors, and you should do that to flush out problems, but the problems you should be trying to flush out with this technique should not be concurrency related?
I think you're misinterpreting the OP, because the best way to flush out non-concurrency-related problems would be to run in a single thread (or with no concurrency-related code at all if your framework supports that). That falls in the category of "fewer threads than processors". You may agree with the GP more than you realize >;)
Re:Run with more threads than processors
on
Clean Code
·
· Score: 2, Informative
+1 Insightful? More like -1 Poor Reading Comprehension.
If you have a quad-core machine and you run your app with three threads, then you're almost guaranteed that all of your threads will be running at once. On the other hand, if you're running with five threads, and thread #5 conflicts with thread #3, you may never notice that, because thread #5 could be sleeping the whole time.
And as the GP said, it's a good idea to test your code with more and less treads than the optimal number.
If there are alternatives and those alternatives do well (without the DRM) then I'm sure the message will come across loud and clear.
The music industry still makes the lions share of their money off of CD sales, a DRM-free medium, but that particular message hasn't seemed to make it through their thick skulls.
Clarification: when they say "lower priority", they mean "higher latency". It shouldn't noticeably affect streaming video or torrents, because those require high bandwidth, but not low latency. It's not the end of the world if you need to wait 5 seconds for your YouTube video to start streaming, as long as it doesn't pause to buffer while you're trying to watch the video.
On the other hand, VOIP and online games -- which don't require high bandwidth -- will benefit from better latency than they currently get. (As I understand it, the telcos have already been doing this for VOIP, but not in an unbiased way.)
This is actually a sudden outbreak of common sense. Of course, Comcast still has bandwidth caps, but that's nothing new if you were around in the days of dial-up. Dial-up was closer to a free market, though, which is how we ended up with unlimited bandwidth deals to begin with.
Up here in Canada, Bell has been forced to lease their bandwidth to third-party ISPs, and that helps (we probably have two dozen options for ISPs in Toronto) but it's not quite ideal.
Scenario 1: You've published a web page that lists the email addresses of several of your coworkers. Perhaps it's a corporate directory, or contact information for a project you're working on, or posts by multiple coworkers on a forum. Whatever. An email harvesting bot sees all these email addresses in the same place and assumes they might know each other.
Scenario 2: The email harvesting bot finds different email addresses on completely unrelated web pages, but since they share the same domain name, it assumes there's a chance that they know each other.
Scenario 3: The email harvesting bot finds your email address (sancho@example.com) on a web page and spams you with a list of common names in the From field. Even if there's a 3% chance that you know john@example.com, that's good enough for the spammers.
In short, there's plenty of ways for spammers to fake emails from people you know. And what's worse, without some sort of authentication, we don't know whether or not that persons machine is really compromised.
First of all, you only need to expose the business end of the keyboard, and I hope the staff are competent enough to notice when a student starts splicing wires the wires on the lab equipment. And since the wires in a keyboard cord are very fine, that kind of splice would fail pretty quickly unless the connection was soldered; if your lab monitors don't notice that, then they're retarded.
Not that I think it's likely this kid used a hardware keylogger. Or that he spliced any wires to install one. (Otherwise, we'd see something about damage to equipment in the story.)
Second, you can require a different form of login for privileged tasks. A username/password is fine for logins and email, but you need to enter your student number if you want to access anything that's more sensitive, like course registration and financial information. That way, if an account is compromised, it's not the end of the world.
Third, you can use some form of identification that doesn't go through the keyboard. Like, say, a key card. Only, here's the important part: don't put any identifying information on the key card. If the attacker can read your username off of the keycard, then it can be abused without even cloning the card. (Even better, of course, would be to use an RFID, since those would be exponentially harder to clone; oh, and make sure these kinds of logins only work from known hardware, obviously.)
Forth, there's all the things you can do to detect break-in attempts. Emailing failed login attempts to the admins' is a no-brainer. You should also ensure that you record login attempts, and you kick any user who has logged in twice. That way you'll get a report from a frustrated user who's getting booted, and you can find out that the same users has, apparently, logged in on the opposite side of the campus. Check your security footage, and you've caught the attacker.
If you want to get really fancy, your system can automatically check the physical distance between the two machines, and alert the admins when a login should be impossible. This is taking it a bit far for most purposes, but for a debit card and access to financial information, it's perfectly reasonable. This is important stuff, so even monitoring IP traffic to bring the admins' attention to atypical traffic (i.e. gigs of traffic sent to an unknown IP address) isn't out of the question.
There's also things you can do to your hardware design to make modifications obvious to the users. Around here, banks have put a translucent green piece of plastic on the ATMs so that an attacker can't surreptitiously install a mag stripe reader.
This is all stuff I've thought of in a couple of minutes, and a fraction of this stuff would have stopped the kid.
The idea that physical access to the machine implies security is impossible just makes for lazy IT workers. There's still lots you can do to make things difficult, or make break-in attempts apparent.
In most cases, people only need physical access to the keyboard, mouse, and monitor, and maybe a usb socket; the rest of the computer can be locked away.
It's also a cinch to prevent unauthorized users from installing software on any moderately competent operating system. Unauthorized users may still be able to run unauthorized software, but there's no way it would keep running when another students logs in.
When you're offering public terminals, it's also a good idea to ghost those terminals every morning, so that if somebody does compromise any of your machines, the damage is limited.
Any IT worker worth their salt should know these things.
Slashdot Mirror
Except Gimp is primarily an image manipulation program, not a drawing program. As an image manipulation program, ellipse select is a far more useful tool than ellipse drawing. Having two different ellipse tools would just be confusing.
On the other hand, in a program like Inkscape (which is a drawing program) the ellipse tool really is for drawing ellipses. They don't even have an ellipse selection tool.
I don't get what the big deal is. Hell, when I was a kid we actually had a class in home ec where the teacher taught us how to use gimps!
Just look at your average business man. He goes to work while texting on his "Blackberry" and reading the newspaper in "Acrobat" format on his "Kindle". When he gets to work he checks in email on "Outlook" and prepares a presentation in "Powerpoint".
There's a certain amount of logic to giving your apps unique, memorable names, rather than using generic names. As contemptible as they are, Apple's iBrand manages to come up with names that are unique, memorable, and obvious. Granted, its brand power might be diluted if something like gPhoto became popular.
Polygonal support in the freehand select tool is a purely redundant feature in Gimp. For ages Gimp has had a competent paths tool, and you can create selections from paths.
peaches to pears
Oh, come on. Peaches and pears aren't remotely comparable. Peaches are obviously better.
Have you ever heard of a pear cobbler? Can you name and princesses named after pears? No, of course not. Because pears can suck it.
(Mod insightful, please.)
Maybe so, but you don't speak real English, so it cancels out.
I liked my Virtual Boy, you insensitive clod.
Or they could have used a U for the first one, and a Double-U for the second one. It would go:
Uii
Wii
Wuii
Wwii
Actually, on second thought, the Japanese might not want to release a console called the WWII.
the japanese pronunciation of which is more like "buruu" because of a lack of an L sound.
Eh, they don't really lack an L sound, but they do lack an L letter. Japanese Rs sound an awful lot like English Ls.
So if you wanted to write "blue" in (Romanized) Japanese, you would write it as "buruu", but it would sound more like "buluu" (and if you keep repeating it long enough it starts to sound like "baloo").
(For the discerning readers, I'm being simplistic; the Japanese R syllables do still have a little bit of the English R sound in them. Imagine trying to say R and L at the same time, followed by any vowel.)
Video game players are computer savvy; I think that counts as predisposed.
Instead of looking at the rules of an artform, we should instead look at the piece as a whole; as we do for any other form of art.
That was exactly my point: if the "rules" don't support the piece of art as a whole, then the piece of art would be better expressed in a different medium.
But do mechanics of Prince of Persia (the "rules") actually benefit the game as a piece of art? The answer, I think, depends on what you mean by "art".
I generally put art in two categories: art as aesthetic, and it's more pretentious sibling, art as an exploration of the human condition; so called "high art".
(As a quick aside, despite the fact that I called high art pretentious, I think both kinds of art are very important. I also think that the best pieces of art fall in both categories.)
I think we can all agree that games easily count as aesthetic art. In Prince of Persia, the models, textures, animations, music, even the way the prince responds to your input is all very aesthetic. The story is a great representation of the aesthetic of the Arabian Nights. And most importantly, the aesthetic of each component works with every other component to create a cohesive work.
But what about high art? Well, an argument can be made for the story as high art. I don't actually think the games were intended to be more than entertainment, so this is going to require a bit of BS on my part, but let's say that the story is about our tenuous relationship with time. (I'm not going to go any deeper than that, because as I said, I'm just bull shitting here.)
The question is, do the other components of the game support that idea? Well, you can try to claim that the dagger supports the story, by giving the player direct control over time. A counter-argument could be made that the story is more pure without the distraction of the gameplay, but that's alright; the dagger is arguably important, and that's good enough.
It falls apart much further than that, though. The combat and acrobatic puzzles are hard to justify, as are their repetitive nature. Part of the reasons for these things are because of market expectations, but if we're going to take Prince of Persia as high art, then these things only serve to dilute the message.
The fact that we're this close with Prince of Persia (or Ico, or Portal...) is great, though! Sure, we don't have a Citizen Kane of videogames yet, but there's no reason such a thing is impossible. The key is going to be finding things to express that are more difficult to express with any other medium, and interactivity is going to be central to that endeavor. One of my favourite examples of this is the Tales of the Black Freighter portion of Watchmen, and how the story melds with the news-vendor's ramblings. This is a technique which would be, at best, very diluted if attempted in any other medium.
Oh, come on. Live a little.
I L'edOL..
Let's look closer at what the OP wrote:
"Run with more threads than processors" to flush out problems.
So what you're saying is that you should run with more threads than processors, and you should do that to flush out problems, but the problems you should be trying to flush out with this technique should not be concurrency related?
I think you're misinterpreting the OP, because the best way to flush out non-concurrency-related problems would be to run in a single thread (or with no concurrency-related code at all if your framework supports that). That falls in the category of "fewer threads than processors". You may agree with the GP more than you realize >;)
+1 Insightful? More like -1 Poor Reading Comprehension.
If you have a quad-core machine and you run your app with three threads, then you're almost guaranteed that all of your threads will be running at once. On the other hand, if you're running with five threads, and thread #5 conflicts with thread #3, you may never notice that, because thread #5 could be sleeping the whole time.
And as the GP said, it's a good idea to test your code with more and less treads than the optimal number.
If there are alternatives and those alternatives do well (without the DRM) then I'm sure the message will come across loud and clear.
The music industry still makes the lions share of their money off of CD sales, a DRM-free medium, but that particular message hasn't seemed to make it through their thick skulls.
Clarification: when they say "lower priority", they mean "higher latency". It shouldn't noticeably affect streaming video or torrents, because those require high bandwidth, but not low latency. It's not the end of the world if you need to wait 5 seconds for your YouTube video to start streaming, as long as it doesn't pause to buffer while you're trying to watch the video.
On the other hand, VOIP and online games -- which don't require high bandwidth -- will benefit from better latency than they currently get. (As I understand it, the telcos have already been doing this for VOIP, but not in an unbiased way.)
This is actually a sudden outbreak of common sense. Of course, Comcast still has bandwidth caps, but that's nothing new if you were around in the days of dial-up. Dial-up was closer to a free market, though, which is how we ended up with unlimited bandwidth deals to begin with.
Up here in Canada, Bell has been forced to lease their bandwidth to third-party ISPs, and that helps (we probably have two dozen options for ISPs in Toronto) but it's not quite ideal.
Scenario 1: You've published a web page that lists the email addresses of several of your coworkers. Perhaps it's a corporate directory, or contact information for a project you're working on, or posts by multiple coworkers on a forum. Whatever. An email harvesting bot sees all these email addresses in the same place and assumes they might know each other.
Scenario 2: The email harvesting bot finds different email addresses on completely unrelated web pages, but since they share the same domain name, it assumes there's a chance that they know each other.
Scenario 3: The email harvesting bot finds your email address (sancho@example.com) on a web page and spams you with a list of common names in the From field. Even if there's a 3% chance that you know john@example.com, that's good enough for the spammers.
In short, there's plenty of ways for spammers to fake emails from people you know. And what's worse, without some sort of authentication, we don't know whether or not that persons machine is really compromised.
That's not exactly a solution to the problem. I think we all agree that doing customer support through a web form sucks.
Exactly. Luckily, people are working on devices that don't require glasses.
First of all, you only need to expose the business end of the keyboard, and I hope the staff are competent enough to notice when a student starts splicing wires the wires on the lab equipment. And since the wires in a keyboard cord are very fine, that kind of splice would fail pretty quickly unless the connection was soldered; if your lab monitors don't notice that, then they're retarded.
Not that I think it's likely this kid used a hardware keylogger. Or that he spliced any wires to install one. (Otherwise, we'd see something about damage to equipment in the story.)
Second, you can require a different form of login for privileged tasks. A username/password is fine for logins and email, but you need to enter your student number if you want to access anything that's more sensitive, like course registration and financial information. That way, if an account is compromised, it's not the end of the world.
Third, you can use some form of identification that doesn't go through the keyboard. Like, say, a key card. Only, here's the important part: don't put any identifying information on the key card. If the attacker can read your username off of the keycard, then it can be abused without even cloning the card. (Even better, of course, would be to use an RFID, since those would be exponentially harder to clone; oh, and make sure these kinds of logins only work from known hardware, obviously.)
Forth, there's all the things you can do to detect break-in attempts. Emailing failed login attempts to the admins' is a no-brainer. You should also ensure that you record login attempts, and you kick any user who has logged in twice. That way you'll get a report from a frustrated user who's getting booted, and you can find out that the same users has, apparently, logged in on the opposite side of the campus. Check your security footage, and you've caught the attacker.
If you want to get really fancy, your system can automatically check the physical distance between the two machines, and alert the admins when a login should be impossible. This is taking it a bit far for most purposes, but for a debit card and access to financial information, it's perfectly reasonable. This is important stuff, so even monitoring IP traffic to bring the admins' attention to atypical traffic (i.e. gigs of traffic sent to an unknown IP address) isn't out of the question.
There's also things you can do to your hardware design to make modifications obvious to the users. Around here, banks have put a translucent green piece of plastic on the ATMs so that an attacker can't surreptitiously install a mag stripe reader.
This is all stuff I've thought of in a couple of minutes, and a fraction of this stuff would have stopped the kid.
The idea that physical access to the machine implies security is impossible just makes for lazy IT workers. There's still lots you can do to make things difficult, or make break-in attempts apparent.
In most cases, people only need physical access to the keyboard, mouse, and monitor, and maybe a usb socket; the rest of the computer can be locked away.
It's also a cinch to prevent unauthorized users from installing software on any moderately competent operating system. Unauthorized users may still be able to run unauthorized software, but there's no way it would keep running when another students logs in.
When you're offering public terminals, it's also a good idea to ghost those terminals every morning, so that if somebody does compromise any of your machines, the damage is limited.
Any IT worker worth their salt should know these things.
If only there was some way we could send mail to Slahsdot when we disagree on how the site is being run...
You misunderstand. Those signs are just listing the three things they don't provide.