It links to the original article, which was missing on the 6th (so I couldn't link to it) but is now back. Notice that the title graphic to that site says "News That's Almost Reliable"? It's an Onion-style fake news site. Today's headlines are "Paul Ryan claims to be a descendant of Jesus Christ", "Democrats put God in Platform, adding Odin, Zeus, Mothra", and "GOP Celebrates New ‘PreSin’ Pregnancy Prevention Pill".
What few toll booths have already been installed on the northern part of 130 are scheduled to be removed. This isn't some damn Yankee urban toll road. For those who don't have an RFID TxTag (which works on all but a few obscure toll roads in Texas), license plate recognition cameras are used to send you a bill in the mail. Just don't be late on paying it; I've heard that they tack on some nasty "administrative fees" for late payment.
FWIW, it follows 183 from the South 45 intersection down to just before Lockhart, then splits off to just east of Seguin to reach I-10. 183 will be the frontage road of 130 for that section.
This is in keeping with a general principle of "don't make it worse than before for the non-toll drivers" that is why 45 North has free bypass lanes under the Parmer bridge. (Note that the current lack of free frontage roads on 183A and 45N/Loop 1 still applies, since there were no roads there before. That being said, the lack of free frontage on 45N just before 130 still pisses me off the few times I go that way.)
But yeah, all this grabbing for toll roads (OH LOOK FREE GUMMINT MONEYS!) is stupid. I think San Antonio may have managed to escape it in the 1604/281/Stone Oak area, but it was looking bad for a while.
And...
1: it's a toll road, which reduces traffic from the start
2: it's a toll road, so there are fewer entrances and exits
3: it's RFID toll tag or pay-by-mail (using license plate recognition cameras) ONLY, and existing toll booths on the north half will be removed, further reducing obstacles
4: not only is it a divided highway (or "dual carriageway" as they say on the other side of the pond), but
5: it's being built with a concrete surface, not asphalt (all the toll roads around Austin have been concrete) so you won't have potholes
6: it completely bypasses the Austin metro area and the overloaded San Antonio to Austin I-35 route, even avoiding small towns (part of the point, since this would have been the route for the now-defunct TTC project)
Even on the overloaded San Antonio to Austin section of I-35, traffic often goes 75-85mph when traffic is light.
(Author's note: Apparently, some folks are upset that I didn't explicitly state that this original story appeared on a satirical site - though I clearly linked to it in the piece. The point of my piece was to point out that it couldn't possibly be true - not to "debunk" a satire. It was meant to remind folks not to simply share without reading - also in the original story - and not to merely rely on a headline or a sentence in an email for your news. Those of you who stop by the blog regularly get that and I appreciate it. I'm not going to change the original piece but I am going to clarify this in big red letters at the top so that the rest of you can sleep a little better.)
I was going to mod you up, then I tried the link... "Page Not Found The page you requested could not be found."
Then I googled it and guess what was the first hit? That missing page.
Then I noticed that all of the links on the first page of results were rougly identical... except one: a Forbes article that included:
(Author's note: Apparently, some folks are upset that I didn't explicitly state that this original story appeared on a satirical site - though I clearly linked to it in the piece. The point of my piece was to point out that it couldn't possibly be true - not to "debunk" a satire. It was meant to remind folks not to simply share without reading - also in the original story - and not to merely rely on a headline or a sentence in an email for your news. Those of you who stop by the blog regularly get that and I appreciate it. I'm not going to change the original piece but I am going to clarify this in big red letters at the top so that the rest of you can sleep a little better.)
I've amassed a large collection of Zip disks from thrift store shopping over the years. Too bad that most people either never used them or actually bothered to delete everything before getting rid of them, because digital archaeology can be so fun.
And what's really sad is that it's easier to make a random tiny computer (like an Arduino or some kind of ARM-based SoC) use an SD card that can hold 20 or more Zip disks worth of data than it is to use an actual Zip drive. So they're really completely useless.
My first computer was that 1977 TRS-80 Model I, with the 600 baud cassette tape player. It finally bit the dust around 1990.
That's 500 baud, unless you started with Level I basic, which I think was 250 baud. I still have a lot of tapes from 1979-1981 or so that I need to decode (1979, 14th birthday, Level II 16K). I finally decided to try a few weeks ago, and guess who still sells a cassette tape player? The Shack. CTR-121, fifty bucks. I did some rips with Audacity with beautiful waveforms, but what bits of code I have to decode from WAVs don't work with them.
A few years later I got a CoCo 4K (and immediately upgraded it to 16K) just because I wanted to play with 6809 assembly language. But then I became one of the first "switchers" and went straight to Macintosh in 1985. I had a Fidonet BBS on a PC, and had Linux PCs to do internet stuff, but I've used Mac all the way, even through the crappy days of the early PowerPC era.
A few years ago I imaged all my old TRS-80 floppies with a Catweasel board, with no errors beyond the ones from 20+ years ago. Then I tried to image a bunch of other random disks I'd acquired for other systems, mostly from being a thrift store junkie. Atari 8-bit wasn't too bad, just a speeded up motor and inverted data. Apple II took some work to make a GCR decoder, and I got both 13-sector and 16-sector working. But Commodore's GCR method was crap. It doesn't even have a proper address mark like Apple II does, so it's hard to sync up to the bitstream.
My ultimate goal is to rig up that Catweasel with an 8-inch drive and read a bunch of TRS-80 Model II/16 disks that I have. I have a few old machines with 8" drives under piles of stuff, and I should be able to get at least one of them working.
Back in the day, early '80s, someone at the local TRS-80 user group would buy large quantities of floppy disks so that everyone could take advantage of the better pricing. I get a box, take it home, and try to format it. Instead of the "Click... click... click..." the drive went RAT-A-TAT-A-TAT! They were hard sectored (10, I think), so formatting was stepping eleven times faster than normal.
Anyhow, I imaged all my old disks a few years ago with a Catweasel board. It uses the ultimate formatting method: time between magnetic changes. There were no disk errors other than the ones that were already there 20+ years before.
Then go find your own. I've been meaning to find out more about them (had reasons why I couldn't so far) and this got me to click the link and look at their map. And now I know that they're very near where I work. I was expecting them to be on the south side of town or something like that. (going between north and south Austin can take a while even with good traffic, and Austin traffic usually sucks)
If you change the size of a block of assembly code, you have to adjust pointers throughout that segment and beyond. This is the task of an assembler and linker, working on your source code. For ROM hacking, you don't have the source. It's infeasible--and provably uncomputable in the general case--to know where all these pointers are, so that you can adjust them when you rebuild with hacks in place.
It is possible, but it's a lot of work, and it grows with the size of the code. First you have to start with a disassembler that traces down branches and calls, then you have to keep looking for more code that didn't get traced because it was referenced from a jump table somewhere, and tell the disassembler to search that too.
It also depends on the instruction set of the CPU, and how pointers get represented in memory. In 6502 code, each byte of a data record is often put in separate tables, and jump tables that use PHA/PHA/RTS will use the address - 1 because of the way RTS works.
But in my experience, the hard work is data blocks with pointers to other blocks that contain even more pointers. When the code is in assembly language, a lot more liberties can be taken with data formats than would be done in C code. Sometimes the only way to be sure is to find the code that accesses the tables, and identify which offsets contain addresses under which conditions.
It's one thing to do this to an arcade-style game that's 16K bytes. It's completely different trying to do this to an RPG of a few hundred K bytes. I've done the former, but never had the guts to try the latter.
Instead of a machine with a ghost inside, package contained cardboard sleeve containing black plastic disc with strange grooves on it. Would not buy again.
What icons? I ad-blocked those icons a long time ago. I just now noticed that my cursor doesn't even give me the finger anymore as I scrub over where those icons used to be (it did when they first added that crap). I've also ad-blocked that annoying "sharethis" or whatever it is that web sites include to create a popup with like 20 hipster social crap sharing icons. Ad-block isn't just for ads. (Though you could justifiably call all those icons a form of advertisement.)
The best way to filter is to make sure that their screens are easily visible to passers-by. Kind of hard to watch porn when your screen is set up nice and high where everyone can see it.
I'm surprised to see that nobody has mentioned frequency bands yet. It sounds like your phone is a European model. The problem is that different parts of the world use different frequencies for mobile phone service, and now even different technologies, too.
From what I understand, pretty much all of Europe uses the GSM on the same frequency bands, so you can shuffle around SIM cards all day. But in the US, the frequencies are different from Europe. Even more of a problem is that GSM isn't dominant here. And now 3G and 4G are coming.
So sure, you could stick in a SIM card, but can your phone even talk on the right frequencies? If it is a "quad band" phone, you may be in luck.
Actually, no. If you just change 'struct' to 'class', and don't use virtual methods or templates, there is absolutely no bloat vs the same C code.
But to achieve this there is, however, a tradeoff. Which method actually gets used is determined statically at compile time by what you declared it as. If you declare an object pointer CBase* p, and assign a CSubclass* pointer to it, calling p->Foo will always call CBase::Foo and never call CSubclass::Foo. If you can't live with that behavior, then you were probably going to need function pointers anyhow, and for 4 bytes extra per struct you can make as many virtual methods as you want. If you needed more than one, only one vtable is created per class, as opposed to needing 4 bytes per function pointer in every instance of your struct.
When I first used C++ classes, I actually saved memory because it replaced code that had one messy uber-union that covered all kinds of different memory allocations for various sorts of thingies (and therefore enough for the largest was always allocated), and switch statements everywhere. Afterwards, each thingy got exactly the RAM it needed (from a fixed allocation pool managed by the base class, since this was on a SoC with 64K RAM) and the switch statements were replaced with virtual functions for each thingy. The code was significantly more readable, too.
But templates are indeed a mess. They cause code bloat because for every object type you want to use with a template, it generates a completely new function just like the others it created before, with the only changes being for the new type. This is in comparison to the Smalltalk style of Objective C, where you can write a single function to work on (effectively) anonymous objects. And the STL assumes you have a heap, which is often not the case in embedded systems programming. The only template I have used is one I created to handle a fixed length array of flag bits, because it made my code a little easier to read.
I've read their guidelines, and they're doing much like I've been doing recently with moving from C to C++ for embedded systems programming, which is to avoid the really crazy shit that you can do in C++. In particular, exceptions and RTTI are absolutely verboten. They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source. Any templates outside of STL are also forbidden ("template hell" sucks), and I won't even use STL myself because I can't count on having a heap. Even iostreams are being frowned on except maybe possibly in debug dump code where no text language translations are needed.
C++ can really tidy up C code that uses any sort of function pointer hooks or object dispatch style switch statements with virtual methods. A class can become a mini-API, and even used as a sort of device-driver, as in the mbed libraries. Doing this has really helped improve encapsulation in my own code.
You forgot to mention that the lander is MOVING during re-entry, with multiple attitude changes. (For OP, that means it turns around different ways.) Even ignoring the "other side of Mars" problem, it would not only require being able to accurately aim a high-gain antenna, but the antenna would have to be physically mounted where it could point at Earth at all times during descent. AT ALL TIMES. And at that distance you have to use directional antennas, which have to be rather precisely aimed at the other end, which doesn't go well with the kind of vibration you get during descent. It just ain't gonna happen.
The problem isn't getting "a little" bandwidth for streaming video, it's getting ANY significant bandwidth beyond simple telemetry. Even audio wants a few kbits/sec. And if you somehow managed to get a 64x64x16-gray postage stamp video into a low bandwidth, it would be useless at such a small size. Most importantly, it wouldn't tell you anything important. Knowing just the few numbers relating to the vehicle status and position updated every second is much more useful and efficient.
And for what it's worth, the lander took a bunch of high-resolution pictures during descent for a stop-motion video. So far they've only uploaded down-sampled versions of a fraction of them. Eventually they'll get them all, but the point is it took a few days before we even got all of the down-sampled series.
Slashdot Mirror
It links to the original article, which was missing on the 6th (so I couldn't link to it) but is now back. Notice that the title graphic to that site says "News That's Almost Reliable"? It's an Onion-style fake news site. Today's headlines are "Paul Ryan claims to be a descendant of Jesus Christ", "Democrats put God in Platform, adding Odin, Zeus, Mothra", and "GOP Celebrates New ‘PreSin’ Pregnancy Prevention Pill".
Your Delorean can reach 88? With the stock 130hp engine?
What few toll booths have already been installed on the northern part of 130 are scheduled to be removed. This isn't some damn Yankee urban toll road. For those who don't have an RFID TxTag (which works on all but a few obscure toll roads in Texas), license plate recognition cameras are used to send you a bill in the mail. Just don't be late on paying it; I've heard that they tack on some nasty "administrative fees" for late payment.
FWIW, it follows 183 from the South 45 intersection down to just before Lockhart, then splits off to just east of Seguin to reach I-10. 183 will be the frontage road of 130 for that section.
This is in keeping with a general principle of "don't make it worse than before for the non-toll drivers" that is why 45 North has free bypass lanes under the Parmer bridge. (Note that the current lack of free frontage roads on 183A and 45N/Loop 1 still applies, since there were no roads there before. That being said, the lack of free frontage on 45N just before 130 still pisses me off the few times I go that way.)
But yeah, all this grabbing for toll roads (OH LOOK FREE GUMMINT MONEYS!) is stupid. I think San Antonio may have managed to escape it in the 1604/281/Stone Oak area, but it was looking bad for a while.
...from lack of food and water?
And...
1: it's a toll road, which reduces traffic from the start
2: it's a toll road, so there are fewer entrances and exits
3: it's RFID toll tag or pay-by-mail (using license plate recognition cameras) ONLY, and existing toll booths on the north half will be removed, further reducing obstacles
4: not only is it a divided highway (or "dual carriageway" as they say on the other side of the pond), but
5: it's being built with a concrete surface, not asphalt (all the toll roads around Austin have been concrete) so you won't have potholes
6: it completely bypasses the Austin metro area and the overloaded San Antonio to Austin I-35 route, even avoiding small towns (part of the point, since this would have been the route for the now-defunct TTC project)
Even on the overloaded San Antonio to Austin section of I-35, traffic often goes 75-85mph when traffic is light.
From http://www.forbes.com/sites/kellyphillipserb/2012/07/30/why-i-dont-believe-that-anonymous-hacked-the-irs-for-romneys-returns/ :
(Author's note: Apparently, some folks are upset that I didn't explicitly state that this original story appeared on a satirical site - though I clearly linked to it in the piece. The point of my piece was to point out that it couldn't possibly be true - not to "debunk" a satire. It was meant to remind folks not to simply share without reading - also in the original story - and not to merely rely on a headline or a sentence in an email for your news. Those of you who stop by the blog regularly get that and I appreciate it. I'm not going to change the original piece but I am going to clarify this in big red letters at the top so that the rest of you can sleep a little better.)
I was going to mod you up, then I tried the link... "Page Not Found The page you requested could not be found."
Then I googled it and guess what was the first hit? That missing page.
Then I noticed that all of the links on the first page of results were rougly identical... except one: a Forbes article that included:
(Author's note: Apparently, some folks are upset that I didn't explicitly state that this original story appeared on a satirical site - though I clearly linked to it in the piece. The point of my piece was to point out that it couldn't possibly be true - not to "debunk" a satire. It was meant to remind folks not to simply share without reading - also in the original story - and not to merely rely on a headline or a sentence in an email for your news. Those of you who stop by the blog regularly get that and I appreciate it. I'm not going to change the original piece but I am going to clarify this in big red letters at the top so that the rest of you can sleep a little better.)
So it looks like Snopes needs to add this one.
Just don't get it confused with Ceti Alpha V!
I've amassed a large collection of Zip disks from thrift store shopping over the years. Too bad that most people either never used them or actually bothered to delete everything before getting rid of them, because digital archaeology can be so fun.
And what's really sad is that it's easier to make a random tiny computer (like an Arduino or some kind of ARM-based SoC) use an SD card that can hold 20 or more Zip disks worth of data than it is to use an actual Zip drive. So they're really completely useless.
My first computer was that 1977 TRS-80 Model I, with the 600 baud cassette tape player. It finally bit the dust around 1990.
That's 500 baud, unless you started with Level I basic, which I think was 250 baud. I still have a lot of tapes from 1979-1981 or so that I need to decode (1979, 14th birthday, Level II 16K). I finally decided to try a few weeks ago, and guess who still sells a cassette tape player? The Shack. CTR-121, fifty bucks. I did some rips with Audacity with beautiful waveforms, but what bits of code I have to decode from WAVs don't work with them.
A few years later I got a CoCo 4K (and immediately upgraded it to 16K) just because I wanted to play with 6809 assembly language. But then I became one of the first "switchers" and went straight to Macintosh in 1985. I had a Fidonet BBS on a PC, and had Linux PCs to do internet stuff, but I've used Mac all the way, even through the crappy days of the early PowerPC era.
A few years ago I imaged all my old TRS-80 floppies with a Catweasel board, with no errors beyond the ones from 20+ years ago. Then I tried to image a bunch of other random disks I'd acquired for other systems, mostly from being a thrift store junkie. Atari 8-bit wasn't too bad, just a speeded up motor and inverted data. Apple II took some work to make a GCR decoder, and I got both 13-sector and 16-sector working. But Commodore's GCR method was crap. It doesn't even have a proper address mark like Apple II does, so it's hard to sync up to the bitstream.
My ultimate goal is to rig up that Catweasel with an 8-inch drive and read a bunch of TRS-80 Model II/16 disks that I have. I have a few old machines with 8" drives under piles of stuff, and I should be able to get at least one of them working.
Back in the day, early '80s, someone at the local TRS-80 user group would buy large quantities of floppy disks so that everyone could take advantage of the better pricing. I get a box, take it home, and try to format it. Instead of the "Click... click... click..." the drive went RAT-A-TAT-A-TAT! They were hard sectored (10, I think), so formatting was stepping eleven times faster than normal.
Anyhow, I imaged all my old disks a few years ago with a Catweasel board. It uses the ultimate formatting method: time between magnetic changes. There were no disk errors other than the ones that were already there 20+ years before.
But how would we sneak in SCADA viruses to break their centrifuges, if not through games downloaded from Steam?
Then go find your own. I've been meaning to find out more about them (had reasons why I couldn't so far) and this got me to click the link and look at their map. And now I know that they're very near where I work. I was expecting them to be on the south side of town or something like that. (going between north and south Austin can take a while even with good traffic, and Austin traffic usually sucks)
They removed the mercury. Autism rates still rose.
This needs repeating, in a post all by itself. And in boldface.
If you change the size of a block of assembly code, you have to adjust pointers throughout that segment and beyond. This is the task of an assembler and linker, working on your source code. For ROM hacking, you don't have the source. It's infeasible--and provably uncomputable in the general case--to know where all these pointers are, so that you can adjust them when you rebuild with hacks in place.
It is possible, but it's a lot of work, and it grows with the size of the code. First you have to start with a disassembler that traces down branches and calls, then you have to keep looking for more code that didn't get traced because it was referenced from a jump table somewhere, and tell the disassembler to search that too.
It also depends on the instruction set of the CPU, and how pointers get represented in memory. In 6502 code, each byte of a data record is often put in separate tables, and jump tables that use PHA/PHA/RTS will use the address - 1 because of the way RTS works.
But in my experience, the hard work is data blocks with pointers to other blocks that contain even more pointers. When the code is in assembly language, a lot more liberties can be taken with data formats than would be done in C code. Sometimes the only way to be sure is to find the code that accesses the tables, and identify which offsets contain addresses under which conditions.
It's one thing to do this to an arcade-style game that's 16K bytes. It's completely different trying to do this to an RPG of a few hundred K bytes. I've done the former, but never had the guts to try the latter.
Instead of a machine with a ghost inside, package contained cardboard sleeve containing black plastic disc with strange grooves on it. Would not buy again.
What icons? I ad-blocked those icons a long time ago. I just now noticed that my cursor doesn't even give me the finger anymore as I scrub over where those icons used to be (it did when they first added that crap). I've also ad-blocked that annoying "sharethis" or whatever it is that web sites include to create a popup with like 20 hipster social crap sharing icons. Ad-block isn't just for ads. (Though you could justifiably call all those icons a form of advertisement.)
Today Joe Biden will announce our plans to land the first man on the Sun.
The best way to filter is to make sure that their screens are easily visible to passers-by. Kind of hard to watch porn when your screen is set up nice and high where everyone can see it.
I'm surprised to see that nobody has mentioned frequency bands yet. It sounds like your phone is a European model. The problem is that different parts of the world use different frequencies for mobile phone service, and now even different technologies, too.
From what I understand, pretty much all of Europe uses the GSM on the same frequency bands, so you can shuffle around SIM cards all day. But in the US, the frequencies are different from Europe. Even more of a problem is that GSM isn't dominant here. And now 3G and 4G are coming.
So sure, you could stick in a SIM card, but can your phone even talk on the right frequencies? If it is a "quad band" phone, you may be in luck.
Actually, no. If you just change 'struct' to 'class', and don't use virtual methods or templates, there is absolutely no bloat vs the same C code.
But to achieve this there is, however, a tradeoff. Which method actually gets used is determined statically at compile time by what you declared it as. If you declare an object pointer CBase* p, and assign a CSubclass* pointer to it, calling p->Foo will always call CBase::Foo and never call CSubclass::Foo. If you can't live with that behavior, then you were probably going to need function pointers anyhow, and for 4 bytes extra per struct you can make as many virtual methods as you want. If you needed more than one, only one vtable is created per class, as opposed to needing 4 bytes per function pointer in every instance of your struct.
When I first used C++ classes, I actually saved memory because it replaced code that had one messy uber-union that covered all kinds of different memory allocations for various sorts of thingies (and therefore enough for the largest was always allocated), and switch statements everywhere. Afterwards, each thingy got exactly the RAM it needed (from a fixed allocation pool managed by the base class, since this was on a SoC with 64K RAM) and the switch statements were replaced with virtual functions for each thingy. The code was significantly more readable, too.
But templates are indeed a mess. They cause code bloat because for every object type you want to use with a template, it generates a completely new function just like the others it created before, with the only changes being for the new type. This is in comparison to the Smalltalk style of Objective C, where you can write a single function to work on (effectively) anonymous objects. And the STL assumes you have a heap, which is often not the case in embedded systems programming. The only template I have used is one I created to handle a fixed length array of flag bits, because it made my code a little easier to read.
I've read their guidelines, and they're doing much like I've been doing recently with moving from C to C++ for embedded systems programming, which is to avoid the really crazy shit that you can do in C++. In particular, exceptions and RTTI are absolutely verboten. They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source. Any templates outside of STL are also forbidden ("template hell" sucks), and I won't even use STL myself because I can't count on having a heap. Even iostreams are being frowned on except maybe possibly in debug dump code where no text language translations are needed.
C++ can really tidy up C code that uses any sort of function pointer hooks or object dispatch style switch statements with virtual methods. A class can become a mini-API, and even used as a sort of device-driver, as in the mbed libraries. Doing this has really helped improve encapsulation in my own code.
You forgot to mention that the lander is MOVING during re-entry, with multiple attitude changes. (For OP, that means it turns around different ways.) Even ignoring the "other side of Mars" problem, it would not only require being able to accurately aim a high-gain antenna, but the antenna would have to be physically mounted where it could point at Earth at all times during descent. AT ALL TIMES. And at that distance you have to use directional antennas, which have to be rather precisely aimed at the other end, which doesn't go well with the kind of vibration you get during descent. It just ain't gonna happen.
The problem isn't getting "a little" bandwidth for streaming video, it's getting ANY significant bandwidth beyond simple telemetry. Even audio wants a few kbits/sec. And if you somehow managed to get a 64x64x16-gray postage stamp video into a low bandwidth, it would be useless at such a small size. Most importantly, it wouldn't tell you anything important. Knowing just the few numbers relating to the vehicle status and position updated every second is much more useful and efficient.
And for what it's worth, the lander took a bunch of high-resolution pictures during descent for a stop-motion video. So far they've only uploaded down-sampled versions of a fraction of them. Eventually they'll get them all, but the point is it took a few days before we even got all of the down-sampled series.
But is that 11 inches or 11 feet?