I refine this a bit. I'll look at the problem. Often it is something obvious. Easy fix for everyone... except the OEM...
This is the problem.
OEMs do not want anyone ELSE to make money on their offering. If this happens then they failed. They have left money on the table.
And this is why I am very, very upset with the trends in technology these days... The tech market has swung once again into the screw the custie side of the market.... This has happened before, and that pendulum swings back again.... the 3rd party markets learn how to fix the OEM's broken shit, and for a 3 -5 year span no one buys new shit... they pay to have their old shit fixed. I have been through this market cycle a few times. We are about due for a swing to the maker/fixer market....
It is fairly easy to create conditions where an unexpected fatality can occur:
The innards of laptop running on batteries can deliver a fatal shock in a number of ways.
Proper training is a must, even for low-voltage work. It doesn't much of a mistake to achieve conduction across the heart. It only takes a few milliamps of flow to start cardiac-arrest. You only get to make that mistake ONCE if no one is there to attempt to revive you.
Don't mess around with the innards of any electronic gear unless you know the fundamental safety rules, have a good grasp of Ohm's Law and how it applies to the electrical aspects of the Human-Body-Model!
First gen RX-7s with 12A and 13B engines had a carb bypass valve that kicked in when the throttle was closed(idle) && intake vacuum was above a set threshold. (RPM may also have been a factor) This would allow the engine to take in a nearly full charge of air (as if the throttle were almost WOT) without any fuel in it. If at any time during motoring the vacuum dropped too far (lowered engine RPM) or the throttle came off idle, the bypass valve would snap closed to restore correct fuel-air mixture for the air mass.
Without this feature the engine would have terrible motoring characteristics and burn more fuel, due to fundamental differences in how rotaries behave as driven pumps, compared to pistons. As an added benefit it also helped cool the exhaust system.
One drawback to this was that if you were after hyper milling you really want need to shut the motor down, (unless you wanted zero engine drag) you'd just keep upshifting to lower the rpm and thus the pumping loss, while still maintaining the carb-bypass.
I rather liked learning to deal with what turned out to be a very flexible power-plant, because of it's rather wide rage of behaviors. More like a motor-cycle in a lot of ways.
That the Esper is applying interpolative corrections makes perfect sense for the scene. "Enhance" would seem to mean, "figure out what is going on in this picture and correct for possible distortion(s)."
The tools we have today can do this. They can't do it automagically. It generally requires telling the software, "In this region of the picture... Treat *this* curved edge as if it was straight." Doing so would result in an acceptable image.
sorry for replying to my own post... correcting a slight error in my description. Erm cant keep left and right straight... the cot/bed is on the right... and also it is not unusual in remodeled victorians converted to rooming houses to have a room that has an entrance at ether end of the central hallway.
The nitpickers do not understand the scene, or follow Deckard's mindset as he examines the photo.
The view was taken in one room looking into a second room(hallway?) through a doorway. On the opposing wall (in the other room looking through the doorway) is a convex silver mirror. In the right portion of the curved mirror is reflected the image of a partially open door that impinges into the room where the picture was taken. A full length mirror set in the center of the door creates the correct incident angle to reveal the woman lying on the cot, which is out of frame (to the left and low) in the camera's primary view.
The fictional camera that took the picture had a ridiculously long depth of field , and high resolution. The print process was also absurdly high resolution. No other exotic tech is needed to have those elements stored on the print.
The Esper machine, by modern standards, is almost passe.
That scene is one of my favorite reveals of all times.
The Forest Mimms and Art of Electronics suggestions are quite good for threading into the Physics of electronics.
For beginners in embedded space. Lots try to push Ardunio, but the IDE is shit, and much of the libs are a mixed bag. The programmers model is also kind of iffy. You really need to know a lot about C and C++ to get the most out of it. To total noobs C, C++ are asking way too much.
Same for the Pilot systems based on Arduino. If it doesn't do what you need out of the box you'll likely never get it to work without a lot of futzing and learning.
Another approach is: Olimex PIC32-T795 $22 Comes with a decent BASIC interpreter and rudimentary file system on board. Hooks to PC or mac via usb serial. More than adequate for most beginner projects, and well outperforms the home computers all us graybeards started with in the late 70's more RAM (128K), more than a floppy disk worth of file storage, core CPU is 80 times faster than the vintage computers of the day. ~10 us per BASIC token, (give or take)
The Olimex also would interface well to a Raspberry Pi via serial or one of the other serial busses. Additionally once one felt more confident, coding in C is fairly easy on the PIC32 using the MPLabX on MacOS, Win, or Linux. The included BASIC interpreter is open source, and with some ramp-up is easily modifiable. The author of the BASIC interpreter closed the more recent versions of the source but more advanced versions are available for the T795 for free... and you can get non-commercial license versions of the source for free.
For those who want an easy road to PIC18: SDCC and a PICkit2 is a good starter. Though I used to use MPLab as the burner interface via PICStarter, or PICKit3 SDCC will built a.hex file which can be fed to MPLab for simulation and for programming. Many of the worst aspects of the PIC16 programming model don't apply to the PIC18. Many have a good amount of RAM and plenty of FLASH (More than comparable AVRs, and they are much faster, if needed)
3000 ships:
core stats
shields
armor
structure
capacitor
Power
velocity (vector)
acceleration (vector)
turn rate
effective radius (apparent size of hull to sensors)
dynamic resists to damage type drones up to 5 active per ship
drones have all the same stats plus a crude AI that evaluates their flight C&C. up to 8 active missile objects per ship (no other weapon systems create active objects) each module mounted on a ship has it's own set of core stats and state info. Ships may have as few as 5 or more than 20. Each of these modules have more state info than most FPS toons. so: We are talking about over 72000 complex dynamic active objects that project real-time information to every client view, and to the resolving system and may be acted on by a pilot's interpretation of that information.
Now add to that a somewhat simpler state for destroyed ships, disconnected drones, pods, containers, and other objects that are continually added until the event activity collapses.
Add to that: typically furballs like the event from TFA happen in very close quarters where a large percentage of the client nodes are in direct interaction with each other. No other MMO I have ever seen processes anywhere NEAR this much real-time data and even can stay running, let alone (*)tolerably playable.
* doesn't result in a coin-flip result for most participants... etc.
PS: Factor in that this was not an anticipated in-game event, so CCP had little to no opportunity to re-enforce the system node that got hammered. So 3000 brawling ships hammering a 2nd or 3rd string node.
Don't worry about refining. Just take up a device to grind and fuse the material(s) into structural elements. The idea is not to create refined materials, but to fuse what the asteroid gives you into bricks.
Now you have a source of building material in orbit. No need to bring structural elements out of the G-well unless they need very specialized characteristics.
Now you have limited the mass that gets lifted into orbit just to those elements that CANNOT be made in orbit. As time goes on the number of elements lifted out to the station decreases, as refining processes are developed and proven in micro-gravity.
Asteroids are going to have a lot of material aggregates that can be blended and then thermally fused into glasses and stone for use as building materials. Those materials are not so much engineered as characterized for their role in the structure.
Much later after more refined methods are bolted onto the station we could focus on engineered materials, even refining fused blocks that were used to build the older structure(s), since ideally, we would know something about the composition of those earlier assemblies.
Williams Electronics Space invaders -- first use of a micro-processor (Intel 8080) in an arcade video game. Prior to this system, video games were built using discrete TTL display controllers and State-Machines. Atari continued building discrete TTL systems for a few more years until they saw what 'The Steves' did with the 6502 and the Apple I. Woz's sweet-16 library and mini-assember. Microsoft BASIC (Applesoft BASIC and other variants.) Conway's Life Apple DOS 3.3 -- fastest (and simplest hardware) 5.25" floppy-disc storage system on the home market for years. Visicalc A23D1 3D graphics library for Apple ][ and other systems by Bruce Artwick. (1979) A2FS1 3D flight simulator by Bruce Artwick (1979) Three Mile Island -- rare reactor sim with disasters... LISA ('LI ZA') Lazer's Interactive Symbolic Assembler/debugger (1981 IDE) Locksmith ][ nibble copier/patch/sector editor. Any of the Beagle Brothers tool kits. Swashbuckler -- well done 2D sword duel simulation. Sneakers -- used the disc-drive motors as a sound-effect. Apple UCSD PASCAL system -- Many kids my age had our first exposure to structured programming in this PASCAL IDE. Magic Window word processor. (scrolling 80 column word processor for 40 column displays) Scott Adams adventure series. Wizardry Proving Grounds of the Mad Overlord Castle Wolfenstein (Apple ][ version) Robot War (apple ][) simulated robotics game. CGW sponsored tournaments for several years. Corvus Constellation file-server and 1Mbps network platform for Apple ][ systems. Adobe PostScript -- made modern desktop publishing possible AppleTalk -- made sharing laser printers feasible for office environments (per node costs for Ethernet 10Base2 and 10BaseT were still too high for for a number of years) Word for Mac Excel (Mac) MacPaint MacWrite MacDraw Photoshop Illustrator PageMaker HyperCard Band-In-A-Box SoundEdit (destructive waveform editor -- started life as an 8 bit sample editor) Audacity -- (first commonly available wave editor with binaural audio filters)
But seriously, there are only two possibilities for time travel. (1) The universe is fully deteministic in which case the time-travel already occurred and the travel will change nothing, or (2) alternate universe "time-lines" in which case whatever horrible thing you are trying to change still occurred in the original universe and you have just created a copy. Nobody ever deals with that.
3) The universe is fully deterministic, so if you go to past and kill your grandfather before your father was conceived you cease to exist, thus didn't go to past, thus didn't kill your grandfather, thus existed, thus went to past and so on ad infinitum. In other words, time oscillates.
4) The universe is not fully deterministic, so if you go to past and so on, things will play differently at each oscillation and possibly eventually settle into some kind of consistent sequence of events.
5) Time is multi-dimensional. If you go past and kill your grandfather, he once lived to his 80's and now died on his 16th birthday. There's still only one universe/timeline, but it has an attached "metatime" that tracks changes to it (and presumably meta-metatime and so on). The current version of the timeline doesn't include you, but a past (metapast?) one did, thus your grandfater being shot is (meta)causally consistent - it's only invalid with a naive understanding of time.
6) The universe just plain doesn't care about such inconsistencies. You are small, the universe is large, and the illogic of your grandfather dying before your father was conceived is roughly equivalent to the damage my fingers suffered from typing this post - not worth worrying about. Enjoy your living dead grandfather and unborn life.
7) Attempting to travel back in time kicks the traveller and their ship into another (but generally related) causal domain (universe) with ever-so-slightly randomized universal constants. Paradox is not permitted, the traveller appears in the new domain and has to deal with exploring a new universe and it's properties. The slight shift in constants plays havoc: you can't chemically interact with the matter in the new universe.. so you had better have enough matter with you to survive until you learn to incorporate matter that follows the new rules. The new humanoids you meet can't use the matter you brought with you either... wackiness ensues.
With the exception of slashdot eating the time.h and stdio.h header includes, the transcript of the session is what I did and what I got. The result I expected was that time_t is 64 bits even in 32 bit ABI for new code. Now it does work as expected in 64 bit ABI (the default compile behavior for my version of OSX).
uname -a Darwin islabquad 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
vi time.c a #include #include
int main(void) { printf("On this machine, time_t is %zu bits\n", sizeof(time_t)*8); return 0; }:wq gcc -m32 time.c./a.out On this machine, time_t is 32 bits
If you mean "won by default because the Soviet Union collapsed" then yeah, we won.
Oh we gonna redefine 'win' now? For many centuries if your opponent defaults... that is a win. Time honored tradition in chess which is older than most of western civilization.
No it is not a clear a win as having your boot on the opponent's throat, but hey that must be an intelligent opponent, who recognizes that, 1( victory is not possible. 2(Surrender is not acceptable. 3) Capitulation is the best way out.
L: Ok so we just stop this nonsense. Yes?:(
W: Yuuuush!! We Wiii...:D
L: Unless you desire bloodbath.... We could accom... >:(
W: No! No... We'll accept your 'cease...' er position! Position! Yes! We good?:}
L: Is good! No?:|
W: Yes! (Thank God yes!):)
L: Did you say something? >:|
W: No! No. No. Jus... Just glad it is over... He He...:D 3
I don't think most kids new how close it could have come to an immolation, if that had not been handled as well as it was.
As an after-thought.... How is it that we have all these great languages and HLLs and yet no one has really put any effort into writing a decent tool that takes a machine description (registers, machine codes, timings, RTL whatever) and uses that to build a verifiable C (varient) compiler from it? Such a tool might ease a lot of constraints on machine-level design in future processors and make it easier to add constructs to C that reflect it's one-step-above-the-Assembler philosophy that reflect the hardware model rather than the standard C runtime model.
Here's what you sound like to me: "While I agree x86 Assembly is a bad language, it has no competition in x86 machine level coding." Or to use a car analogy: "While I agree Wheels are a bad design, they have no competition in axle mounted circular rolling systems."
It is not just x86 architecture that sucks. There is very few truly innovative machine-level programming models that get beyond 'the ivory tower' state because commercial interests ask the question, "Do you have a C compiler for it?"
We now have a situation where if the programming model does not conform to the C runtime model, you might as well give up. Processor designers have a rough time justifying radical new ideas in programming models because the SDK for the new CPU must include a C compiler, or the CPU will not be adopted in any meaningful volume.
Some attempts are being made... Xmos.com for example and their rather interesting XC variant of C solves a lot of problems by adding concurrency and IPC constructs to C at the lowest level, while leaving the rest of the language largely unmolested. These changes would be useless if implemented on a CPU that did not have machine-codes and register support for them. However Xmos is still too focused on small footprint systems, and after 3 generations of the I/O ring have yet to tackle the problem of scaling their architecture even to where ARM was 10 years ago. Xmos has already shown better market survival than the Inmos Transputer, so I'm hoping there are better implementations on the way.
6x0x and x86 approaches served us well for a long time. We need to rethink the general approach, and bend the language to the hardware rather than bending the hardware to the language. The tail needs to stop wagging the dog.
If we can do that then -eventually- operating system kernels get more efficient and offer better determinism, and higher level constructs get easier to express in more compact notation... It will probably be worthwhile, at that point, to re-factor a lot of this crufty old C we have been dragging in our wake for 40+ years.
Ok... this is is freaking obvious... (IANAPA) however...
Able is a clever guy. He patents a new process for smelting smelt. He does not license this method, but uses it in his own fish processing factory.
Barney is a clever guy too. He processes fish in his own cannery. He sees that Able has patented a new method for smelting smelt. He reads the patent, and realizes that it is more efficient than his method of smelting smelt. He builds a machine based on the published patent and now his smelt smelter is more efficient. He does not sell his implementation either.
Barney has infringed on Able's patent.
Alternative case: EVEN IF Barney had Charley build the smelt smelter and did not know that it infringes on Able's patent he is still liable. The reasoning is that Barney being in the same industry should have known that what Charley built for him might infringe if he had been doing due diligence on Charley's proposal.
This has happened many times over the history of patents in the US and the UK.
Slashdot Mirror
I refine this a bit. I'll look at the problem. Often it is something obvious. Easy fix for everyone... except the OEM...
This is the problem.
OEMs do not want anyone ELSE to make money on their offering. If this happens then they failed. They have left money on the table.
And this is why I am very, very upset with the trends in technology these days... The tech market has swung once again into the screw the custie side of the market.... This has happened before, and that pendulum swings back again.... the 3rd party markets learn how to fix the OEM's broken shit, and for a 3 -5 year span no one buys new shit... they pay to have their old shit fixed. I have been through this market cycle a few times. We are about due for a swing to the maker/fixer market....
It is fairly easy to create conditions where an unexpected fatality can occur:
The innards of laptop running on batteries can deliver a fatal shock in a number of ways.
Proper training is a must, even for low-voltage work. It doesn't much of a mistake to achieve conduction across the heart. It only takes a few milliamps of flow to start cardiac-arrest. You only get to make that mistake ONCE if no one is there to attempt to revive you.
Don't mess around with the innards of any electronic gear unless you know the fundamental safety rules, have a good grasp of Ohm's Law and how it applies to the electrical aspects of the Human-Body-Model!
Time to teach them endian-ness
you are doing it wrong. That is all.
First gen RX-7s with 12A and 13B engines had a carb bypass valve that kicked in when the throttle was closed(idle) && intake vacuum was above a set threshold. (RPM may also have been a factor) This would allow the engine to take in a nearly full charge of air (as if the throttle were almost WOT) without any fuel in it. If at any time during motoring the vacuum dropped too far (lowered engine RPM) or the throttle came off idle, the bypass valve would snap closed to restore correct fuel-air mixture for the air mass.
Without this feature the engine would have terrible motoring characteristics and burn more fuel, due to fundamental differences in how rotaries behave as driven pumps, compared to pistons. As an added benefit it also helped cool the exhaust system.
One drawback to this was that if you were after hyper milling you really want need to shut the motor down, (unless you wanted zero engine drag) you'd just keep upshifting to lower the rpm and thus the pumping loss, while still maintaining the carb-bypass.
I rather liked learning to deal with what turned out to be a very flexible power-plant, because of it's rather wide rage of behaviors. More like a motor-cycle in a lot of ways.
That is 2000 calories of food you are using as a reference. Chemical calories are 1000 times smaller.
1 food calorie = 1000 chemical calories.
So:
2.324 KWh per day, or 1000 AA NI-mh batteries.
That the Esper is applying interpolative corrections makes perfect sense for the scene. "Enhance" would seem to mean, "figure out what is going on in this picture and correct for possible distortion(s)."
The tools we have today can do this. They can't do it automagically. It generally requires telling the software, "In this region of the picture... Treat *this* curved edge as if it was straight." Doing so would result in an acceptable image.
sorry for replying to my own post... correcting a slight error in my description.
Erm cant keep left and right straight... the cot/bed is on the right... and also it is not unusual in remodeled victorians converted to rooming houses to have a room that has an entrance at ether end of the central hallway.
The nitpickers do not understand the scene, or follow Deckard's mindset as he examines the photo.
The view was taken in one room looking into a second room(hallway?) through a doorway. On the opposing wall (in the other room looking through the doorway) is a convex silver mirror. In the right portion of the curved mirror is reflected the image of a partially open door that impinges into the room where the picture was taken. A full length mirror set in the center of the door creates the correct incident angle to reveal the woman lying on the cot, which is out of frame (to the left and low) in the camera's primary view.
The fictional camera that took the picture had a ridiculously long depth of field , and high resolution. The print process was also absurdly high resolution. No other exotic tech is needed to have those elements stored on the print.
The Esper machine, by modern standards, is almost passe.
That scene is one of my favorite reveals of all times.
If it is magic MOKE, you see, then that signals that you need a new 3D chip.
The Forest Mimms and Art of Electronics suggestions are quite good for threading into the Physics of electronics.
For beginners in embedded space. Lots try to push Ardunio, but the IDE is shit, and much of the libs are a mixed bag. The programmers model is also kind of iffy. You really need to know a lot about C and C++ to get the most out of it. To total noobs C, C++ are asking way too much.
Same for the Pilot systems based on Arduino. If it doesn't do what you need out of the box you'll likely never get it to work without a lot of futzing and learning.
Another approach is:
Olimex PIC32-T795 $22
Comes with a decent BASIC interpreter and rudimentary file system on board. Hooks to PC or mac via usb serial. More than adequate for most beginner projects, and well outperforms the home computers all us graybeards started with in the late 70's
more RAM (128K),
more than a floppy disk worth of file storage,
core CPU is 80 times faster than the vintage computers of the day.
~10 us per BASIC token, (give or take)
The Olimex also would interface well to a Raspberry Pi via serial or one of the other serial busses. Additionally once one felt more confident, coding in C is fairly easy on the PIC32 using the MPLabX on MacOS, Win, or Linux. The included BASIC interpreter is open source, and with some ramp-up is easily modifiable. The author of the BASIC interpreter closed the more recent versions of the source but more advanced versions are available for the T795 for free... and you can get non-commercial license versions of the source for free.
For those who want an easy road to PIC18: .hex file which can be fed to MPLab for simulation and for programming. Many of the worst aspects of the PIC16 programming model don't apply to the PIC18. Many have a good amount of RAM and plenty of FLASH (More than comparable AVRs, and they are much faster, if needed)
SDCC and a PICkit2 is a good starter. Though I used to use MPLab as the burner interface via PICStarter, or PICKit3 SDCC will built a
YMMV.
This, in a nutshell.
3000 ships:
core stats
shields
armor
structure
capacitor
Power
velocity (vector)
acceleration (vector)
turn rate
effective radius (apparent size of hull to sensors)
dynamic resists to damage type
drones up to 5 active per ship
drones have all the same stats plus a crude AI that evaluates their flight C&C.
up to 8 active missile objects per ship
(no other weapon systems create active objects)
each module mounted on a ship has it's own set of core stats and state info. Ships may have as few as 5 or more than 20. Each of these modules have more state info than most FPS toons.
so:
We are talking about over 72000 complex dynamic active objects that project real-time information to every client view, and to the resolving system and may be acted on by a pilot's interpretation of that information.
Now add to that a somewhat simpler state for destroyed ships, disconnected drones, pods, containers, and other objects that are continually added until the event activity collapses.
Add to that: typically furballs like the event from TFA happen in very close quarters where a large percentage of the client nodes are in direct interaction with each other.
No other MMO I have ever seen processes anywhere NEAR this much real-time data and even can stay running, let alone (*)tolerably playable.
* doesn't result in a coin-flip result for most participants... etc.
PS: Factor in that this was not an anticipated in-game event, so CCP had little to no opportunity to re-enforce the system node that got hammered. So 3000 brawling ships hammering a 2nd or 3rd string node.
Now: go back to your armchairs /.
Finally a AAR on this incident that doesn't smell like a big steaming pile of bullshit! Thanks AC!
FFS:
Don't worry about refining. Just take up a device to grind and fuse the material(s) into structural elements. The idea is not to create refined materials, but to fuse what the asteroid gives you into bricks.
Now you have a source of building material in orbit. No need to bring structural elements out of the G-well unless they need very specialized characteristics.
Now you have limited the mass that gets lifted into orbit just to those elements that CANNOT be made in orbit. As time goes on the number of elements lifted out to the station decreases, as refining processes are developed and proven in micro-gravity.
Asteroids are going to have a lot of material aggregates that can be blended and then thermally fused into glasses and stone for use as building materials. Those materials are not so much engineered as characterized for their role in the structure.
Much later after more refined methods are bolted onto the station we could focus on engineered materials, even refining fused blocks that were used to build the older structure(s), since ideally, we would know something about the composition of those earlier assemblies.
Williams Electronics Space invaders -- first use of a micro-processor (Intel 8080) in an arcade video game. Prior to this system, video games were built using discrete TTL display controllers and State-Machines. Atari continued building discrete TTL systems for a few more years until they saw what 'The Steves' did with the 6502 and the Apple I.
Woz's sweet-16 library and mini-assember.
Microsoft BASIC (Applesoft BASIC and other variants.)
Conway's Life
Apple DOS 3.3 -- fastest (and simplest hardware) 5.25" floppy-disc storage system on the home market for years.
Visicalc
A23D1 3D graphics library for Apple ][ and other systems by Bruce Artwick. (1979)
A2FS1 3D flight simulator by Bruce Artwick (1979)
Three Mile Island -- rare reactor sim with disasters...
LISA ('LI ZA') Lazer's Interactive Symbolic Assembler/debugger (1981 IDE)
Locksmith ][ nibble copier/patch/sector editor.
Any of the Beagle Brothers tool kits.
Swashbuckler -- well done 2D sword duel simulation.
Sneakers -- used the disc-drive motors as a sound-effect.
Apple UCSD PASCAL system -- Many kids my age had our first exposure to structured programming in this PASCAL IDE.
Magic Window word processor. (scrolling 80 column word processor for 40 column displays)
Scott Adams adventure series.
Wizardry Proving Grounds of the Mad Overlord
Castle Wolfenstein (Apple ][ version)
Robot War (apple ][) simulated robotics game. CGW sponsored tournaments for several years.
Corvus Constellation file-server and 1Mbps network platform for Apple ][ systems.
Adobe PostScript -- made modern desktop publishing possible
AppleTalk -- made sharing laser printers feasible for office environments (per node costs for Ethernet 10Base2 and 10BaseT were still too high for for a number of years)
Word for Mac
Excel (Mac)
MacPaint
MacWrite
MacDraw
Photoshop
Illustrator
PageMaker
HyperCard
Band-In-A-Box
SoundEdit (destructive waveform editor -- started life as an 8 bit sample editor)
Audacity -- (first commonly available wave editor with binaural audio filters)
But seriously, there are only two possibilities for time travel.
(1) The universe is fully deteministic in which case the time-travel already occurred and the travel will change nothing, or
(2) alternate universe "time-lines" in which case whatever horrible thing you are trying to change still occurred in the original universe and you have just created a copy. Nobody ever deals with that.
3) The universe is fully deterministic, so if you go to past and kill your grandfather before your father was conceived you cease to exist, thus didn't go to past, thus didn't kill your grandfather, thus existed, thus went to past and so on ad infinitum. In other words, time oscillates.
4) The universe is not fully deterministic, so if you go to past and so on, things will play differently at each oscillation and possibly eventually settle into some kind of consistent sequence of events.
5) Time is multi-dimensional. If you go past and kill your grandfather, he once lived to his 80's and now died on his 16th birthday. There's still only one universe/timeline, but it has an attached "metatime" that tracks changes to it (and presumably meta-metatime and so on). The current version of the timeline doesn't include you, but a past (metapast?) one did, thus your grandfater being shot is (meta)causally consistent - it's only invalid with a naive understanding of time.
6) The universe just plain doesn't care about such inconsistencies. You are small, the universe is large, and the illogic of your grandfather dying before your father was conceived is roughly equivalent to the damage my fingers suffered from typing this post - not worth worrying about. Enjoy your living dead grandfather and unborn life.
7) Attempting to travel back in time kicks the traveller and their ship into another (but generally related) causal domain (universe) with ever-so-slightly randomized universal constants. Paradox is not permitted, the traveller appears in the new domain and has to deal with exploring a new universe and it's properties. The slight shift in constants plays havoc: you can't chemically interact with the matter in the new universe.. so you had better have enough matter with you to survive until you learn to incorporate matter that follows the new rules. The new humanoids you meet can't use the matter you brought with you either... wackiness ensues.
Glad I checked.... it hadn't come up in anything I worked on. So in the future I say "no!" to 32-bit ABI unless there is a compelling reason not to.
With the exception of slashdot eating the time.h and stdio.h header includes, the transcript of the session is what I did and what I got. The result I expected was that time_t is 64 bits even in 32 bit ABI for new code. Now it does work as expected in 64 bit ABI (the default compile behavior for my version of OSX).
uname -a
Darwin islabquad 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
vi time.c
a
#include
#include
int :wq ./a.out
main(void)
{
printf("On this machine, time_t is %zu bits\n", sizeof(time_t)*8);
return 0;
}
gcc -m32 time.c
On this machine, time_t is 32 bits
fail in 32 bit mode.
I honestly believe they could market SimCity as a destruction simulator, where you develop a town so that you can destroy it over and over again.
Obviously you are way too young to remember:
Crush, Crumble & Chomp.
http://en.wikipedia.org/wiki/Crush,_Crumble_and_Chomp!
Now, get off my lawn. You are blocking my light!
Exploited by a one man starship?!
NO!
DEFEATED by a one man starship!
FFS!
If you mean "won by default because the Soviet Union collapsed" then yeah, we won.
Oh we gonna redefine 'win' now? For many centuries if your opponent defaults... that is a win. Time honored tradition in chess which is older than most of western civilization.
No it is not a clear a win as having your boot on the opponent's throat, but hey that must be an intelligent opponent, who recognizes that, 1( victory is not possible. 2(Surrender is not acceptable. 3) Capitulation is the best way out.
L: Ok so we just stop this nonsense. Yes? :(
W: Yuuuush!! We Wiii... :D
L: Unless you desire bloodbath.... We could accom... >:(
W: No! No... We'll accept your 'cease...' er position! Position! Yes! We good? :}
L: Is good! No? :|
W: Yes! (Thank God yes!) :)
L: Did you say something? >:|
W: No! No. No. Jus... Just glad it is over... He He... :D 3
I don't think most kids new how close it could have come to an immolation, if that had not been handled as well as it was.
As an after-thought.... How is it that we have all these great languages and HLLs and yet no one has really put any effort into writing a decent tool that takes a machine description (registers, machine codes, timings, RTL whatever) and uses that to build a verifiable C (varient) compiler from it? Such a tool might ease a lot of constraints on machine-level design in future processors and make it easier to add constructs to C that reflect it's one-step-above-the-Assembler philosophy that reflect the hardware model rather than the standard C runtime model.
Here's what you sound like to me: "While I agree x86 Assembly is a bad language, it has no competition in x86 machine level coding." Or to use a car analogy: "While I agree Wheels are a bad design, they have no competition in axle mounted circular rolling systems."
It is not just x86 architecture that sucks. There is very few truly innovative machine-level programming models that get beyond 'the ivory tower' state because commercial interests ask the question, "Do you have a C compiler for it?"
We now have a situation where if the programming model does not conform to the C runtime model, you might as well give up. Processor designers have a rough time justifying radical new ideas in programming models because the SDK for the new CPU must include a C compiler, or the CPU will not be adopted in any meaningful volume.
Some attempts are being made... Xmos.com for example and their rather interesting XC variant of C solves a lot of problems by adding concurrency and IPC constructs to C at the lowest level, while leaving the rest of the language largely unmolested. These changes would be useless if implemented on a CPU that did not have machine-codes and register support for them. However Xmos is still too focused on small footprint systems, and after 3 generations of the I/O ring have yet to tackle the problem of scaling their architecture even to where ARM was 10 years ago. Xmos has already shown better market survival than the Inmos Transputer, so I'm hoping there are better implementations on the way.
6x0x and x86 approaches served us well for a long time. We need to rethink the general approach, and bend the language to the hardware rather than bending the hardware to the language. The tail needs to stop wagging the dog.
If we can do that then -eventually- operating system kernels get more efficient and offer better determinism, and higher level constructs get easier to express in more compact notation... It will probably be worthwhile, at that point, to re-factor a lot of this crufty old C we have been dragging in our wake for 40+ years.
Ok... this is is freaking obvious... (IANAPA) however...
Able is a clever guy. He patents a new process for smelting smelt. He does not license this method, but uses it in his own fish processing factory.
Barney is a clever guy too. He processes fish in his own cannery. He sees that Able has patented a new method for smelting smelt. He reads the patent, and realizes that it is more efficient than his method of smelting smelt. He builds a machine based on the published patent and now his smelt smelter is more efficient. He does not sell his implementation either.
Barney has infringed on Able's patent.
Alternative case: EVEN IF Barney had Charley build the smelt smelter and did not know that it infringes on Able's patent he is still liable. The reasoning is that Barney being in the same industry should have known that what Charley built for him might infringe if he had been doing due diligence on Charley's proposal.
This has happened many times over the history of patents in the US and the UK.