My point was simply that it is a funny thing because they on the one hand obviously were helped by the sites, but also want to shut them down. It's not about copyright ownership and rights, it's about the weirdness of the situation.
There are MANY nes and snes games that ninentendo did NOT publish and has no particular stake in.
Not true. For example, the NES classic edition has Capcom, Konami, Square, and others. They have a stake in it. Also, I would presume they also have some copyrighted material even in third party roms (e.g. library code) so they also almost certainly have a right.
If a copyright holder is active then its not abandonware.
It's worthkeeping in mind that abandonware is not a legally recognized thing. The holder of the rights can at any point decide to go after it.
Only the original copyright holder has the right to make money off these roms.
Financial gain is not a requirement to be sued for violating copyright.
It's funny, but at the same time they are perfectly within their rights to download from a site for their use, and even sue that same site for infringement. They are the copyright holder after all..
12x1.5" is a pretty big area to suck out of a laptop....
Also, expect these things to be priced in the stratosphere, much much more than I would imagine any laptop consumer spending on even 10 entire laptops...
Generally speaking, laptops are using M.2 modules, which have a screw and a card-edge connector. I haven't owned any laptop that solders storage down to the board.
It is designed for 1U servers that would be designed for it. That's the rub. Yes, they made them 1U wide, and a depth that in theory can fit with processors and dimms. However there isn't leftovers for other things.
Front cabled systems with front drives also could work (albeit without being able to cram in 32 drives, but that's fine...), but front cabling isn't too popular...
Note that it actually quite common now to have drives that go into the front and the back. For these 12" long suckers, that's unlikely and having that volume of NAND chips all front serviceable without a tray would be one point of these things. 12" is however a bit *too* long for reasonable 1U servers. 6" depth might have been a pretty sweet spot, not much longer than 3.5" drives. As such this form factor pretty much requires the design of the server to be focused on the storage to the exclusion of other concerns.
Actually, server *blades* tend to be relatively shallow, they are the least likely to have the depth for this.
1U server is the smallest server form factor that *could* conceivably be adapted to cope (and has to forgo things like even half-length PCIe slots so the CPU and memory can be seated far enough out of the way for the drives to come in.
2U server with the 12" drives flying over the other components is the smallest one where the 12" depth could be accommodated without crazy compromises (you probably will be limited to 1U heatsink for the CPUs, but you would have the ability to have normal network adapters, though the bottom U of the front would probably be relegated to just being air intake.
Well, the point of this is to extend gobs of storage off a single connector. Space wise, 2.5" drives will be more storage per unit volume, but will need more connectors.
These things are really inconvenient in terms of form factor, being over twice as long as even the now 'gigantic' 3.5" drives.
While AR is certainly an interesting concept, I wouldn't want to give up the full VR experience. I'd rather feel totally enveloped. Being able to see the boring old drywall and such mixed with the environment can take something away.
Current user of an oculus rift and the experience is simply fantastic. AR may be more practical if well executed for a lot of work related or local multiplayer gaming for board/tabletop type stuff, but for single player immersive experience... VR...
My personal perspective is that 1:1 movement is overrated. I play 3d games where the avatar moves in ways that I couldn't, or at least ways I'd rather not bother moving.
That said, redirected walking seems a viable approach, at least for extending a large space to an 'infinite' space.
It's one thing if the argument is 'you need to award several smaller *independent* providers', so that a total failure of one vendor is isolated and you can keep going, great I wholeheartedly agree.
It's another if the argument is (and I think this is Oracle's hope) 'you need to compose the solution of many providers at different layers', so that a total failure of any of them is guaranteed to knock everything out.
Broadly speaking, it's a valid concern that we are eager to put all our eggs into as few baskets as possible, and those baskets will have a lot of mono culture in them.
An adversary discovers a way to access some key part of the power infrastructure of a brand Amazon uses and knows of a vulnerability that can deal persistent damage? Poof things could grind to a halt inflicting significant economic damage, and using an attack of a nature that has thus far not justified forceful retaliation in scenarios where it has happened.
Even assuming that from a networking and computer security things were perfect, we still have the reality that a military adversary coordinating an attack on 2 dozen sites could cripple our online infrastructure.
Our love of making these too big to fail companies not only has regrettable economic repercussions, but leaves our online ecosystem way too fragile.
This is true, but that makes this all the more significant of a proof point of the value of competition. In a competitive landscape, there's going to be *someone* to call someone else on their shenanigans, even if it another usually bad actor.
A more accurate analogy would be that whales live underwater, therefore if our whole society is flooded under a mile of water, we'd be ok because whales have proven the world wouldn't end under water.
No matter how slowly we approach Eocene conditions, there's no evidence that our biology will be able to cope with that ecosystem...
Improvement is one thing, but the proposal of writing unit tests and only unit tests as an improvement I disagree with.
I can't give a human a bunch of test cases without saying what it is actually doing and expect a sane result, no way a machine will do better, it has to know the intent not *guessing* the intent (with exceptions).
To the extent it is possible (e.g. machine learning today), you need to feed a model thousands of distinct examples for it to kind of lock on to some guesswork. It still screws up a lot (you feed it 1,000 pictures of sheep to recognize sheep, it messes up on a sheep that is indoors because that happened to not be in the set). We tolerate it for image recognition because while it is terrible, a human just can't describe all the ways to apply image analysis strategies and all the variations of the subject matter. The technique is best effort to tame unstructured data to then work with traditional programming, as once structure has been applied to the data, much easier to manipulate with programming.. The techniques just don't extend to handling structured data.
IT doesn't control my firefox. I install it myself. IT provides me DHCP specified DNS resolver that understands our internal network. They provide the certificate I can install.
This path ultimately leads to firefox resolution acting *differently* than chrome and neither resolving like the rest of the system.
The browser projects need to not internalize name resolution and instead work toward whatever they need out of the OS resolver.
"The disconnect between the hype and the reality is significant -- I've never seen anything like it," said Rajesh Kandaswamy, an analyst at Gartner Inc.
That's pretty much the case for most things Gartner sings the praises of from the rooftops. Gartner and IDC's business is largely made at senselessly hyping things up to scare companies into paying them for analyst insight on 'the new hot thing' that they don't get, but must be important....
But the implementation you would end up with would be a secure one, because you tested it for insecure inputs. And it would be a robust one, because your input set for testing is thorough and has good coverage. So there's that.
No, you probably didn't think of all the insecure inputs to design the test for. Unit testing when thoroughly practiced today with full human intelligence striving to pass it ends up with vulnerabilities. The resultant function could in fact be doing the very wrong thing, and just happen to match the test things you input. For example, if I give the tests: 1 gives 2, 2 gives 3, 3 gives 5, and 4 gives 7. Let's say this miracle code generator looks at them and says 'ah ha, he wants a function to return prime numbers!' but no, I wanted exponents for Mersenne primes, so it does the wrong functionality, but it passes all the tests! More specific and more numerous unit tests are not going to be easier than programming, and they won't cause a code generator to produce secure and reliable functionality.
- Do I write my loops and worry about the boundaries? Why? Let the software deal with the boundaries.
Depending on what you mean, this is something programming languages already do. The problem is that if some boundary condition is hit, it isn't psychic and doesn't know what to do about it. In a perl like language, it may be inclined to just no-op on it, which is closest to the ask, and this can produce very bad behavior because while a planned boundary has been violated, the unexpected existence of that data is a real thing and so it isn't handled as someone expects.
Do I worry about whether the collection is sorted? Why? Let the software determine whether the collection is sorted and end the looping early if it can.
There are two ways this can go down, either with a type that explicitly says it is sorted, or the software to iterate over the collection checking if it is sorted, which probably won't save you any time. The former does exist in various languages incidentally.
- Did I specify the collection was sorted to begin with? Why? Let the software look at how the items were collected and used and decide whether to maintain them in sorted order or to sort them, and what sorting algorithm to use.
Ok, so this would not use a sorted type, but it means it has to check if it is sorted... a lot... Also it may *happen* to be sorted but not *need* to be sorted and it would waste a lot of effort maintaining sort to get out of indicating intent. Also, it may guess the *wrong* thing to sort by and produce behavior not desirable.
- Do I worry about paralyzing the transform operation? Let the software break it up and send it to the GPU to do all in one go. Or not if the transformation can't be compiled for GPU. Or not if it will be slower to use the GPU.
I assume you don't mean paralyze. This is an area that could do with better language primitives. There's not much in the way of a standard way of saying 'iterations of this loop are independent of each other'. Closest we get are pools and applying a function, but this can be a bit heavy handed and restrict solutions. For example to get parallelism you might make a function that takes a 32 bit value and parallelize it rather than in a loop, but compiler may know better to use a vector processing facility to batch them. I'm amazed this far into multi-core being the norm and GPGPU being so prominent that languages have not evolved on this front.
Generally speaking, the things you ask for are existing language features or available in libraries to handle certain problem sets. The last case is probably the least addressed, but the answer is going to be 'I have a new programming language' or at least a new version of a programming language or library.
Yes, but let's start saying it. Then someone might do it, or part of it. Then we'll have better tools.
It doesn't really need to be said, because it is so self evident.
But your implementation still has to pass tests, even if you just think them and don't write them down. Writing them down means they can be used outside your own brain.
We have to be honest with ourselves, in practice, test cases don't cover all scenarios. They assume some amount of human intelligence and are there for the 'tricky' cases. If you suddenly had to have test cases for every expected behavior for software to randomly guess algorithms to hit it, it would be as hard as programming, if not harder. Creating a loop to count numbers is utterly trivial, but describing all the test cases that would allow a hypothetical learning strategy to deliver something that would just count numbers would be insane.
Let's expand the number of those problem sets. And then break down big problems into parts that fit into this expanded set
I guess I sholudn't have said 'works' but should have said 'practical'. As above, in most programming, it's *far* easier to just state the things for the computer to do than to tediously describe all sorts of scenarios until random code generation produces something vaguely appropriate. This isn't a matter of refining the techniques, it's just a fundamental reality of that approach.
Note that you don't *need* to have a database, server side execution, javascript assembled DOM, and such.
I do that in some cases.
There is however a documentation site I am responsible for that is just HTML and CSS. People originally said 'oh, it's going to have to be some complex CMS' but we went a different direction. Designers can play with the css and our technical writers just edit text and a build system kicks off to produce HTML and CSS and put to the site.
As a result, much less surface for attacks and a procedure that allows any writer that can edit a text file the ability to do their job. Yet it *looks* clean and modern to the endusers who are oblivious to how 'unfancy' it is under the covers.
There's a phenomenon where you forget how to be 'satisfied' with easy programming. When you start out, you don't know how to do much, but what you can do seems easy. As you acquire experience you become able to do so much more than you ever thought you could.
Then one day years on you take a step back at how you do things and think 'man, this is much more complicated than when I started out'. What you fail to do, however, is try to use those simplistic approaches to solve a problem that you are now used to addressing with all your experience and tools. Then you realize why you needed to leave those simplistic ways behind, and in fact simplistic ways still exist, they just aren't useful as you grow in complexity.
Whether he is writing the code or writing the tests the same description generally applies... The inexperienced developer doesn't understand everything that was asked and a lot of what could go wrong. One could say he should have conveyed the whole thing up front, but practically speaking humans don't think of everything up front, and only recall or conceive of things when faced with an iteration. You realize as you go that situations crop up, or the original design was ill-conceived.
This is an area where I have some reservations about the impact of 'test driven development' on human behavior. Any time you say you have '100% coverage' and 'it passes all the tests', it instills a false sense of security because those tests are likely to be incorrect or inadequate. It's a good idea, but have to not get *too* confident based on the unfortunate phrasing.
Slashdot Mirror
My point was simply that it is a funny thing because they on the one hand obviously were helped by the sites, but also want to shut them down. It's not about copyright ownership and rights, it's about the weirdness of the situation.
There are MANY nes and snes games that ninentendo did NOT publish and has no particular stake in.
Not true. For example, the NES classic edition has Capcom, Konami, Square, and others. They have a stake in it. Also, I would presume they also have some copyrighted material even in third party roms (e.g. library code) so they also almost certainly have a right.
If a copyright holder is active then its not abandonware.
It's worthkeeping in mind that abandonware is not a legally recognized thing. The holder of the rights can at any point decide to go after it.
Only the original copyright holder has the right to make money off these roms.
Financial gain is not a requirement to be sued for violating copyright.
https://www.eurogamer.net/arti...
It's funny, but at the same time they are perfectly within their rights to download from a site for their use, and even sue that same site for infringement. They are the copyright holder after all..
12x1.5" is a pretty big area to suck out of a laptop....
Also, expect these things to be priced in the stratosphere, much much more than I would imagine any laptop consumer spending on even 10 entire laptops...
These would be way too big for laptops.
Generally speaking, laptops are using M.2 modules, which have a screw and a card-edge connector. I haven't owned any laptop that solders storage down to the board.
It is designed for 1U servers that would be designed for it. That's the rub. Yes, they made them 1U wide, and a depth that in theory can fit with processors and dimms. However there isn't leftovers for other things.
Front cabled systems with front drives also could work (albeit without being able to cram in 32 drives, but that's fine...), but front cabling isn't too popular...
Note that it actually quite common now to have drives that go into the front and the back. For these 12" long suckers, that's unlikely and having that volume of NAND chips all front serviceable without a tray would be one point of these things. 12" is however a bit *too* long for reasonable 1U servers. 6" depth might have been a pretty sweet spot, not much longer than 3.5" drives. As such this form factor pretty much requires the design of the server to be focused on the storage to the exclusion of other concerns.
Actually, server *blades* tend to be relatively shallow, they are the least likely to have the depth for this.
1U server is the smallest server form factor that *could* conceivably be adapted to cope (and has to forgo things like even half-length PCIe slots so the CPU and memory can be seated far enough out of the way for the drives to come in.
2U server with the 12" drives flying over the other components is the smallest one where the 12" depth could be accommodated without crazy compromises (you probably will be limited to 1U heatsink for the CPUs, but you would have the ability to have normal network adapters, though the bottom U of the front would probably be relegated to just being air intake.
Well, the point of this is to extend gobs of storage off a single connector. Space wise, 2.5" drives will be more storage per unit volume, but will need more connectors.
These things are really inconvenient in terms of form factor, being over twice as long as even the now 'gigantic' 3.5" drives.
While AR is certainly an interesting concept, I wouldn't want to give up the full VR experience. I'd rather feel totally enveloped. Being able to see the boring old drywall and such mixed with the environment can take something away.
Current user of an oculus rift and the experience is simply fantastic. AR may be more practical if well executed for a lot of work related or local multiplayer gaming for board/tabletop type stuff, but for single player immersive experience... VR...
My personal perspective is that 1:1 movement is overrated. I play 3d games where the avatar moves in ways that I couldn't, or at least ways I'd rather not bother moving.
That said, redirected walking seems a viable approach, at least for extending a large space to an 'infinite' space.
Exactly my concern...
It's one thing if the argument is 'you need to award several smaller *independent* providers', so that a total failure of one vendor is isolated and you can keep going, great I wholeheartedly agree.
It's another if the argument is (and I think this is Oracle's hope) 'you need to compose the solution of many providers at different layers', so that a total failure of any of them is guaranteed to knock everything out.
Broadly speaking, it's a valid concern that we are eager to put all our eggs into as few baskets as possible, and those baskets will have a lot of mono culture in them.
An adversary discovers a way to access some key part of the power infrastructure of a brand Amazon uses and knows of a vulnerability that can deal persistent damage? Poof things could grind to a halt inflicting significant economic damage, and using an attack of a nature that has thus far not justified forceful retaliation in scenarios where it has happened.
Even assuming that from a networking and computer security things were perfect, we still have the reality that a military adversary coordinating an attack on 2 dozen sites could cripple our online infrastructure.
Our love of making these too big to fail companies not only has regrettable economic repercussions, but leaves our online ecosystem way too fragile.
This is true, but that makes this all the more significant of a proof point of the value of competition. In a competitive landscape, there's going to be *someone* to call someone else on their shenanigans, even if it another usually bad actor.
A more accurate analogy would be that whales live underwater, therefore if our whole society is flooded under a mile of water, we'd be ok because whales have proven the world wouldn't end under water.
No matter how slowly we approach Eocene conditions, there's no evidence that our biology will be able to cope with that ecosystem...
Improvement is one thing, but the proposal of writing unit tests and only unit tests as an improvement I disagree with.
I can't give a human a bunch of test cases without saying what it is actually doing and expect a sane result, no way a machine will do better, it has to know the intent not *guessing* the intent (with exceptions).
To the extent it is possible (e.g. machine learning today), you need to feed a model thousands of distinct examples for it to kind of lock on to some guesswork. It still screws up a lot (you feed it 1,000 pictures of sheep to recognize sheep, it messes up on a sheep that is indoors because that happened to not be in the set). We tolerate it for image recognition because while it is terrible, a human just can't describe all the ways to apply image analysis strategies and all the variations of the subject matter. The technique is best effort to tame unstructured data to then work with traditional programming, as once structure has been applied to the data, much easier to manipulate with programming.. The techniques just don't extend to handling structured data.
IT doesn't control my firefox. I install it myself. IT provides me DHCP specified DNS resolver that understands our internal network. They provide the certificate I can install.
This path ultimately leads to firefox resolution acting *differently* than chrome and neither resolving like the rest of the system.
The browser projects need to not internalize name resolution and instead work toward whatever they need out of the OS resolver.
Problem is Firefox is eager to give Cloudfare *all* the DNS traffic, and Chrome is also talking about doing the same, but to 8.8.8.8 (Google's).
So... now what?
"The disconnect between the hype and the reality is significant -- I've never seen anything like it," said Rajesh Kandaswamy, an analyst at Gartner Inc.
That's pretty much the case for most things Gartner sings the praises of from the rooftops. Gartner and IDC's business is largely made at senselessly hyping things up to scare companies into paying them for analyst insight on 'the new hot thing' that they don't get, but must be important....
But the implementation you would end up with would be a secure one, because you tested it for insecure inputs. And it would be a robust one, because your input set for testing is thorough and has good coverage. So there's that.
No, you probably didn't think of all the insecure inputs to design the test for. Unit testing when thoroughly practiced today with full human intelligence striving to pass it ends up with vulnerabilities. The resultant function could in fact be doing the very wrong thing, and just happen to match the test things you input. For example, if I give the tests: 1 gives 2, 2 gives 3, 3 gives 5, and 4 gives 7. Let's say this miracle code generator looks at them and says 'ah ha, he wants a function to return prime numbers!' but no, I wanted exponents for Mersenne primes, so it does the wrong functionality, but it passes all the tests! More specific and more numerous unit tests are not going to be easier than programming, and they won't cause a code generator to produce secure and reliable functionality.
- Do I write my loops and worry about the boundaries? Why? Let the software deal with the boundaries.
Depending on what you mean, this is something programming languages already do. The problem is that if some boundary condition is hit, it isn't psychic and doesn't know what to do about it. In a perl like language, it may be inclined to just no-op on it, which is closest to the ask, and this can produce very bad behavior because while a planned boundary has been violated, the unexpected existence of that data is a real thing and so it isn't handled as someone expects.
Do I worry about whether the collection is sorted? Why? Let the software determine whether the collection is sorted and end the looping early if it can.
There are two ways this can go down, either with a type that explicitly says it is sorted, or the software to iterate over the collection checking if it is sorted, which probably won't save you any time. The former does exist in various languages incidentally.
- Did I specify the collection was sorted to begin with? Why? Let the software look at how the items were collected and used and decide whether to maintain them in sorted order or to sort them, and what sorting algorithm to use.
Ok, so this would not use a sorted type, but it means it has to check if it is sorted... a lot... Also it may *happen* to be sorted but not *need* to be sorted and it would waste a lot of effort maintaining sort to get out of indicating intent. Also, it may guess the *wrong* thing to sort by and produce behavior not desirable.
- Do I worry about paralyzing the transform operation? Let the software break it up and send it to the GPU to do all in one go. Or not if the transformation can't be compiled for GPU. Or not if it will be slower to use the GPU.
I assume you don't mean paralyze. This is an area that could do with better language primitives. There's not much in the way of a standard way of saying 'iterations of this loop are independent of each other'. Closest we get are pools and applying a function, but this can be a bit heavy handed and restrict solutions. For example to get parallelism you might make a function that takes a 32 bit value and parallelize it rather than in a loop, but compiler may know better to use a vector processing facility to batch them. I'm amazed this far into multi-core being the norm and GPGPU being so prominent that languages have not evolved on this front.
Generally speaking, the things you ask for are existing language features or available in libraries to handle certain problem sets. The last case is probably the least addressed, but the answer is going to be 'I have a new programming language' or at least a new version of a programming language or library.
Yes, but let's start saying it. Then someone might do it, or part of it. Then we'll have better tools.
It doesn't really need to be said, because it is so self evident.
But your implementation still has to pass tests, even if you just think them and don't write them down. Writing them down means they can be used outside your own brain.
We have to be honest with ourselves, in practice, test cases don't cover all scenarios. They assume some amount of human intelligence and are there for the 'tricky' cases. If you suddenly had to have test cases for every expected behavior for software to randomly guess algorithms to hit it, it would be as hard as programming, if not harder. Creating a loop to count numbers is utterly trivial, but describing all the test cases that would allow a hypothetical learning strategy to deliver something that would just count numbers would be insane.
Let's expand the number of those problem sets. And then break down big problems into parts that fit into this expanded set
I guess I sholudn't have said 'works' but should have said 'practical'. As above, in most programming, it's *far* easier to just state the things for the computer to do than to tediously describe all sorts of scenarios until random code generation produces something vaguely appropriate. This isn't a matter of refining the techniques, it's just a fundamental reality of that approach.
Note that you don't *need* to have a database, server side execution, javascript assembled DOM, and such.
I do that in some cases.
There is however a documentation site I am responsible for that is just HTML and CSS. People originally said 'oh, it's going to have to be some complex CMS' but we went a different direction. Designers can play with the css and our technical writers just edit text and a build system kicks off to produce HTML and CSS and put to the site.
As a result, much less surface for attacks and a procedure that allows any writer that can edit a text file the ability to do their job. Yet it *looks* clean and modern to the endusers who are oblivious to how 'unfancy' it is under the covers.
There's a phenomenon where you forget how to be 'satisfied' with easy programming. When you start out, you don't know how to do much, but what you can do seems easy. As you acquire experience you become able to do so much more than you ever thought you could.
Then one day years on you take a step back at how you do things and think 'man, this is much more complicated than when I started out'. What you fail to do, however, is try to use those simplistic approaches to solve a problem that you are now used to addressing with all your experience and tools. Then you realize why you needed to leave those simplistic ways behind, and in fact simplistic ways still exist, they just aren't useful as you grow in complexity.
Whether he is writing the code or writing the tests the same description generally applies... The inexperienced developer doesn't understand everything that was asked and a lot of what could go wrong. One could say he should have conveyed the whole thing up front, but practically speaking humans don't think of everything up front, and only recall or conceive of things when faced with an iteration. You realize as you go that situations crop up, or the original design was ill-conceived.
This is an area where I have some reservations about the impact of 'test driven development' on human behavior. Any time you say you have '100% coverage' and 'it passes all the tests', it instills a false sense of security because those tests are likely to be incorrect or inadequate. It's a good idea, but have to not get *too* confident based on the unfortunate phrasing.
Easier said than done.
Basically creating those 'tests' is going to be programming... again... And you could instead... just program...
The whole 'software guesses randomly' works in some very useful, but very narrow problem sets.