Now I'm confused. Did I use the phrase wrong? I just repeated what the parent post said. Not a native speaker, just acting like one, eager to learn, etc.
Huh. I guess it's telling that I silently assumed he was talking about censoring the game for violence, not porn. Around here, games are routinely only easily available in "reduced violence". The thought of this being about removing adult content from a game never even crossed my mind.
This is also because there seem to be very, very few games that have any sexual content in them apart from those few games which sell BECAUSE they have sexual content, starting from those beach volleyball games. And it seems silly to have a low porn mode in a porn game. Apart from those, I have a difficult time coming up with an example of a normal game which could have a low-porn-mode. Less over the top cup sizes for female characters? Scantily clad characters in RPGs? Maybe I'm playing the wrong games or something.
Either way, I absolutely agree that he has a legitimate gripe.
Say what you want about it, doing it in a generic object oriented fashion is usually more fun. Lets you focus on all the imaginable problems instead of just the single, dull instance you're faced with.:)
Well, TFA speculates about saving games on a server, I implicitly referred to this example. Obviously, if the game simply streams the save game data to the server which streams it back on demand, emulating it wouldn't be too difficult. But it's conceivable to design the game in a way that it streams data A to the server, which does some kind of game-specific processing, and streams data B back. A very simple example: position (x/y/z) in a level in, checkpoint (named reference) back. The relation between A and B need not be available in the game binary, so that you can't reverse engineer it just by looking at the game. Granted, for the example you could just let the user choose the checkpoint to go back to, which would sort of circumvent the server-side, but it'd be a different game experience. A more elaborate scheme would make things more inconvenient.
Getting the best of both worlds would mean getting low latency access to bulk file metadata, as well. I don't even mean fancy stuff like tags or what have you; but it would be nice if file listings would appear instantly instead of just very quickly, ideally including the icon thumbnails for media data if you're browsing graphically, finding files (recursively) should be super fast, as well. None of this is easy to do without doing strange ninja stuff, though, if it's possible at all.
This tells me that a) you're good at doing extremely repetitive work and b) he probably wasn't very good at writing scripts (yet). However, the next time a similar job comes around, you'll still take the same time, while he can either simply re-use his scripts or write a new one within a shorter time because he hopefully has learned from past experience.
With similar effort one can construct a kit that replaces calls to server communication sub-routines -- or better yet, the hackers can emulate the whole "mothership" server system, based on the analysis of the appropriate client sub-routines.
That's not a similar effort, it's a LOT more work, and I'm not sure that any of it can really be automated. How difficult it ends up being obviously depends on how much work the server is doing in the first place. Not that any of this will apply to AC2.
I had to read that a couple of times before I understood/believed it: they uncensored a game and you were unhappy with that? You wanted the censored version of the game back?
You should be so lucky! I've got to boot my TV blindfolded, with my bare hands, out in the snow, for 60 minutes, up a hill, while strangling a dozen chicken and whistling the tune to the Family Guy theme, etc etc.
Damn it, Slashdot ate my italics, the paragraph below the blockquote is another quote, so it should be:
So the primary goal of a font is to be legible. Being true to the font designers idea is secondary.
Strike that; reverse it. IF it is being used for the purpose of documenting a lengthy text (for which most typefaces are not designed), then an appropriate typeface should be selected for the environment, including the display medium and other factors.
There is no purpose to a multi-typeface environment if the purpose is merely to encode text.
That is not what I said. I said the primary goal is encoding text; I never said it's the only goal. This multi-faceted character was the whole point of the comparison with images.
So the primary goal of a font is to be legible. Being true to the font designers idea is secondary.
Strike that; reverse it. IF it is being used for the purpose of documenting a lengthy text (for which most typefaces are not designed), then an appropriate typeface should be selected for the environment, including the display medium and other factors.
Well, not sure where to start. Well first of all now you silently seem to concede that legibility and fidelity are at odds in certain situations. That was really the central point I was making in my previous post so I could just stop here.
I'll add that it's a given that we're talking about fonts^Wtypefaces that are designed for either lengthy texts or something similar that's fairly specific to computer interfaces. Text at a standard print size is, after all, one of the central elements of the GUI (and the only element in non-G UI). Talking about fonts designed for other purposes and legibility and rendering at larger sizes means missing the point. I agree that designing and using fonts well-suited to the relatively low-ppi display technology is a very good idea. And of course I look forward to having super high resolution displays in the forseeable future.
I've always been deeply opposed to new buttons on Slashdot, but now that I've come to think about it, YES you're right, Slashdot DIRELY needs a like button.
The difference between images/gamma and fonts/fidelity is pretty simple. With images, in general the single goal is an accurate representation of the image on your viewing device. This is because the purpose of the image is to be looked at. With fonts, fidelity is NOT the single goal since the font itself serves a further purpose: it encodes a text, which's purpose is to be read. So the primary goal of a font is to be legible. Being true to the font designers idea is secondary.
Of course, you claim that legibility vs. fidelity is a false dichotomy. Not only that, but you claim the opposite: high fidelity is also high legibility. If that's true, then the algorithm should be optimised to give fidelity. However, you also agree that at low font sizes, optimising for fidelity gives poor results, so clearly, the two goals don't align in every situation. I don't see why the principles that apply at low font sizes wouldn't apply to large fonts as well, to a much lesser degree, but still. So claiming it's a false dichotomy seems disingenuous.
That same OpenDNS anti phishing crap prevented me from going to a very prominent and perfectly innocuous German-language cooking website a couple of days ago. Pissed me off to no end because even after replacing the OpenDNS servers, I still got redirected because of some caching or other shenanigans. After some fiddling and restarting things it started working, though. And with DNS redirecting, it's not a matter of hitting a "Yes I'm sure" button, you can't get to the site full stop.
Thanks but no thanks, I'll rely on other methods -- primarily not being an idiot -- to avoid phishing. The affected site was chefkoch.de, if anyone cares, and I did submit it as a false positive, so maybe it's fixed now.
You're missing the point. I'm sure they don't give a fuck about the LCIs, but I'm also pretty sure that someone who consistently ignored devices installed specifically to get out of a warranty replacement (justified or not) wouldn't be in charge of warranty issues for a long time. They might have a bit more leeway if they can cross the "Misc" box on the replacement form. It obviously makes for great PR.
I'm not particularly angry and the evidence is the presence of LCIs in most mobile electronics (you know, the topic of this whole discussion). As for anecdotes, I've actually posted my two friends' non-replacement stories (never had to return my own Apple gear) somewhere else, but short of a Slashdot poll on the topic we're not going to get a meaningful sample here.
The difference is that Apple is probably the highest profile consumer electronics brand in the western world? With a somewhat high-quality/luxury/high-price image attached to many of the products? What's so difficult about that to understand?
Individual Apple employees don't really give a fuck if Apple has to shell out for a replacement iPhone vs. Company management killing a significant part of all warranty replacements. Story by random internet dude vs. Presence of LCIs in all mobile Apple devices. Guess you were lucky it fell (two stories) on concrete and not into a puddle.
In fact, it's hardly unreasonable to expect mobile devices like phones and media players and even laptops to be more resistant to harsh conditions than devices that are clearly designed for indoor use such as a regular computer and a TV. For instance, I think it's terribly annoying that you're not supposed to use many of the mobile devices in the rain. And all devices should be able to deal with the "normal" range of outside temperatures of the country they're sold in, or be clearly marked as summer/indoor use only.
And of course they do work at extreme temperatures, otherwise there would've been a huge consumer outcry, I guess the manufacturers just can't (or are too cheap to) prove that they work.
Maybe Apple sometimes is great on warranty, but I know of two cases where they refused to look at iPods because they had scratches or other mars that were simply the result of using them normally and keeping them in a pocket with keys. So YMMV. Guess that's why they installed motion sensors, now they can record spikes in the acceleration when devices are dropped...
Sure. No one should have any software problems! End of story. So what are you suggesting? Putting off a release if somebody reports a bug/regression? Sticking to old versions of a package if a regression is reported? To be honest, I'd rather have the updated package and risk a couple of bugs. It's upstream's job to make sure there are no bugs and particularly that there are no regressions; it might be part of Canonical's job to shield users from particularly bad upstream releases, but only up to a point. Maybe you should look at Debian stable?
Of course it'd be nice if they fixed all the bugs that crop up, but that's a job that's better left for the actual developers of the package. I'd rather they concentrate on good integration and facilitating bug reporting and communication between users and developers.
Writing a 1000+ character reply is hardly dismissive. You've got a valid complaint (or whatever, not here to mince words), but Canonical won't be able to help you, because they don't have the resources to do anything about it. If you're used to a particular pro application that's platform-locked to Windows, well, what is supposed to happen? I guess the application developers would be the ones to talk to, not a Linux distributor. But like I said, application availability and compatibility is a huge barrier to Linux adoption, even though
Your belief that a lack of Linux adoption is due to a lack of application friendliness would need some more arguments and/or examples. FWIW, I disagree, I believe the apps that are useful to most users aren't worse in terms of UI than their Windows counterparts. The primary app, the web browser, seems about the same.
I think GIMP is a bad example because the application is not relevant to most users, and professionals in a field are (for good reason) fiercely loyal to their tools and are extremely unlikely to switch, least of all for a petty sum of a couple hundred bucks. Of course this is also due to interface entrenchment, there is just no doubt about that (you misquoting me as if I said it's only due to that seems hostile).
Slashdot Mirror
Now I'm confused. Did I use the phrase wrong? I just repeated what the parent post said. Not a native speaker, just acting like one, eager to learn, etc.
Huh. I guess it's telling that I silently assumed he was talking about censoring the game for violence, not porn. Around here, games are routinely only easily available in "reduced violence". The thought of this being about removing adult content from a game never even crossed my mind.
This is also because there seem to be very, very few games that have any sexual content in them apart from those few games which sell BECAUSE they have sexual content, starting from those beach volleyball games. And it seems silly to have a low porn mode in a porn game. Apart from those, I have a difficult time coming up with an example of a normal game which could have a low-porn-mode. Less over the top cup sizes for female characters? Scantily clad characters in RPGs? Maybe I'm playing the wrong games or something.
Either way, I absolutely agree that he has a legitimate gripe.
Say what you want about it, doing it in a generic object oriented fashion is usually more fun. Lets you focus on all the imaginable problems instead of just the single, dull instance you're faced with. :)
Well, TFA speculates about saving games on a server, I implicitly referred to this example. Obviously, if the game simply streams the save game data to the server which streams it back on demand, emulating it wouldn't be too difficult. But it's conceivable to design the game in a way that it streams data A to the server, which does some kind of game-specific processing, and streams data B back. A very simple example: position (x/y/z) in a level in, checkpoint (named reference) back. The relation between A and B need not be available in the game binary, so that you can't reverse engineer it just by looking at the game. Granted, for the example you could just let the user choose the checkpoint to go back to, which would sort of circumvent the server-side, but it'd be a different game experience. A more elaborate scheme would make things more inconvenient.
Getting the best of both worlds would mean getting low latency access to bulk file metadata, as well. I don't even mean fancy stuff like tags or what have you; but it would be nice if file listings would appear instantly instead of just very quickly, ideally including the icon thumbnails for media data if you're browsing graphically, finding files (recursively) should be super fast, as well. None of this is easy to do without doing strange ninja stuff, though, if it's possible at all.
This tells me that a) you're good at doing extremely repetitive work and b) he probably wasn't very good at writing scripts (yet). However, the next time a similar job comes around, you'll still take the same time, while he can either simply re-use his scripts or write a new one within a shorter time because he hopefully has learned from past experience.
See, people are talking about cars, not trucks. The two vehicle classes aren't really related.
With similar effort one can construct a kit that replaces calls to server communication sub-routines -- or better yet, the hackers can emulate the whole "mothership" server system, based on the analysis of the appropriate client sub-routines.
That's not a similar effort, it's a LOT more work, and I'm not sure that any of it can really be automated. How difficult it ends up being obviously depends on how much work the server is doing in the first place. Not that any of this will apply to AC2.
I had to read that a couple of times before I understood/believed it: they uncensored a game and you were unhappy with that? You wanted the censored version of the game back?
You should be so lucky! I've got to boot my TV blindfolded, with my bare hands, out in the snow, for 60 minutes, up a hill, while strangling a dozen chicken and whistling the tune to the Family Guy theme, etc etc.
Damn it, Slashdot ate my italics, the paragraph below the blockquote is another quote, so it should be:
(Rest of my comment.)
There is no purpose to a multi-typeface environment if the purpose is merely to encode text.
That is not what I said. I said the primary goal is encoding text; I never said it's the only goal. This multi-faceted character was the whole point of the comparison with images.
Strike that; reverse it. IF it is being used for the purpose of documenting a lengthy text (for which most typefaces are not designed), then an appropriate typeface should be selected for the environment, including the display medium and other factors.
Well, not sure where to start. Well first of all now you silently seem to concede that legibility and fidelity are at odds in certain situations. That was really the central point I was making in my previous post so I could just stop here.
I'll add that it's a given that we're talking about fonts^Wtypefaces that are designed for either lengthy texts or something similar that's fairly specific to computer interfaces. Text at a standard print size is, after all, one of the central elements of the GUI (and the only element in non-G UI). Talking about fonts designed for other purposes and legibility and rendering at larger sizes means missing the point. I agree that designing and using fonts well-suited to the relatively low-ppi display technology is a very good idea. And of course I look forward to having super high resolution displays in the forseeable future.
I've always been deeply opposed to new buttons on Slashdot, but now that I've come to think about it, YES you're right, Slashdot DIRELY needs a like button.
The difference between images/gamma and fonts/fidelity is pretty simple. With images, in general the single goal is an accurate representation of the image on your viewing device. This is because the purpose of the image is to be looked at. With fonts, fidelity is NOT the single goal since the font itself serves a further purpose: it encodes a text, which's purpose is to be read. So the primary goal of a font is to be legible. Being true to the font designers idea is secondary.
Of course, you claim that legibility vs. fidelity is a false dichotomy. Not only that, but you claim the opposite: high fidelity is also high legibility. If that's true, then the algorithm should be optimised to give fidelity. However, you also agree that at low font sizes, optimising for fidelity gives poor results, so clearly, the two goals don't align in every situation. I don't see why the principles that apply at low font sizes wouldn't apply to large fonts as well, to a much lesser degree, but still. So claiming it's a false dichotomy seems disingenuous.
Duly note.
Or: Dully noted.
What a mind-boggingly bad argument. And you actually seem to buy it, yourself.
That same OpenDNS anti phishing crap prevented me from going to a very prominent and perfectly innocuous German-language cooking website a couple of days ago. Pissed me off to no end because even after replacing the OpenDNS servers, I still got redirected because of some caching or other shenanigans. After some fiddling and restarting things it started working, though. And with DNS redirecting, it's not a matter of hitting a "Yes I'm sure" button, you can't get to the site full stop.
Thanks but no thanks, I'll rely on other methods -- primarily not being an idiot -- to avoid phishing. The affected site was chefkoch.de, if anyone cares, and I did submit it as a false positive, so maybe it's fixed now.
You're missing the point. I'm sure they don't give a fuck about the LCIs, but I'm also pretty sure that someone who consistently ignored devices installed specifically to get out of a warranty replacement (justified or not) wouldn't be in charge of warranty issues for a long time. They might have a bit more leeway if they can cross the "Misc" box on the replacement form. It obviously makes for great PR.
I'm not particularly angry and the evidence is the presence of LCIs in most mobile electronics (you know, the topic of this whole discussion). As for anecdotes, I've actually posted my two friends' non-replacement stories (never had to return my own Apple gear) somewhere else, but short of a Slashdot poll on the topic we're not going to get a meaningful sample here.
The difference is that Apple is probably the highest profile consumer electronics brand in the western world? With a somewhat high-quality/luxury/high-price image attached to many of the products? What's so difficult about that to understand?
Individual Apple employees don't really give a fuck if Apple has to shell out for a replacement iPhone vs. Company management killing a significant part of all warranty replacements. Story by random internet dude vs. Presence of LCIs in all mobile Apple devices. Guess you were lucky it fell (two stories) on concrete and not into a puddle.
In fact, it's hardly unreasonable to expect mobile devices like phones and media players and even laptops to be more resistant to harsh conditions than devices that are clearly designed for indoor use such as a regular computer and a TV. For instance, I think it's terribly annoying that you're not supposed to use many of the mobile devices in the rain. And all devices should be able to deal with the "normal" range of outside temperatures of the country they're sold in, or be clearly marked as summer/indoor use only.
And of course they do work at extreme temperatures, otherwise there would've been a huge consumer outcry, I guess the manufacturers just can't (or are too cheap to) prove that they work.
Incidently, my computer is self-heating.
Maybe Apple sometimes is great on warranty, but I know of two cases where they refused to look at iPods because they had scratches or other mars that were simply the result of using them normally and keeping them in a pocket with keys. So YMMV. Guess that's why they installed motion sensors, now they can record spikes in the acceleration when devices are dropped...
Not sure what accounts for a major player, but the standard Ubuntu desktop seems fairly conservative to me.
Sure. No one should have any software problems! End of story. So what are you suggesting? Putting off a release if somebody reports a bug/regression? Sticking to old versions of a package if a regression is reported? To be honest, I'd rather have the updated package and risk a couple of bugs. It's upstream's job to make sure there are no bugs and particularly that there are no regressions; it might be part of Canonical's job to shield users from particularly bad upstream releases, but only up to a point. Maybe you should look at Debian stable?
Of course it'd be nice if they fixed all the bugs that crop up, but that's a job that's better left for the actual developers of the package. I'd rather they concentrate on good integration and facilitating bug reporting and communication between users and developers.
Writing a 1000+ character reply is hardly dismissive. You've got a valid complaint (or whatever, not here to mince words), but Canonical won't be able to help you, because they don't have the resources to do anything about it. If you're used to a particular pro application that's platform-locked to Windows, well, what is supposed to happen? I guess the application developers would be the ones to talk to, not a Linux distributor. But like I said, application availability and compatibility is a huge barrier to Linux adoption, even though
Your belief that a lack of Linux adoption is due to a lack of application friendliness would need some more arguments and/or examples. FWIW, I disagree, I believe the apps that are useful to most users aren't worse in terms of UI than their Windows counterparts. The primary app, the web browser, seems about the same.
I think GIMP is a bad example because the application is not relevant to most users, and professionals in a field are (for good reason) fiercely loyal to their tools and are extremely unlikely to switch, least of all for a petty sum of a couple hundred bucks. Of course this is also due to interface entrenchment, there is just no doubt about that (you misquoting me as if I said it's only due to that seems hostile).