Out of curiosity - why would they need to seed the random number generator?
Wouldn't -not- seeding it be better?
I can't speak for Javascript but in most C libraries - at least in the DOS era when I last made this mistake - the library would default to a static seed of its own during program initialisation, probably 0 or something.
As a result, if you made a program that started, output 15 random numbers and then quit, each time you ran it you would get the same 15 numbers.
What you're supposed to do to avoid that is seed the RNG at the program start, using the current time since the epoch as the seed. This is what I was referring to, not using a static seed:P
I thought it was originally going to be that they forgot to seed the random number generator or something.
What the problem actually seems to be is not that they're using random, but how they're using it.
What they essentially did was use something like qsort() to sort the list, but in their comparator function, instead of returning which of the two strings comes first, they return some random crap instead. qsort() or whatever they used was designed to have results that are consistent, and with input like that it could potentially abort and leave the list entirely unsorted. Or if you're really unlucky it could sit there sorting them forever.
AFAIK, most ARM processors do not currently have an FPU. Maybe as FPUs become more common support for using the FPU directly will be added. Just a guess.
The two issues that prevented YouTube from using the Ogg Theora codec still apply.
Many hardware devices already have H.264 decoding built into the chip, ranging from set-top boxes to the iPhone. Moving away would mean losing ability to run on these target devices (or run at an unacceptable frame rate).
Yes, but going by that logic there won't be an H.265 either, because the hardware support doesn't exist in current devices.
The alternative would be to have two versions of the video stored, but they're currently already doing this for Mobile YouTube and regular YouTube, and adding a third wouldn't make much sense.
Since it seems to work by pre-solving the cube and then compiling the solution into instructions for the robot to carry out, it probably wouldn't do anything at all aside from scanning the cube at the start, unfortunately.
This robot does seems to be solving it step-by-step on the fly, though:
You put it in and it snaps shots of the 6 sides of the cube. Those are interpreted by the computer which probably uses a standard solving algorithm. The solution is translated into movements for the robot, and off it goes.
I'm stunned. And here I was thinking it worked by magic. Is that REALLY how it's done?
To be fair, I had initially assumed it was scanning the cube and solving it on-the-fly like a human would, as opposed to scanning first, solving and then executing.
I want to know what happens if you break the cube up and reassemble it so it can't be solved. I'm pretty sure that was possible. If it's not I'm sure it could be accomplished by breaking two cubes and creatively swapping the parts over.
AFAIK you can only write subroutines in native code, you have to use Java for the main program and IIRC the user interface. The NDK is intended to be used for number-crunching, or reusing large amounts of existing logic written in C/C++.
Are you using the Ubuntu bundled version of 3.1, by any chance? Canonical have managed to destroy it somehow. What you're describing is a known issue in the Ubuntu version.
It did two disagreeable things to me - firstly, attempting to stretch or move an image would make it distort the image so you couldn't see what it was doing, and secondly, it was unable to save documents correctly.
I was using it to make a 4-page document for a CD booklet with the lyrics etc in a bunch of frames. When the document was reloaded, it had reduced to 3 pages and splattered the frames everywhere, seemingly at random.
The primary solution to these problems at the moment seems to be uninstalling the broken Canonical version and installing the official OOo binaries instead.
The article - even the summary - quite clearly says that they're dropping it from the default install. If you want it, you install it. Problem solved.
Personally I ended up removing it anyway since it took too much space on the SSD and I almost never used it while travelling...
Printing paper is not made from mahogany felled in virgin rainforests. In the UK at least, it is made from fast-growing trees like pine which are grown specifically for the purpose of making it and continuously replanted as the more mature trees are felled. So ultimately, the demand for paper ensures that the forest itself is being preserved. If the demand for paper from commercial forests dried up the land would probably be turned into parking lots or houses instead.
That's cool. They can not care what their users think, and not support big popular websites, and they can have all the ideology they want and no users.
Hundreds of millions of people use Firefox, according to Mozilla's estimates. Even a modest amount per infringement would result in legal damages of at least one billion dollars.
Sadly I missed U7 when it came out on original release as I still had a 286 at the time.
Targeting EMS would have allowed it to work with an actual EMS memory card, which may have been faster than EMM386' emulation.
Whether they could have used EMM386 as part of Voodoo to provide a VCPI interface and get into ring 0 that way, I don't know. As you say, it may have been too new, or it might have made reserving the extended memory they wanted to use a more difficult task.
When I did my synthesizer I just kicked DOS in the nuts and stole the memory since it's a single-purpose appliance rather than an application.
Because I happen to have read about this way back when (either on the Exult list or Ultima-Dragons newsgroup), I figure I may as well expand on the technical issues, and why it was done this way.
Warning - blast from the past.
Voodoo memory worked by putting the machine into 32-bit protected mode, opened up the FS selector (or GS?) to have a 32-bit linear address space and then switched it back into real-mode. Owing to a quirk of the CPU design, the FS register was left with a full 32-bit address space, which could be accessed via assembler code.
This sounds like a hack, and it was, but from what I've heard it was the only way they were able to get the performance they needed for the game to be playable on the average hardware of the day, a 386sx running at 16MHz.
I have done the voodoo trick myself actually, when I had an attack of insanity and decided to make my own MIDI synth in DOS - but that's another story.
Anyway, Ultima 7 was made with Borland C, which was a 16-bit compiler. In order to make the program work they had to swap blocks of memory in and out of the 640k region that DOS programs can access. From what I heard they tried everying - swapping to disk, EMS and XMS but swapping via 'voodoo' memory was the only acceptable solution in terms of performance. DOS extenders as used in Doom etc were unheard of at the time and Win32 didn't even exist.
The problem - which really came a few years later - was that it wouldn't work if you had EMM386 running in DOS, or if you tried to run it inside a DPMI host such as Windows.
Pagan did use a DOS extender, but a 16-bit one. Probably they still wanted to use Borland as the compiler since it was one of the best ones available at the time. They either used Phar Lap/16 or Rational Systems DOS16M as the extender, but I'd have to look at the program to see. They hit a different problem, though.
The graphics engine used a lot of assembler and this used the 386 extended registers for performance reasons. After all, why blit stuff to the framebuffer in 8 or 16 bit blocks when you can do it 32 bits at a time? The problem was that the 16-bit DOS extender was only preserving the lower 16 bits when an interrupt occurred which meant that the game would run fine for a while and then randomly crash when an interrupt happened at the wrong moment, trashing the upper word of a crucial register.
To get around this, they had to hack the kernel somehow to add support for this, a mechanism which I believe Jason Ely referred to as "Spanky" or somesuch. I don't know how they did this but I suspect they used ring-0 code to do it... while it was rather more tolerant of running under a different DPMI host, Pagan still wouldn't run under Windows.
So, if you ever wondered what the kernel hacking stuff in the Pagan credits was all about, there you go:P
Whether they glow is relative to the type and *amount* of radiation. I take it that you don't remember radium watch dials?
No argument about secondary radiation, but I think you'll find the green glow is a myth. Blue glow, yes - see Cerenkov radiation. I think you'll find that the radium watches work by energizing phosphor or some similar fluorescent material. In other words, it is the phosphor which is glowing green, not the radium itself.
I don't think ARM supports 64-bit addressing, either. For most things that doesn't matter, but for netbook type machines, it's going to become an issue in the next 5 years at most.
Am I reading this right? If I make a ceramic tile design, I'll get a cut from all future ceramics made with that pattern, anywhere in the EU or Canada? I think I'm in the wrong industry.
Probably... but most Windows apps won't run on it without recompiling. And people don't buy Windows to run Windows, they buy Windows to run Windows apps.
I guess C# and the like could be an option, but running non-native code on ARM seems like masochism to me.
It will take more than a recompilation in most cases, I assure you. Windows CE 5 (which is what the netbooks are using) has a per-process limitation of 32MB. It's touch and go whether you can allocate more than 1MB in a single chunk, at least that's been my experience.
The APIs are subtly different so you will have to find the places where you've used the SendMessageA or something instead of SendMessageW, or where the parameters are simply different and fix those. You'll have to rewrite the menu handling as the APIs are simply not the same. You'll have to rewrite it again for the Windows Mobile version as they're different again. You'll have to make sure you're not relying on the current working directory because CE doesn't support that.
All in all, it can be done (I've gone the other way, CE->win32) but it would be a major problem for anything substantial as you'll run out of memory and have to use memory-mapped files or some other hack. I would imagine that most developers wouldn't bother. Using.NET rather than straight C++ might help a bit, but I can't see it overcoming the memory limitation - it's liable to make things worse as the runtime will want its share, and you won't be able to roll your own memory manager to access >32MB.
It is dead simple to find apps that run on Windows Mobile.
Yes. And they won't work either! You can make a CE app that runs on WM, but a WM app will not run on bare CE because of many missing dependencies. AYGSHELL in particular.
All the CE-based netbooks I have seen so far are using just the bare CE.NET core.
Your tv - is essentially not much more than 2 glass plates with small cells with either gases or liquid crystals in them, and 2 plastic plates to cover it all, and then one graphics chip cpu-fpu-memory and all in one, plus a chip for digital tv-decoding and a tuner. These SMD components cost so little
that you could buy a burger for what it actually cost to manufacture.
I imagine the machinery needed to assemble those small cells correctly and accurately is pretty expensive. However, I'd agree that the price isn't likely to drop once the capital costs of the manufacturing plant have been amortized.
Slashdot Mirror
Out of curiosity - why would they need to seed the random number generator?
Wouldn't -not- seeding it be better?
I can't speak for Javascript but in most C libraries - at least in the DOS era when I last made this mistake - the library would default to a static seed of its own during program initialisation, probably 0 or something.
As a result, if you made a program that started, output 15 random numbers and then quit, each time you ran it you would get the same 15 numbers. :P
What you're supposed to do to avoid that is seed the RNG at the program start, using the current time since the epoch as the seed. This is what I was referring to, not using a static seed
What the problem actually seems to be is not that they're using random, but how they're using it.
What they essentially did was use something like qsort() to sort the list, but in their comparator function, instead of returning which of the two strings comes first, they return some random crap instead. qsort() or whatever they used was designed to have results that are consistent, and with input like that it could potentially abort and leave the list entirely unsorted. Or if you're really unlucky it could sit there sorting them forever.
AFAIK, most ARM processors do not currently have an FPU. Maybe as FPUs become more common support for using the FPU directly will be added. Just a guess.
The two issues that prevented YouTube from using the Ogg Theora codec still apply.
Many hardware devices already have H.264 decoding built into the chip, ranging from set-top boxes to the iPhone. Moving away would mean losing ability to run on these target devices (or run at an unacceptable frame rate).
Yes, but going by that logic there won't be an H.265 either, because the hardware support doesn't exist in current devices.
The alternative would be to have two versions of the video stored, but they're currently already doing this for Mobile YouTube and regular YouTube, and adding a third wouldn't make much sense.
Actually there seem to be more than just two, AFAIK there's at least fmt=6, fmt=18, fmt=22...
A quick googling reveals this list: http://en.wikipedia.org/wiki/YouTube#Quality_and_codecs
This robot does seems to be solving it step-by-step on the fly, though:
http://www.youtube.com/watch?v=htnL1KTpaY8
You put it in and it snaps shots of the 6 sides of the cube. Those are interpreted by the computer which probably uses a standard solving algorithm. The solution is translated into movements for the robot, and off it goes.
I'm stunned. And here I was thinking it worked by magic. Is that REALLY how it's done?
To be fair, I had initially assumed it was scanning the cube and solving it on-the-fly like a human would, as opposed to scanning first, solving and then executing.
I want to know what happens if you break the cube up and reassemble it so it can't be solved. I'm pretty sure that was possible. If it's not I'm sure it could be accomplished by breaking two cubes and creatively swapping the parts over.
AFAIK you can only write subroutines in native code, you have to use Java for the main program and IIRC the user interface. The NDK is intended to be used for number-crunching, or reusing large amounts of existing logic written in C/C++.
You are aware then that in his later years he tied all his universes together, right?
I think that Watership Down should be tied into the Foundation universe as well.
It did two disagreeable things to me - firstly, attempting to stretch or move an image would make it distort the image so you couldn't see what it was doing, and secondly, it was unable to save documents correctly.
I was using it to make a 4-page document for a CD booklet with the lyrics etc in a bunch of frames. When the document was reloaded, it had reduced to 3 pages and splattered the frames everywhere, seemingly at random.
The primary solution to these problems at the moment seems to be uninstalling the broken Canonical version and installing the official OOo binaries instead.
The article - even the summary - quite clearly says that they're dropping it from the default install. If you want it, you install it. Problem solved.
Personally I ended up removing it anyway since it took too much space on the SSD and I almost never used it while travelling...
Printing paper is not made from mahogany felled in virgin rainforests. In the UK at least, it is made from fast-growing trees like pine which are grown specifically for the purpose of making it and continuously replanted as the more mature trees are felled. So ultimately, the demand for paper ensures that the forest itself is being preserved. If the demand for paper from commercial forests dried up the land would probably be turned into parking lots or houses instead.
I simply assumed it was a brain-damaged version of the Cortex A8...
That's cool. They can not care what their users think, and not support big popular websites, and they can have all the ideology they want and no users.
Hundreds of millions of people use Firefox, according to Mozilla's estimates. Even a modest amount per infringement would result in legal damages of at least one billion dollars.
Sadly I missed U7 when it came out on original release as I still had a 286 at the time.
Targeting EMS would have allowed it to work with an actual EMS memory card, which may have been faster than EMM386' emulation.
Whether they could have used EMM386 as part of Voodoo to provide a VCPI interface and get into ring 0 that way, I don't know. As you say, it may have been too new, or it might have made reserving the extended memory they wanted to use a more difficult task.
When I did my synthesizer I just kicked DOS in the nuts and stole the memory since it's a single-purpose appliance rather than an application.
Because I happen to have read about this way back when (either on the Exult list or Ultima-Dragons newsgroup), I figure I may as well expand on the technical issues, and why it was done this way.
Warning - blast from the past.
Voodoo memory worked by putting the machine into 32-bit protected mode, opened up the FS selector (or GS?) to have a 32-bit linear address space and then switched it back into real-mode. Owing to a quirk of the CPU design, the FS register was left with a full 32-bit address space, which could be accessed via assembler code.
This sounds like a hack, and it was, but from what I've heard it was the only way they were able to get the performance they needed for the game to be playable on the average hardware of the day, a 386sx running at 16MHz.
I have done the voodoo trick myself actually, when I had an attack of insanity and decided to make my own MIDI synth in DOS - but that's another story.
Anyway, Ultima 7 was made with Borland C, which was a 16-bit compiler. In order to make the program work they had to swap blocks of memory in and out of the 640k region that DOS programs can access. From what I heard they tried everying - swapping to disk, EMS and XMS but swapping via 'voodoo' memory was the only acceptable solution in terms of performance. DOS extenders as used in Doom etc were unheard of at the time and Win32 didn't even exist.
The problem - which really came a few years later - was that it wouldn't work if you had EMM386 running in DOS, or if you tried to run it inside a DPMI host such as Windows.
Pagan did use a DOS extender, but a 16-bit one. Probably they still wanted to use Borland as the compiler since it was one of the best ones available at the time. They either used Phar Lap/16 or Rational Systems DOS16M as the extender, but I'd have to look at the program to see. They hit a different problem, though.
The graphics engine used a lot of assembler and this used the 386 extended registers for performance reasons. After all, why blit stuff to the framebuffer in 8 or 16 bit blocks when you can do it 32 bits at a time? The problem was that the 16-bit DOS extender was only preserving the lower 16 bits when an interrupt occurred which meant that the game would run fine for a while and then randomly crash when an interrupt happened at the wrong moment, trashing the upper word of a crucial register.
To get around this, they had to hack the kernel somehow to add support for this, a mechanism which I believe Jason Ely referred to as "Spanky" or somesuch. I don't know how they did this but I suspect they used ring-0 code to do it... while it was rather more tolerant of running under a different DPMI host, Pagan still wouldn't run under Windows.
So, if you ever wondered what the kernel hacking stuff in the Pagan credits was all about, there you go :P
Abstraction layers.
Whether they glow is relative to the type and *amount* of radiation. I take it that you don't remember radium watch dials?
No argument about secondary radiation, but I think you'll find the green glow is a myth. Blue glow, yes - see Cerenkov radiation. I think you'll find that the radium watches work by energizing phosphor or some similar fluorescent material. In other words, it is the phosphor which is glowing green, not the radium itself.
I don't think ARM supports 64-bit addressing, either. For most things that doesn't matter, but for netbook type machines, it's going to become an issue in the next 5 years at most.
Damn, that's a great shame. Wasn't he also responsible for the special effects in Dark Star and parts of Star Wars?
Am I reading this right? If I make a ceramic tile design, I'll get a cut from all future ceramics made with that pattern, anywhere in the EU or Canada? I think I'm in the wrong industry.
Probably... but most Windows apps won't run on it without recompiling. And people don't buy Windows to run Windows, they buy Windows to run Windows apps.
I guess C# and the like could be an option, but running non-native code on ARM seems like masochism to me.
It will take more than a recompilation in most cases, I assure you. Windows CE 5 (which is what the netbooks are using) has a per-process limitation of 32MB. It's touch and go whether you can allocate more than 1MB in a single chunk, at least that's been my experience.
The APIs are subtly different so you will have to find the places where you've used the SendMessageA or something instead of SendMessageW, or where the parameters are simply different and fix those. You'll have to rewrite the menu handling as the APIs are simply not the same. You'll have to rewrite it again for the Windows Mobile version as they're different again. You'll have to make sure you're not relying on the current working directory because CE doesn't support that.
All in all, it can be done (I've gone the other way, CE->win32) but it would be a major problem for anything substantial as you'll run out of memory and have to use memory-mapped files or some other hack. I would imagine that most developers wouldn't bother. Using .NET rather than straight C++ might help a bit, but I can't see it overcoming the memory limitation - it's liable to make things worse as the runtime will want its share, and you won't be able to roll your own memory manager to access >32MB.
It is dead simple to find apps that run on Windows Mobile.
Yes. And they won't work either! You can make a CE app that runs on WM, but a WM app will not run on bare CE because of many missing dependencies. AYGSHELL in particular.
All the CE-based netbooks I have seen so far are using just the bare CE.NET core.
Your tv - is essentially not much more than 2 glass plates with small cells with either gases or liquid crystals in them, and 2 plastic plates to cover it all, and then one graphics chip cpu-fpu-memory and all in one, plus a chip for digital tv-decoding and a tuner. These SMD components cost so little that you could buy a burger for what it actually cost to manufacture.
I imagine the machinery needed to assemble those small cells correctly and accurately is pretty expensive. However, I'd agree that the price isn't likely to drop once the capital costs of the manufacturing plant have been amortized.
Damn. Make that "See the exFAT (or memory stick) pages on wikipedia."