In some old (probably in the 7.x era) versions of Mac OS, there was a map control panel (I think it was for setting your time zone), that would let you look up locations by name. The zero-zero coordinates had a name of "Middle of Nowhere".
Old Space = "cost plus" contracts - Whoops, we've gone over the budget, but keep paying us until we're done!
New Space = fixed-price contracts - Whoops, our rocket went RUD from a bad strut, now we have to launch another one without you giving us more money! *
(Yes, I know they lost some expensive cargo, even if they had enabled the Dragon capsule to pop its chute. The final resolution was to add four new launch missions at a discounted price.)
// double-slash comments are the one and only improvement that c++ gave us
Why won't people accept the existence of C99 over 15 years later? (Microsoft has to be the worst offender about this, they refuse to support it in VS.)
If you want to talk about Luddites, the anti-C99 Luddites are worse than the anti-C++ ones.
Having played with ATtiny's quite a bit, I know from experience that high level coding uses a lot more memory. Even simple stuff like turning pins on and off is much leaner with direct port calls. And anything involving accurate timing is almost impossible without going low-level due to clock cycle overheads.
You still don't necessarily need assembly language for that. While many platforms may helpfully give you some kind of GPIO library that won't let you toggle pins at more than 100KHz or so, just declaring the raw GPIO registers as volatile pointers is likely to get you the same kind of space and speed improvements as raw assembly, at the cost of your code being more closely tied to a limited number of SoC architectures.
Which you can deal with if you need to by abstracting for architecture at the next level up, writing an optimized version for each architecture you need to support, along with possibly a generic C version for reference. It's still going to be more portable for future architectures than straight assembly language, which will be important if you plan to sell your product for more than a few years. Old CPUs cost a lot more than newer ones, and give you a lot less. And that's even when you don't count the costs of old obsoleted chips going out of supply, or a change like 5 volt logic going away.
You don't have dev units with the larger flash size variants of the CPU just so you can debug? It's one thing to care about millions of units, but when you're crippling your developers by forcing them to use a chip that the code barely fits in, that's just silly. (Yes, I know you want to be sure it works on the real product, that's why you still need to test on the real thing before release. That's no excuse for not having debug prototypes with more code space.)
That sounds great until you have to take that six-year old product that was done in PIC assembly (Which PIC? You mean there's more than one?) and make a new product based on what it did. Now you have to decode the algorithm out of the assembler code. (Sorry, you can't ask the old guy, he left three years ago. He wouldn't understand his old code anyhow.)
Not that C would have been much better on PIC, which is a horrible architecture for it, but at least you could have a chance to see the algorithm, not a hundred assorted register moves and branches with little indication of program flow structure. Fortunately, microcontrollers have been moving toward architectures designed for high-level languages. PIC and 8051 are basically the only old-school 8-bit assembly still being used, and 8051 isn't compiler-hostile like PIC. (code bank switching is bad, mmmkay?)
There are very few cases where you really need to care how many cycles an instruction takes (and now you can't even be sure anymore!), and very few cases where a modern one-dollar CPU isn't already a hundred times faster than you need. There is no need to optimize code for speed when it is executed once per second, or to optimize for space when you can usually double your flash size for a few pennies more. Hand-optimization effort is wasted on anything less than tight inner loops for time-critical stuff.
Indeed, the only real reason to do LEO refueling is for missions beyond GEO (moon, L4/L5, asteroids, Mars), where you can't just use a bigger dumb booster. GEO requires a really big rocket for a really big satellite, but still well within the capability of current and upcoming heavy launchers. You could potentially refuel existing satellites to give them more station-keeping lifetime, but they won't exactly have a standard fueling port, arbitrarily changing orbits is hard and can use as much fuel as launch (try changing an orbit from equatorial to polar in Kerbal if you want to know how much), and you still can't fix a failed reaction wheel by refueling.
Really, the only reason to need so much fuel would be to move humans around in space. (Life support adds a lot of mass!) So I guess the refueling could support... more refueling workers?
That's nice, except for the little problem that it's not the production of the fuel that is expensive, it's lifting the mass from Earth. Fuel doesn't magically appear from nothing, and you don't make the mass of fuel spontaneously appear during production, so the raw materials still take roughly the same amount of fuel to launch them fromearth. Where hare the raw materials coming from, if not from earth?
It's not like there are a lot of hydrocarbons on the moon or asteroids, and certainly not the noble gasses like argon that we typically use for reaction mass in ion engines. And even if there were sufficient raw materials found on the moon, it's still a gravity well, just a lot shallower one. Not that we would know about raw materials for fuel, other than some rocks we brought back around 1970 (mostly basalt and some nasty sharp dust), and some unknown quantity of ice that we think we can see reflecting from inside craters at the poles. And some helium-3 that we won't even be able to start using for at least fifty years, which could probably be made just as cheaply on earth anyhow.
Some might also wonder about who will use this magically-produced fuel once it is in orbit. but at least I don't think that would be a problem. Just as how improved launch vehicles and soon engine launch recovery are bringing down the cost of launches, making entire new categories of missions possible, cheaper refueling will help too. Maybe one day we'll even de-orbit and land a vehicle entirely by retro-thrust, instead of using atmospheric braking, if there's a benefit from using extra fuel to do so.
But ULA, huh? As in the ones who say "Us too!" about launch engine recovery, but haven't yet made any actual attempts to do so? Talk is cheap, guys, let's see you do something new for once, instead of the same decades-old rocket designs.
The truck wasn't crossing a "street", it was making a left turn across a divided highway at a grade crossing intersection in the middle of nowhere, with no signal light. That's highway as in full speed oncoming traffic, and also as in left turning traffic has to yield right of way. How was the Tesla impossible for the truck driver to see? The truck driver didn't have right of way and should have waited for a gap in traffic before turning.
Meanwhile, this big thing suddenly crosses the path of the Tesla driving at highway speeds. Even if it had seen it, what are the chances that there would still have been an accident anyhow? Sure, it might have been able to slow down enough to "only" hit the rear end of the truck and not get capped, but that's a rather complicated sequence for mere silicon to comprehend.
In the US, trucks are required to have a Mansfield Bar in the rear, due to a high-profile traffic accident back in the 1960s. But the only things that are sometimes under the sides of a semi trailer are fairings to reduce air resistance.
Except that's not how Right of Way works. You don't get to assume that the other guy will see you and avoid you when you don't have right of way. If there is conflicting traffic, you're supposed to stop and wait for it to go by. Especially when crossing a a highway when you're not even at a signaled intersection. Just from the description of the accident and seeing the intersection, I find it hard to justify not being the truck driver's fault.
How much do you drive anyhow, and in what country? If you have a driver's license in the US, you should be expected to know and understand this.
So it was an un-signaled intersection, at a typical grade crossing of a rural 4-lane US highway divided with a grass median. This meant that the truck apparently crossed when it was not safe to do so. I don't see any report of the weather or time of day, but the road is quite straight and relatively flat, so the truck driver should have seen the Tesla coming. If the autopilot had been able to see the situation and react, that would have only been a bonus.
If there's one thing that makes autonomous driving hard, it's that other people are dumb and will do dumb things, some of which endanger YOUR life. No matter how much you try to idiot-proof things, the universe will always create a bigger idiot.
Many years ago I worked at a major networking hardware manufacturer (one who should know their stuff, but somehow let this happen). This was maybe '04 or '05 or so. Seems they had installed some kind of security camera system that ran on a Windows platform. Like one per camera or maybe one per four cameras or something. And because it's all wrapped up as a product, you can't just stick McAfee on it. Yes, I know, what the ever loving fuck. They were deployed all over the company. Hooked up via gigabit Ethernet to the internal backbone. Along comes the latest Windows worm, and the cameras not only catch it, they blow out the entire company's network spewing packets all over the place as the worm tries to spread. It was bad enough to cause significant packet loss to the internet.
I also remember that from time to time some SMB worm thing would hit a printer when trying to spread, and those brillant HP printers would happily spew a new page ever time they saw an 0x0C. We actually had to replace one printer in my area because this broke it. (Extra large paper tray, of course.)
If most cancers happen past reproductive age, why is there any need to "prevent" the spread of genes that won't be spread anyhow? And most forms of cancer are due to random mutations in individual cells, which won't change the genes in sperm/eggs. The few cancers that are due to genetic susceptibility (such as some forms of breast cancer) still get passed on anyhow. The hypothesis is so easily refuted that it isn't even funny.
What GP post says should be obvious. We get cancer specifically because there is no evolutionary pressure after reproduction for us to not get it.
I'm going to guess that this uses Apple's "double float" version of the Unix timestamp. Basically, if you're going to use a 64-bit integer to avoid the Y2038 problem, you'll end up with a lot of useless bits. If you convert the same numbers to 64-bit double float, those extra bits become nanosecond resolution (or probably better than your hardware can measure). If for some reason you want to deal with timestamps a few billion years in the past or future, then you can afford to deal with mere seconds-level accuracy. Beyond that, you may have to deal with accuracy of minutes or hours, but what's a few seconds compared to the life of the universe?
Some form of compressed file support is already in HFS+. I only know this from trying to use "cp -a" to recover data from dying hard drives, and seeing parameter error messages. I eventually realized that cp was trying to copy the extended attribute that says a file is compressed, and when trying to set it on the destination, the file system was saying "oh no you don't!" I only saw this on files that were placed there by the OS installers/updaters.
We need a pulp SF story where a lazy astronaut just jizzes on the plants, and in the end they all get eaten by plant people, who successfully reproduce and take over Mars.
Even if they did have the right vehicles to return to Earth, the orbital mechanics of Earth/Mars transfer are a bitch. If you take the six-month trajectory to Mars, once you get there you have to wait a year for the six-month trajectory back to Earth. If you just wanted to do a touch-and-go mission, the return time is eighteen months. Either way, you're not getting back to Earth less than two years from first launch without some kind of constant thrust rockets to make you go faster, and maybe not even with them.
In the US back in the late '90s when I was working with related stuff (automated pay systems for gas pumps), not only was the PIN not on the card, but debit terminals had to encrypt the PIN in the keypad. The keypad had an encryption key (and sometimes all its firmware too) injected into RAM by the bank or clearinghouse or whoever, and was potted to prevent tampering. If its battery ran out, too bad, get a new keypad.
Apparently in those days, Europe must not have encrypted the PIN like that, because that was when PIN stealing was rampant over there.
Slashdot Mirror
In some old (probably in the 7.x era) versions of Mac OS, there was a map control panel (I think it was for setting your time zone), that would let you look up locations by name. The zero-zero coordinates had a name of "Middle of Nowhere".
The difference is:
Old Space = "cost plus" contracts - Whoops, we've gone over the budget, but keep paying us until we're done!
New Space = fixed-price contracts - Whoops, our rocket went RUD from a bad strut, now we have to launch another one without you giving us more money! *
(Yes, I know they lost some expensive cargo, even if they had enabled the Dragon capsule to pop its chute. The final resolution was to add four new launch missions at a discounted price.)
Exactly. I was expecting a rant about people not putting periods at the end of complete sentences in comments.
He predicted the dominance of widescreen monitors years before they became popular, with his insistence that tabs be 8 characters wide.
But lines are still limited to 80 characters?
I code and write on OS X, would it kill you penguin lovers to respect case-insensitive filesystems?
// double-slash comments are the one and only improvement that c++ gave us
Why won't people accept the existence of C99 over 15 years later? (Microsoft has to be the worst offender about this, they refuse to support it in VS.)
If you want to talk about Luddites, the anti-C99 Luddites are worse than the anti-C++ ones.
Having played with ATtiny's quite a bit, I know from experience that high level coding uses a lot more memory. Even simple stuff like turning pins on and off is much leaner with direct port calls. And anything involving accurate timing is almost impossible without going low-level due to clock cycle overheads.
You still don't necessarily need assembly language for that. While many platforms may helpfully give you some kind of GPIO library that won't let you toggle pins at more than 100KHz or so, just declaring the raw GPIO registers as volatile pointers is likely to get you the same kind of space and speed improvements as raw assembly, at the cost of your code being more closely tied to a limited number of SoC architectures.
Which you can deal with if you need to by abstracting for architecture at the next level up, writing an optimized version for each architecture you need to support, along with possibly a generic C version for reference. It's still going to be more portable for future architectures than straight assembly language, which will be important if you plan to sell your product for more than a few years. Old CPUs cost a lot more than newer ones, and give you a lot less. And that's even when you don't count the costs of old obsoleted chips going out of supply, or a change like 5 volt logic going away.
You don't have dev units with the larger flash size variants of the CPU just so you can debug? It's one thing to care about millions of units, but when you're crippling your developers by forcing them to use a chip that the code barely fits in, that's just silly. (Yes, I know you want to be sure it works on the real product, that's why you still need to test on the real thing before release. That's no excuse for not having debug prototypes with more code space.)
That sounds great until you have to take that six-year old product that was done in PIC assembly (Which PIC? You mean there's more than one?) and make a new product based on what it did. Now you have to decode the algorithm out of the assembler code. (Sorry, you can't ask the old guy, he left three years ago. He wouldn't understand his old code anyhow.)
Not that C would have been much better on PIC, which is a horrible architecture for it, but at least you could have a chance to see the algorithm, not a hundred assorted register moves and branches with little indication of program flow structure. Fortunately, microcontrollers have been moving toward architectures designed for high-level languages. PIC and 8051 are basically the only old-school 8-bit assembly still being used, and 8051 isn't compiler-hostile like PIC. (code bank switching is bad, mmmkay?)
There are very few cases where you really need to care how many cycles an instruction takes (and now you can't even be sure anymore!), and very few cases where a modern one-dollar CPU isn't already a hundred times faster than you need. There is no need to optimize code for speed when it is executed once per second, or to optimize for space when you can usually double your flash size for a few pennies more. Hand-optimization effort is wasted on anything less than tight inner loops for time-critical stuff.
Hasn't there been some kind of mold found on the outside of space station windows? Maybe ISS, maybe Mir?
Not to mention that, while a lot shallower, the moon is still a gravity well. Icy asteroids might be a much better source.
Indeed, the only real reason to do LEO refueling is for missions beyond GEO (moon, L4/L5, asteroids, Mars), where you can't just use a bigger dumb booster. GEO requires a really big rocket for a really big satellite, but still well within the capability of current and upcoming heavy launchers. You could potentially refuel existing satellites to give them more station-keeping lifetime, but they won't exactly have a standard fueling port, arbitrarily changing orbits is hard and can use as much fuel as launch (try changing an orbit from equatorial to polar in Kerbal if you want to know how much), and you still can't fix a failed reaction wheel by refueling.
Really, the only reason to need so much fuel would be to move humans around in space. (Life support adds a lot of mass!) So I guess the refueling could support... more refueling workers?
That's nice, except for the little problem that it's not the production of the fuel that is expensive, it's lifting the mass from Earth. Fuel doesn't magically appear from nothing, and you don't make the mass of fuel spontaneously appear during production, so the raw materials still take roughly the same amount of fuel to launch them fromearth. Where hare the raw materials coming from, if not from earth?
It's not like there are a lot of hydrocarbons on the moon or asteroids, and certainly not the noble gasses like argon that we typically use for reaction mass in ion engines. And even if there were sufficient raw materials found on the moon, it's still a gravity well, just a lot shallower one. Not that we would know about raw materials for fuel, other than some rocks we brought back around 1970 (mostly basalt and some nasty sharp dust), and some unknown quantity of ice that we think we can see reflecting from inside craters at the poles. And some helium-3 that we won't even be able to start using for at least fifty years, which could probably be made just as cheaply on earth anyhow.
Some might also wonder about who will use this magically-produced fuel once it is in orbit. but at least I don't think that would be a problem. Just as how improved launch vehicles and soon engine launch recovery are bringing down the cost of launches, making entire new categories of missions possible, cheaper refueling will help too. Maybe one day we'll even de-orbit and land a vehicle entirely by retro-thrust, instead of using atmospheric braking, if there's a benefit from using extra fuel to do so.
But ULA, huh? As in the ones who say "Us too!" about launch engine recovery, but haven't yet made any actual attempts to do so? Talk is cheap, guys, let's see you do something new for once, instead of the same decades-old rocket designs.
Except he didn't "get into" the situation. The truck made a left turn across rural highway traffic.
The truck wasn't crossing a "street", it was making a left turn across a divided highway at a grade crossing intersection in the middle of nowhere, with no signal light. That's highway as in full speed oncoming traffic, and also as in left turning traffic has to yield right of way. How was the Tesla impossible for the truck driver to see? The truck driver didn't have right of way and should have waited for a gap in traffic before turning.
Meanwhile, this big thing suddenly crosses the path of the Tesla driving at highway speeds. Even if it had seen it, what are the chances that there would still have been an accident anyhow? Sure, it might have been able to slow down enough to "only" hit the rear end of the truck and not get capped, but that's a rather complicated sequence for mere silicon to comprehend.
In the US, trucks are required to have a Mansfield Bar in the rear, due to a high-profile traffic accident back in the 1960s. But the only things that are sometimes under the sides of a semi trailer are fairings to reduce air resistance.
Except that's not how Right of Way works. You don't get to assume that the other guy will see you and avoid you when you don't have right of way. If there is conflicting traffic, you're supposed to stop and wait for it to go by. Especially when crossing a a highway when you're not even at a signaled intersection. Just from the description of the accident and seeing the intersection, I find it hard to justify not being the truck driver's fault.
How much do you drive anyhow, and in what country? If you have a driver's license in the US, you should be expected to know and understand this.
According to the diagram of the crash (In this WaPo article linked from another reply in this thread) it looks like the truck was making a left turn onto a side street, across the path of the Tesla coming from the other direction. The accident seems to have occurred here at US27A and NE 140 Ct.
So it was an un-signaled intersection, at a typical grade crossing of a rural 4-lane US highway divided with a grass median. This meant that the truck apparently crossed when it was not safe to do so. I don't see any report of the weather or time of day, but the road is quite straight and relatively flat, so the truck driver should have seen the Tesla coming. If the autopilot had been able to see the situation and react, that would have only been a bonus.
If there's one thing that makes autonomous driving hard, it's that other people are dumb and will do dumb things, some of which endanger YOUR life. No matter how much you try to idiot-proof things, the universe will always create a bigger idiot.
Many years ago I worked at a major networking hardware manufacturer (one who should know their stuff, but somehow let this happen). This was maybe '04 or '05 or so. Seems they had installed some kind of security camera system that ran on a Windows platform. Like one per camera or maybe one per four cameras or something. And because it's all wrapped up as a product, you can't just stick McAfee on it. Yes, I know, what the ever loving fuck. They were deployed all over the company. Hooked up via gigabit Ethernet to the internal backbone. Along comes the latest Windows worm, and the cameras not only catch it, they blow out the entire company's network spewing packets all over the place as the worm tries to spread. It was bad enough to cause significant packet loss to the internet.
I also remember that from time to time some SMB worm thing would hit a printer when trying to spread, and those brillant HP printers would happily spew a new page ever time they saw an 0x0C. We actually had to replace one printer in my area because this broke it. (Extra large paper tray, of course.)
If most cancers happen past reproductive age, why is there any need to "prevent" the spread of genes that won't be spread anyhow? And most forms of cancer are due to random mutations in individual cells, which won't change the genes in sperm/eggs. The few cancers that are due to genetic susceptibility (such as some forms of breast cancer) still get passed on anyhow. The hypothesis is so easily refuted that it isn't even funny.
What GP post says should be obvious. We get cancer specifically because there is no evolutionary pressure after reproduction for us to not get it.
I'm going to guess that this uses Apple's "double float" version of the Unix timestamp. Basically, if you're going to use a 64-bit integer to avoid the Y2038 problem, you'll end up with a lot of useless bits. If you convert the same numbers to 64-bit double float, those extra bits become nanosecond resolution (or probably better than your hardware can measure). If for some reason you want to deal with timestamps a few billion years in the past or future, then you can afford to deal with mere seconds-level accuracy. Beyond that, you may have to deal with accuracy of minutes or hours, but what's a few seconds compared to the life of the universe?
Some form of compressed file support is already in HFS+. I only know this from trying to use "cp -a" to recover data from dying hard drives, and seeing parameter error messages. I eventually realized that cp was trying to copy the extended attribute that says a file is compressed, and when trying to set it on the destination, the file system was saying "oh no you don't!" I only saw this on files that were placed there by the OS installers/updaters.
We need a pulp SF story where a lazy astronaut just jizzes on the plants, and in the end they all get eaten by plant people, who successfully reproduce and take over Mars.
Even if they did have the right vehicles to return to Earth, the orbital mechanics of Earth/Mars transfer are a bitch. If you take the six-month trajectory to Mars, once you get there you have to wait a year for the six-month trajectory back to Earth. If you just wanted to do a touch-and-go mission, the return time is eighteen months. Either way, you're not getting back to Earth less than two years from first launch without some kind of constant thrust rockets to make you go faster, and maybe not even with them.
In the US back in the late '90s when I was working with related stuff (automated pay systems for gas pumps), not only was the PIN not on the card, but debit terminals had to encrypt the PIN in the keypad. The keypad had an encryption key (and sometimes all its firmware too) injected into RAM by the bank or clearinghouse or whoever, and was potted to prevent tampering. If its battery ran out, too bad, get a new keypad.
Apparently in those days, Europe must not have encrypted the PIN like that, because that was when PIN stealing was rampant over there.