"it's a lot easier to restart a program than clean up a compromised machine."
That depends on what it is. If it crashes in such a way that the program isn't usable, then OpenBSD simply isn't an option.
Re:This is why I couldn't use OpenBSD exclusively.
on
Heap Protection Mechanism
·
· Score: -1, Troll
"But they don't care, they're not trying to be FreeBSD or a Linux distribution, they're trying to be OpenBSD and a part of that is not letting people's perception of optimum performance get in the way of doing what is right by them."
I know, but they also don't accept "performance" as a valid reason to use something else. They usually respond with "it's worth it", "performance is just fine", etc. If they are going to specialize, they should accept that their specializations will be mutually exclusive with the priorities of others.
"If this looses like 5 or 10 percent of it's performance on my machines I won't mind, it's another layer of protection and I like having it and am fine with the cost, faster hardware isn't that expensive."
But it's not 5-10% is it? It's orders of magnitude for some things. They haven't even fixed the double-halt bug in STABLE that cuts I/O performance in half in some cases.
"If something I run crashes, I will report to the people that wrote it, telling them that I found a problem that was found by OpenBSD's malloc, maybe they'll even devote an old test box to checking for bugs on it."
That's great, unless the software comes from a vendor/project that doesn't care about OpenBSD bugs. To some people it's an OpenBSD bug unless they can reproduce it elsewhere. Sure that's a bad attitude, but people do it anyway. Or better yet, when it's binary-only software from a vendor that doesn't exist anymore.
"If OpenBSD was trying to be a Linux distribution then we'd not have most of the good stuff that makes OpenBSD unique."
I agree. Which is why I'm happy to use the specializations on my firewall where the specializations are helpful, and I'm not going to let it anywhere near my desktop, where they aren't.
They're willing to break things in order to improve security. That's commendable, and I can't see myself using anything else for the firewall, but I simply cannot do without some software and some of it is binary-only. Does it break for me? I don't know, but from what Theo has said breakage isn't uncommon for large applications. I haven't checked because Java is poorly supported for unrelated reasons, and this rules out OpenBSD without me having to validate all my other software.
Also, the OpenBSD crowd is very quick to say that performance should be good enough for most purposes, but that's a copout. They have no idea what any particular person needs to do. The double-halt bug is a good example of how this is an issue. If they don't pay enough attention to performance to catch such a major issue quickly, they aren't going to be catching up to Linux or FreeBSD anytime soon.
"You mean the Data Execute Protection from Microsoft? OpenBSD has had that for a long time already, only they named it w^x."
They also didn't need the per-page execute bit to do it. You need a fairly new machine to get the protection, but my 486 firewall has it. They also have stack protection, which is helpful because even if the heap and stack aren't executable you can overwrite return addresses or pointers to functions, and have them point to existing code that can be tricked into doing something malicious.
"So, you have stars, and they're easy to identify because there's this whole fusion reaction that gives off a lot of radiated energy. Everything that is too small to start the reaction is just in a different category - "not a star"."
White dwarfs and neutron stars don't have fusion...
I don't know if you're an idiot or not but it doesn't look like it from your post.
I think Apple will ultimately cave, but they want to make the labels look as bad as possible before that. Apple's actions to date support that theory, because the longer and more public the battle is the worse the labels will look. Apple can make the labels look bad without actually saying anything that can get them sued.
Towards that end they may be putting up a fight over issues they are ultimately prepared to accept, like variable pricing. I don't think Apple's motives are altruistic (I think they mostly want to rip people off on iPods instead of on music), but if this is a battle for public opinion, an already poorly regarded industry is going up against probably one of the best PR companies there is.
"so the tether mass must be signifigantly higher then the aircraft to prevent a rather problematic deorbit"
"rather problematic deorbit" indeed! I laughed out loud at the way you phrased that.:)
And yes, that assesment is accurate. It has to be massive enough for the slower-moving cargo to not drag it out of orbit.
"So my only real objections are the sheer mass of the tether, and the power requirements."
I've seen a number of solutions proposed to the power problem. Nuclear, power microwaved from the ground (power does not have to be full-time), etc.
If people will accept the JIMO using a full reactor (which it presumeably must to break orbit), a nuclear powered tether could probably be sold as well, provided that no possible tether break could send the reactor back into the atmosphere. A heavy reactor could be a counter-weight on the other end of the tether, and if that end were short enough a break wouldn't de-orbit the thing. Alternatively, the reactor could follow the tether, a few degrees behind in the same orbit, and microwave power to it.
Or, if it makes space-based solar power economical it could be powered from the ground initially, and then from independantly oribtting power satelites later on.
The mass problem is simply one of economics. According to tethers.com, the mass of of the tether would have to be about 5 times that of the cargo it lifts. One assumes that's optimistic, but even so 2-3 times that is not out of the question. Bringing spaceflight within the capability of aircraft with reasonable design tolerances, that can be maintained without too much in the way of special training is the main goal.
I don't see anyone jumping to build one of these and do not assume anyone will, but it's as plausible as hydrogen-powered SSTO being ten times cheaper than existing systems.
"and it's much easier to reach 1km/s than go from 1km/s to 2km/s"
Indeed. Interesting that you consider 2 km/s impractical because it's so much harder than 1 km/s, but you neglect to mention that 7.73 km/s at 300 km is harder than 2 km/s at 100 km. Both SpaceShipOne and the X-15 were tiny aircraft, and if we're talking about a space plane designed to carry cargo, a larger craft with larger fuel tanks is a reasonable assumption to make. It's still orders of magnitude easier to do than existing space craft because the sheer volume of fuel necessary is so much less. That doesn't mean it's necessarily easy, just easier.
"it's coming from the tether, which means that you're dealing with 100's of Gs - the relative velocity can only be 0 if you're going 7.73km/s, orbit isn't so much a question of height, as speed. If you're going too slow for a given height, you'll deorbit."
I'll say it again.
If the tether is rotating, then the end farther out into space is traveling faster than the orbital velocity and the end closer to the Earth is traveling less than orbital velocity. If it is traveling sufficiently less than orbital velocity, a much slower space plane can rendevous with it and the relative velocity of the tip will be, for an instant, 0. The structure as a whole has to be moving fast enough to stay in orbit, but parts of it can move slower for long enough to pick things up.
"If you disagree with these conculsions, please supply your own calculations and not just meaningless words."
Okay..
First, there's no reason to assume the top speed of the lift aircraft will be 1 km/s. There hasn't been much need for an aircraft that can do a short sub-orbital hop so the top speeds of atmospheric craft are not representitive of speeds that are acheivable with current technology. SpaceShipOne did 1 km/s on a shoestring and several times that is readily acheivable with current technology.
Second, the speed of the tether tip can be a lot less than the speed of the structure as a whole. If the structure is rotating with the lower end traveling counter to the direction of the orbit, the speed of the craft at rendevous can be cut down substantially (up to about 4 km/s with current materials).
The relative velocity at the rendevous can be 0. See tethers.com for more information.
"for obvious reasons, nuclear is not a viable option"
"Thus a elevator coudl take loads up but your design would be dragged down over time or imidiately dependign on the size of the satalite at the end."
But it can use high-efficiency engines such as nuclear or solar powered ion engines to re-boost itself. In principal, a more conventional launch system could have an ion second stage, but that would be much slower and less efficient because it would have to be small enough to be launched into free-fall. It would take less time to recover the same amount of momentum.
"So then you have to get something up to orbital speed to catch up to it. Since you only have to get something up to orbital speed in order to have it reach orbit, you're not going to be saving a lot."
But its center of gravity can be pretty high, so its orbital speed can be significantly lower than it otherwise would be at that altitude (say 100 km). It can also be rotating about its center of gravity, and if the bottom end is traveling counter to its direction the relative velocity between the bottom end and the ground can be lowered to a level readily achievable with current technology.
"Then, after a week of atmospheric drag, it falls to the ground."
Only if the bottom end is in the atmosphere. Getting above the atmosphere is a lot easier than getting above the atmosphere at orbital speeds.
Slashdot Mirror
Ah, sorry. Didn't make the errata page.
"it's a lot easier to restart a program than clean up a compromised machine."
That depends on what it is. If it crashes in such a way that the program isn't usable, then OpenBSD simply isn't an option.
"But they don't care, they're not trying to be FreeBSD or a Linux distribution, they're trying to be OpenBSD and a part of that is not letting people's perception of optimum performance get in the way of doing what is right by them."
I know, but they also don't accept "performance" as a valid reason to use something else. They usually respond with "it's worth it", "performance is just fine", etc. If they are going to specialize, they should accept that their specializations will be mutually exclusive with the priorities of others.
"If this looses like 5 or 10 percent of it's performance on my machines I won't mind, it's another layer of protection and I like having it and am fine with the cost, faster hardware isn't that expensive."
But it's not 5-10% is it? It's orders of magnitude for some things. They haven't even fixed the double-halt bug in STABLE that cuts I/O performance in half in some cases.
"If something I run crashes, I will report to the people that wrote it, telling them that I found a problem that was found by OpenBSD's malloc, maybe they'll even devote an old test box to checking for bugs on it."
That's great, unless the software comes from a vendor/project that doesn't care about OpenBSD bugs. To some people it's an OpenBSD bug unless they can reproduce it elsewhere. Sure that's a bad attitude, but people do it anyway. Or better yet, when it's binary-only software from a vendor that doesn't exist anymore.
"If OpenBSD was trying to be a Linux distribution then we'd not have most of the good stuff that makes OpenBSD unique."
I agree. Which is why I'm happy to use the specializations on my firewall where the specializations are helpful, and I'm not going to let it anywhere near my desktop, where they aren't.
They're willing to break things in order to improve security. That's commendable, and I can't see myself using anything else for the firewall, but I simply cannot do without some software and some of it is binary-only. Does it break for me? I don't know, but from what Theo has said breakage isn't uncommon for large applications. I haven't checked because Java is poorly supported for unrelated reasons, and this rules out OpenBSD without me having to validate all my other software.
Also, the OpenBSD crowd is very quick to say that performance should be good enough for most purposes, but that's a copout. They have no idea what any particular person needs to do. The double-halt bug is a good example of how this is an issue. If they don't pay enough attention to performance to catch such a major issue quickly, they aren't going to be catching up to Linux or FreeBSD anytime soon.
"You mean the Data Execute Protection from Microsoft? OpenBSD has had that for a long time already, only they named it w^x."
They also didn't need the per-page execute bit to do it. You need a fairly new machine to get the protection, but my 486 firewall has it. They also have stack protection, which is helpful because even if the heap and stack aren't executable you can overwrite return addresses or pointers to functions, and have them point to existing code that can be tricked into doing something malicious.
He doesn't like being photographed, and and people who do things he doesn't like generally don't do them again.
"So, you have stars, and they're easy to identify because there's this whole fusion reaction that gives off a lot of radiated energy. Everything that is too small to start the reaction is just in a different category - "not a star"."
White dwarfs and neutron stars don't have fusion...
"Talking of making the labels look bad, I don't see how this *isn't* a blatant attempt at illegal price fixing."
Business as usual.
I don't know if you're an idiot or not but it doesn't look like it from your post.
I think Apple will ultimately cave, but they want to make the labels look as bad as possible before that. Apple's actions to date support that theory, because the longer and more public the battle is the worse the labels will look. Apple can make the labels look bad without actually saying anything that can get them sued.
Towards that end they may be putting up a fight over issues they are ultimately prepared to accept, like variable pricing. I don't think Apple's motives are altruistic (I think they mostly want to rip people off on iPods instead of on music), but if this is a battle for public opinion, an already poorly regarded industry is going up against probably one of the best PR companies there is.
"Or is the idea that I should have learned a real job like carpenting, and program just for fun..."
In Alberta these days, a good welder can make an obscene amount of money.
Relicensing as BSD would be problematic in many cases because you'd have to get all contributors to sign off.
Websites like Google use customized GPL software internally. They'll just ignore GPL3'd code and hang onto what they already use.
I'm suddenly glad my shuffle doesn't have a screen.
"Interestingly, OpenSSH's market share is something like 76% of all SSH servers."
Isn't it 90+, not counting re-branded OpenSSH versions?
I'm on 2.6 for the responsiveness, but it's really buggy. Don't use it yet if you can avoid it.
"so the tether mass must be signifigantly higher then the aircraft to prevent a rather problematic deorbit"
:)
"rather problematic deorbit" indeed! I laughed out loud at the way you phrased that.
And yes, that assesment is accurate. It has to be massive enough for the slower-moving cargo to not drag it out of orbit.
"So my only real objections are the sheer mass of the tether, and the power requirements."
I've seen a number of solutions proposed to the power problem. Nuclear, power microwaved from the ground (power does not have to be full-time), etc.
If people will accept the JIMO using a full reactor (which it presumeably must to break orbit), a nuclear powered tether could probably be sold as well, provided that no possible tether break could send the reactor back into the atmosphere. A heavy reactor could be a counter-weight on the other end of the tether, and if that end were short enough a break wouldn't de-orbit the thing. Alternatively, the reactor could follow the tether, a few degrees behind in the same orbit, and microwave power to it.
Or, if it makes space-based solar power economical it could be powered from the ground initially, and then from independantly oribtting power satelites later on.
The mass problem is simply one of economics. According to tethers.com, the mass of of the tether would have to be about 5 times that of the cargo it lifts. One assumes that's optimistic, but even so 2-3 times that is not out of the question. Bringing spaceflight within the capability of aircraft with reasonable design tolerances, that can be maintained without too much in the way of special training is the main goal.
I don't see anyone jumping to build one of these and do not assume anyone will, but it's as plausible as hydrogen-powered SSTO being ten times cheaper than existing systems.
"and it's much easier to reach 1km/s than go from 1km/s to 2km/s"
Indeed. Interesting that you consider 2 km/s impractical because it's so much harder than 1 km/s, but you neglect to mention that 7.73 km/s at 300 km is harder than 2 km/s at 100 km. Both SpaceShipOne and the X-15 were tiny aircraft, and if we're talking about a space plane designed to carry cargo, a larger craft with larger fuel tanks is a reasonable assumption to make. It's still orders of magnitude easier to do than existing space craft because the sheer volume of fuel necessary is so much less. That doesn't mean it's necessarily easy, just easier.
"it's coming from the tether, which means that you're dealing with 100's of Gs - the relative velocity can only be 0 if you're going 7.73km/s, orbit isn't so much a question of height, as speed. If you're going too slow for a given height, you'll deorbit."
I'll say it again.
If the tether is rotating, then the end farther out into space is traveling faster than the orbital velocity and the end closer to the Earth is traveling less than orbital velocity. If it is traveling sufficiently less than orbital velocity, a much slower space plane can rendevous with it and the relative velocity of the tip will be, for an instant, 0. The structure as a whole has to be moving fast enough to stay in orbit, but parts of it can move slower for long enough to pick things up.
"I am still pretty new to linux and one thing I have to say, Konqueror is awesome." ... you're not even using Linux.
This whole article makes my brain weep bitter tears.
"If you disagree with these conculsions, please supply your own calculations and not just meaningless words."
Okay..
First, there's no reason to assume the top speed of the lift aircraft will be 1 km/s. There hasn't been much need for an aircraft that can do a short sub-orbital hop so the top speeds of atmospheric craft are not representitive of speeds that are acheivable with current technology. SpaceShipOne did 1 km/s on a shoestring and several times that is readily acheivable with current technology.
Second, the speed of the tether tip can be a lot less than the speed of the structure as a whole. If the structure is rotating with the lower end traveling counter to the direction of the orbit, the speed of the craft at rendevous can be cut down substantially (up to about 4 km/s with current materials).
The relative velocity at the rendevous can be 0. See tethers.com for more information.
"for obvious reasons, nuclear is not a viable option"
Tell that to the Jupiter Icy Moons Orbiter.
If Everest were on the equator.
"You've got a probably millisecond window of opportunity"
This is a challenge, but missiles today can hit smaller targets that don't want to be hit.
"not to mention the G forces when it gets picked up would require massive dampening."
That is entirely depedant on if/how fast it's spinning. As long as it's 1 G or less, you're fine.
"And you would still need expensive rocket refuelled to keep the thing turning."
It would use higher efficiency engines (eg ion engines) because it's acceptable for it to take a relatively long time to recover.
Other people did the thinking. I read what they wrote. :)
"Thus a elevator coudl take loads up but your design would be dragged down over time or imidiately dependign on the size of the satalite at the end."
But it can use high-efficiency engines such as nuclear or solar powered ion engines to re-boost itself. In principal, a more conventional launch system could have an ion second stage, but that would be much slower and less efficient because it would have to be small enough to be launched into free-fall. It would take less time to recover the same amount of momentum.
"So then you have to get something up to orbital speed to catch up to it. Since you only have to get something up to orbital speed in order to have it reach orbit, you're not going to be saving a lot."
But its center of gravity can be pretty high, so its orbital speed can be significantly lower than it otherwise would be at that altitude (say 100 km). It can also be rotating about its center of gravity, and if the bottom end is traveling counter to its direction the relative velocity between the bottom end and the ground can be lowered to a level readily achievable with current technology.
"Then, after a week of atmospheric drag, it falls to the ground."
Only if the bottom end is in the atmosphere. Getting above the atmosphere is a lot easier than getting above the atmosphere at orbital speeds.
That's correct, I was giving a minimum.