Part of the basis of the decision was that "since there is a legal framework for punishing any leakage of data, there is no concern of data leakage occurring" (p10-11); this suggests to me that if such leakage does occur (and one of the affected parties is actually bothered, since the courts won't let you sue on someone else's behalf), this has a potential to be overturned later. They also explicitly state (p12) that the clause making misuse illegal overrides the clause allowing municipalities to change the rules on use of the data.
It's worth noting that the juuki database only holds four pieces of data: name, date of birth, gender, and address. Not to downplay the potential dangers of any data being stored in electronic databases, of course; but as the decision points out, these tend to be floating around all over the place, and you have to give them out for just about anything you want to do at the city office anyway.
Sometimes you just don't want your data to be compressed; you want to be able to tell the OS to load the data from storage and have it right there, ready for you to use. Sometimes you just can't afford the overhead of decompression. But PNG, reasonably enough (I suppose) for network graphics, requires all images to be compressed; you can't say "no compression".(*) BMP, on the other hand, is uncompressed by default; aside from the line order problems (which are easily solved by pre-flipping the image), that makes it perfect for cases like these. So that's what PNG doesn't do that BMP does.
(*) You can play games by attaching fake compression headers, sort of like what was done to work around the GIF compression patents. In fact, I did. But at that point, you might as well just use something like BMP which is uncompressed in the first place.
1998: "A massive power outage left millions of people without power Friday. The cause of the blackout is unclear."
2008: "A massive power outage left millions of people without power Friday. The government says terrorism was not involved, but the cause of the blackout is unclear."
Overall, I admit a preference for simple methods over complex ones, perhaps as a result of too many years spent deciphering other people's programs (: but you do make several good points.
Perhaps. However, you have to look for a habitable planet. There is also no guarantee that it will stay habitable. Not all stars are as placid as our Sun.
On geological timescales, yes, but on human timescales that shouldn't signify, especially if one presumes that we have the technology to get to such planets in the first place. I do, however, grant you the difficulty of finding a Goldilocks planet versus just dropping a pile of asteroids into your planetoid maker.
We have natural disasters on Earth too. Much more often, I might add. And much more dangerous. Here we have hurricanes, earthquakes, floods, mudslides, lightning, forest fires, droughts, tsunamis, plagues, to name a few.
Most of which your planetoids would be just as susceptible to. (Hell, they get occasional rain in the VAB at under two hundred meters.) You'll have much less chance of earthquakes, and no volcanoes, certainly; but as long as there's water you'll have rain, and the spinning of the cylinder would probably stir up the air enough for some decent storms. (I wonder how they'd behave in a concave cylinder rather than on a convex sphere?)
It "just works". No need to hope that the generators, refueling robots, etc. don't break down.
External atmosphere. Meteors burn up before they punch a hole in the crust.
Fail-soft. Said meteor does not result in the contents of the atmosphere whooshing out the impact site. Also much more resilient against the jackass who "knows" there's a pot of gold underneath the crust, if only he can drill through that one metallic layer.
I give you the redundancy aspect, but I doubt that'll satisfy the people who suddenly find themselves shooting out a hole or floating in the air or what have you.
We need to adjust our direction of civilisation away from more toys and gadgets to higher quality human interactions and more meaningful labour.
And yet you sit here reading Slashdot. (:
Sorry, couldn't resist. But seriously, preaching to people that they need to lower their standards of living just ain't gonna work. (This probably has a lot to do with the impression that many of the people doing the preaching don't practice the same.) We're already making progress in reducing the energy footprint of any particular activity--hybrid cars, low-power CPUs, and so forth--which is a perfectly valid way of reducing society's energy usage as a whole, and much more acceptable to people in general than forcibly reducing their standards of living. And if nothing else, there's a huge fireball just a hundred million miles away that's putting out 5.38 hojillion watts of energy; I doubt we'll run into that limit anytime soon.
While I may be mistaken, I don't think "immediately" is meant to imply "straight from the brewer at 91-96 C" because that would cause 3rd degree burns to your esophagus.
Well, seeing as tea, nabe, and many other things in Japan are usually served in the 90's C, allow me to suggest that you're mistaken. (: It's all a matter of how you drink it; I'll grant that if you pour it down your throat like you would a glass of water, you may not be in for a very pleasant experience.
Isn't reverse engineering with the tools used in this article disallowed by the license agreement for the game? I know little about law, so who has the trump card here?
That depends on the validity of the license. In theory, at least, a license is only required if you want to do something that you wouldn't otherwise be allowed to do; for example, the GPL allows you to distribute software (otherwise a violation of copyright) if you follow its terms. So the question here is, is reverse engineering prohibited by law? If not, Sony can say "prohibited" all they want, but such terms would be legally meaningless--though, of course, they can still sue you and make you spend money to defend yourself.
This is all in my non-lawyerly opinion, of course.
In the end Vista will be inevitable. Drivers not available anymore except for Vista,
This doesn't mean much as long as you don't upgrade your hardware, which is of course most of the business world. What company wants to waste cash on replacing computers that work just fine?
important programs that are Vista-only.
Like Office 97? Somehow I doubt that Microsoft is going to retroactively make that Vista-only, or (equivalently) disable it--though it would be fun to watch the fireworks if they did. (FWIW, I do my finances in Excel 95 under VMware, and not only does it work just fine, it's snappier than anything modern I've come across.)
Security updates not being made available for XP anymore.
This, if anything, will push people; but it could well push them to Macs or Linux instead. Why do you think Microsoft extended the XP support cutoff? (I doubt it was because they want to support two operating systems at once . ..)
It's hard, I'll give you that. I'm not sure if I'd have the courage to find out for myself, but after seeing what it's doing to my grandmother, I think the least I can do is implant the idea in my head that my memory may one day become defective (and hope that if I do succumb, at least that part of my memory remains intact). As long as I was capable of determining that I was in fact losing my mind, I think I could deal with it, and I know it'd be easier on family.
My grandmother's suffering from Alzheimer's, and the OP gave me a chuckle nonetheless. Nobody's forcing you to laugh, but some of us find humor useful in dealing with hardship.
Documenting how things work, from both a user's and a developer's perspective, is certainly important. But it's even more important to write down why your program works the way it does. Any reasonably skilled programmer can reconstruct the "how", given enough time--it's in the code, after all--but nobody can read your mind to determine "why" you chose a particular method of doing things.
Without the "why", another programmer may be hesitant to change your code, even if he sees a potentially better algorithm, because he won't know whether it's safe to do so: Did you use your algorithm on purpose, maybe due to some aspect of the program structure that requires it? Does the rest of your program assume that the function will operate in a particular way? (I'm not going to turn this into a lecture on encapsulation or anything; this is just an example of why the "why" is important.) It's okay if your reasoning is just "it's the only thing that occurred to me" or "I don't like doing this kind of routine so I just rushed through it", and in fact, that sort of note will help others fill in any holes in your design.
As for the code itself, don't worry! Everybody's gone through more or less the same learning process, so most people will be perfectly understanding, no matter how your code looks. (Of course, there are always those who leave snide comments, but like playground name-callers, the best thing to do is just take them in stride.)
With Mac OS X hot on its tail, Vista is simply not capable of competing at an OS level with some of the best software around
"Hot on Vista's tail" would mean that OS X has a market share close to Windows, which is obviously not true even under the most optimistic assumptions.
Actually, it would mean that OS X has a market share close to Vista, not to Windows as a whole. It's still quite possible that this is false, but we keep hearing about Vista's slow uptake, and I myself have a couple of computer-illiterate friends who (independently) went from Windows XP to Mac OSX rather than Vista, so I don't think it's quite as clearly out of the question.
At its heart, 3D rendering is 3D rendering, whether the actual function names are IDirect3DDevice9::ExtremelyLongName() or glShortSweet(). As long as you plan from the start for multiplatform support -- in other words, don't hard-code Direct3D vertex type constants or GL mode values into your data files -- it's not that much extra work. It's even easier (more so in the long run, admittedly) if you wrap both Direct3D and OpenGL code in a platform-agnostic layer, like I'm doing; then you can just code to that middle layer and not even have to think about which renderer is doing what.
Slashdot Mirror
Part of the basis of the decision was that "since there is a legal framework for punishing any leakage of data, there is no concern of data leakage occurring" (p10-11); this suggests to me that if such leakage does occur (and one of the affected parties is actually bothered, since the courts won't let you sue on someone else's behalf), this has a potential to be overturned later. They also explicitly state (p12) that the clause making misuse illegal overrides the clause allowing municipalities to change the rules on use of the data.
It's worth noting that the juuki database only holds four pieces of data: name, date of birth, gender, and address. Not to downplay the potential dangers of any data being stored in electronic databases, of course; but as the decision points out, these tend to be floating around all over the place, and you have to give them out for just about anything you want to do at the city office anyway.
For the curious (and Japanese-literate), the full decision can be found at: http://www.courts.go.jp/hanrei/pdf/20080306142412.pdf
Sometimes you just don't want your data to be compressed; you want to be able to tell the OS to load the data from storage and have it right there, ready for you to use. Sometimes you just can't afford the overhead of decompression. But PNG, reasonably enough (I suppose) for network graphics, requires all images to be compressed; you can't say "no compression".(*) BMP, on the other hand, is uncompressed by default; aside from the line order problems (which are easily solved by pre-flipping the image), that makes it perfect for cases like these. So that's what PNG doesn't do that BMP does.
(*) You can play games by attaching fake compression headers, sort of like what was done to work around the GIF compression patents. In fact, I did. But at that point, you might as well just use something like BMP which is uncompressed in the first place.
Japanese don't do this "sleeping in" thing. If you do, maybe you ought to invest in some curtains?
As a side note, I live in Yokohama and have no trouble whatsoever sleeping until noon when I feel like it.
1998: "A massive power outage left millions of people without power Friday. The cause of the blackout is unclear."
2008: "A massive power outage left millions of people without power Friday. The government says terrorism was not involved, but the cause of the blackout is unclear."
Sigh . . .
So the question is, what did they offer forty-three of?
Husks of overworked employees? Content-free games?
. . . Wizened 6502 assembly hackers?
Overall, I admit a preference for simple methods over complex ones, perhaps as a result of too many years spent deciphering other people's programs (: but you do make several good points.
Perhaps. However, you have to look for a habitable planet. There is also no guarantee that it will stay habitable. Not all stars are as placid as our Sun.On geological timescales, yes, but on human timescales that shouldn't signify, especially if one presumes that we have the technology to get to such planets in the first place. I do, however, grant you the difficulty of finding a Goldilocks planet versus just dropping a pile of asteroids into your planetoid maker.
We have natural disasters on Earth too. Much more often, I might add. And much more dangerous. Here we have hurricanes, earthquakes, floods, mudslides, lightning, forest fires, droughts, tsunamis, plagues, to name a few.Most of which your planetoids would be just as susceptible to. (Hell, they get occasional rain in the VAB at under two hundred meters.) You'll have much less chance of earthquakes, and no volcanoes, certainly; but as long as there's water you'll have rain, and the spinning of the cylinder would probably stir up the air enough for some decent storms. (I wonder how they'd behave in a concave cylinder rather than on a convex sphere?)
Just off the top of my head:
I give you the redundancy aspect, but I doubt that'll satisfy the people who suddenly find themselves shooting out a hole or floating in the air or what have you.
Followed in short order by anonymous cowards who don't bother proofreading.
The way TFA talks about the dimension of time turning into a dimension of space, it feels like deja vu all over again.
Yup, and the rest is second-system syndrome too.
And yet you sit here reading Slashdot. (:
Sorry, couldn't resist. But seriously, preaching to people that they need to lower their standards of living just ain't gonna work. (This probably has a lot to do with the impression that many of the people doing the preaching don't practice the same.) We're already making progress in reducing the energy footprint of any particular activity--hybrid cars, low-power CPUs, and so forth--which is a perfectly valid way of reducing society's energy usage as a whole, and much more acceptable to people in general than forcibly reducing their standards of living. And if nothing else, there's a huge fireball just a hundred million miles away that's putting out 5.38 hojillion watts of energy; I doubt we'll run into that limit anytime soon.
Well, seeing as tea, nabe, and many other things in Japan are usually served in the 90's C, allow me to suggest that you're mistaken. (: It's all a matter of how you drink it; I'll grant that if you pour it down your throat like you would a glass of water, you may not be in for a very pleasant experience.
That depends on the validity of the license. In theory, at least, a license is only required if you want to do something that you wouldn't otherwise be allowed to do; for example, the GPL allows you to distribute software (otherwise a violation of copyright) if you follow its terms. So the question here is, is reverse engineering prohibited by law? If not, Sony can say "prohibited" all they want, but such terms would be legally meaningless--though, of course, they can still sue you and make you spend money to defend yourself.
This is all in my non-lawyerly opinion, of course.
This doesn't mean much as long as you don't upgrade your hardware, which is of course most of the business world. What company wants to waste cash on replacing computers that work just fine?
important programs that are Vista-only.Like Office 97? Somehow I doubt that Microsoft is going to retroactively make that Vista-only, or (equivalently) disable it--though it would be fun to watch the fireworks if they did. (FWIW, I do my finances in Excel 95 under VMware, and not only does it work just fine, it's snappier than anything modern I've come across.)
Security updates not being made available for XP anymore.This, if anything, will push people; but it could well push them to Macs or Linux instead. Why do you think Microsoft extended the XP support cutoff? (I doubt it was because they want to support two operating systems at once . . .)
I think you mean "faze", unless you're worried about the price tag synchronizing you with a waveform.
(Sorry--you just happened to overflow my patience counter for this mistake.)
Just wait until next year.
Blog Action Day 2.0. The Revenge.
It's hard, I'll give you that. I'm not sure if I'd have the courage to find out for myself, but after seeing what it's doing to my grandmother, I think the least I can do is implant the idea in my head that my memory may one day become defective (and hope that if I do succumb, at least that part of my memory remains intact). As long as I was capable of determining that I was in fact losing my mind, I think I could deal with it, and I know it'd be easier on family.
My grandmother's suffering from Alzheimer's, and the OP gave me a chuckle nonetheless. Nobody's forcing you to laugh, but some of us find humor useful in dealing with hardship.
Documenting how things work, from both a user's and a developer's perspective, is certainly important. But it's even more important to write down why your program works the way it does. Any reasonably skilled programmer can reconstruct the "how", given enough time--it's in the code, after all--but nobody can read your mind to determine "why" you chose a particular method of doing things.
Without the "why", another programmer may be hesitant to change your code, even if he sees a potentially better algorithm, because he won't know whether it's safe to do so: Did you use your algorithm on purpose, maybe due to some aspect of the program structure that requires it? Does the rest of your program assume that the function will operate in a particular way? (I'm not going to turn this into a lecture on encapsulation or anything; this is just an example of why the "why" is important.) It's okay if your reasoning is just "it's the only thing that occurred to me" or "I don't like doing this kind of routine so I just rushed through it", and in fact, that sort of note will help others fill in any holes in your design.
As for the code itself, don't worry! Everybody's gone through more or less the same learning process, so most people will be perfectly understanding, no matter how your code looks. (Of course, there are always those who leave snide comments, but like playground name-callers, the best thing to do is just take them in stride.)
Don't worry; Kaguya has a better camera, too.
Chicken, chicken chicken chicken chicken. Chicken chicken Chicken, chicken chicken chicken CKN chickens Chicken Chicken Chicken. Chicken chicken, chicken chicken chicken, chicken chicken chickens chicken chicken chicken chicken. (Chicken chicken chickens, chicken.)
Chicken?
See here (in Japanese); it can talk to HDD recorders or PCs and play back stuff over a LAN.
Looks like the TV has an XMB, too. I guess they had to do something with all those PS3s they can't sell . . .
"Hot on Vista's tail" would mean that OS X has a market share close to Windows, which is obviously not true even under the most optimistic assumptions.
Actually, it would mean that OS X has a market share close to Vista, not to Windows as a whole. It's still quite possible that this is false, but we keep hearing about Vista's slow uptake, and I myself have a couple of computer-illiterate friends who (independently) went from Windows XP to Mac OSX rather than Vista, so I don't think it's quite as clearly out of the question.
Of course, Japan is doing its best to hold the yen down so it can keep up its exports. Silly governments.
At its heart, 3D rendering is 3D rendering, whether the actual function names are IDirect3DDevice9::ExtremelyLongName() or glShortSweet(). As long as you plan from the start for multiplatform support -- in other words, don't hard-code Direct3D vertex type constants or GL mode values into your data files -- it's not that much extra work. It's even easier (more so in the long run, admittedly) if you wrap both Direct3D and OpenGL code in a platform-agnostic layer, like I'm doing; then you can just code to that middle layer and not even have to think about which renderer is doing what.