Hmm, yeah, a major way of knowing you've hit real SF is that it doesn't end with "...the status quo ante was repaired, and everyone lived normally ever after" (I exclude from this the predictable lame-ass sequel hook with which hollywood routinely pollutes its products). It seems there's not much of a USA market for anything but affirmation of stasis. That's one reason why I like Japanese (animated) movies. They seem more willing to wreak change upon characters and settings in non-reversible ways.
BTW, that's also one reason "fantasy" settings annoy me. They need constant deus-ex maintainance to hang onto the status quo. As Pterry has proved, you let a fantasy setting run unhampered, and it will unravel into steampunk within a generation.
The problem is it's coded with the creaky, ancient widget library "motif". I cannot speak for its internals, but motif is older than linux, it's pure C, until fairly recently was commercial closed-source, and I've never seen a motif program that wasn't brittle and flaky. Not to mention unaesthetic, user hostile, non-integrated, and prone to ignoring the scroll wheel. None of which is acceptable anymore, not after using modern apps.
"we would probablly lack any auto immune response to be able to combat them."
It's easy enough to speculate on a vice versa: our modern earth bacteria are tough customers, honed by millennia of unending counter-immune war. Wimpy mars bacteria would cower in their meteorite, like preschoolers dumped in a rough biker bar.
Repetitive CPU-bound work is a strength of JIT compilation. Java should do fine.
You want speed out an RDBMS, the deciding factors are likely to be, in decreasing order of importance: good algorithms, well-designed tables and indexes, fast disk IO, abundant RAM.
I can summarize a working minimum of what you need to know about building in cob in one post. That's ridiculously easy compared to brick-and-wood housing!
FYI, here goes:
- Clay, sand, staw. Clay binds, sand prevents shrinking, staw acts as rebar. Use subsoil from the site, tread in the straw. Measure your subsoil by shaking it in water and letting it settle in layers, to see if you need to add clay or sand. Make up test bricks to see if you got the mix right for shrinkage, cracking, and strength. You'll need a higher percentage of sand than you expect. Sieve out rocks and gravel to avoid introducing weak spots.
- Apply it wet enough to squish, neither runny nor hard. Build upwards iteratively, stopping each course just before it starts to sag under its own weight. Measure the plumb with a spirit level and cut off soft cob to keep it from bulging or sagging. Walls can be straight or tapered, which is stronger and saves time/effort building the upper parts. Test taper by gluing a precisely angled bit of wood onto a spirit level. Tapered outside and plumb inside makes furniture an easier fit.
- Overengineer the thickness of the walls. Theoretically, precisely mixed cob applied with skill can be used in walls a foot thick, but build them two feet thick (or more) at the base.
- You need a stem wall, which is a short (waist height) hard and nonporous wall upon which to sit the cob. Stone, concrete or brick are good. This keeps the dried mud above damp ground and rain-runoff splatter. Make the top jagged so the cob sticks. You can skip this, but your house will have a limited "shelf life". Also, the roof needs to overhang enough to throw rain clear of the walls, and you need good drainage and a site which won't flood. In general, water flowing over cob will erode it, but rain won't.
- Cob functions as "thermal mass", bringing inside temperature towards the daily mean temperature (ie: it smooths out cold and heat into continuing warmth). It doesn't insulate much. Avoid using it where you get no sun (north slope) or where the climate is cold all day. Plan the house as a passive solar collector, with windows sited to admit and trap morning and evening sun.
- Joint the cob to woodwork, especially upstairs-floor beams and roof rafters, by burying anchor points of jaggedy wood into the cob wall. Logs stripped of bark with branch-stubs sticking out are good. Don't bury rafters and beams directly into the cob, because they can shift and tear loose due to settlement and heat-expansion. Non-opening window panes can simply be buried straight into walls, with expansion foam around the edges to prevent them being crushed.
- You can build furniture straight from the cob by cantilevering outwards (go slowly) or by carving in. Tamped cob can also be used to make floors - seal the final layer with boiled linseed oil.
- Never put nonporous materials over cob, especially outside. That includes oil based paints, cement based interior and exterior plasters. Cement exterior plaster is a major cause of cob wall collapse. Water runs in through cracks, down the inside and liquefies the wall base. Instead, use mud-straw plaster or lime-sand plaster. Whitewash and casein paints can be used inside and out.
There you go, that's pretty much the beginner's course and adequate if you ignore amenities.
Those aren't even part of C. They're function calls in an external library, and have nothing to do with the language itself.
That's part of the reason C succeeded, and Ada failed. Ada made specific language concepts for things like memory management and threading, which C left for external libraries.
Which is, in its way, the reason C "failed", too. It seems to be a law of programming that the complexity required to implement a real-world useful language has a constant minimum. If you leave it out of the syntax, you'll have to include it in the library. And if you leave it out of the standard library, it will be implemented differently in each implementation's nonstandard library - trashing the language's supposed portability.
In other words, C isn't really a language. It's a core upon which a language can be built. C plus the standard library plus posix is a language. And even that relies heavily on the preprocessor to mutate your code to match local implementation quirks.
You can do all that stuff, but I'm not the manual, go read it. Don't forget Ada was amongst other things designed for programming on the bare metal, for embedded (military) apps.
It has memory management, quite a sensible sort actually. First, you can manually deallocate things (like "free"). Second, you can take complete control of the memory allocation of a type via "storage pools" - allowing tricks like mark-and-release or garbage collection. Third, it's clever enough to free the storage for everything of a particular type, when that type goes out of scope. All of which makes a lot more sense than C's rather brute-force "malloc" and "free".
Also, Ada leaves C in the dust for bit-flipping. You can specify layout of data down to the byte-order and bit-width, the exact modulus of modular integers, the exact delta of fixed-point numbers, etc etc.
Personally I think the reasons Ada didn't catch on much more are down to an early lack of good compilers, and a stagnant library (no standard way to access sockets? Is this the 1980s?).
...because it's not just "foreach n in X loop", it's "declare type Array_Bounds is Integer range 1.. 5; begin for I in Array_Bounds'Range loop [...] end loop; end;".
A proper type system is worth a heck of a lot more than a few characters saved typing!
Yes, you can write it legibly, but as I discovered that's not the problem. The real problem with Perl is that (a) its nonlinearities make it very nearly impossible to predict and intercept all failure modes of a (sub)program, and (b) it not merely fails to support, but actively subverts hard interfaces. In practise what this means is: you can never cleanly wall off a piece of Perl code and say "this is known to be correct and will fail informatively if misused". There is always some novel way for it to blow up, which will bite you in the ass when your program complexity rises above n (where n is actually quite small).
The whole GUI library - the shapes of widgets, the color scheme, the window layout with its floating menu - is very NeXT, and very very dated. Compare a modern app like firefox, on a modern desktop like KDE. Everything is there when you need it, but wastes minimum space when not. And it's not stylistically intrusive.
I hate to say this, because NeXT was a style god when it came out, but the state of the art has moved on since.
More like, the sheer volume of leechers, driving up bandwidth bills. Centralized media hosting simply got too expensive for amateurs.
In effect BT brings us back to the file-sharing web of the late '90s, and resurrects the old whack-a-mole gambit. Remember that? "They can't stop us all". They could and did when sites had to be big and centralized. But the game's different when centralization is just a matter of market attention.
Pretty much everything you mentioned is actually plausible in the next quarter decade. Robots are getting pretty impressive. Burt Rutan is working on supersonic civilian flight (the next big app for suborbital ships after space tourism is fast intercontinental travel).
As for the 20 hour work week, well... those 60 hours you presently work? You're spending at least 40 of them as an unpaid serf of the taxman. That's where the 20 hour work week went: it went to Washington. To get it back, elect a Libertarian.
If you've read the synopsis, you've read the book
on
Blink
·
· Score: 1
Eh, well, I used fast judgement to tell me to avoid this book, because it smells not so much of new-age (which I often like), but of content-free anecdotes. The kind where you enliven a perfectly good one-page paper with 499 pages of illustrative example. If you've read the slashdot blurb, you've pretty much read everything the book has to say.
Now, what I wouldn't mind in the least is some steps towards developing a "Bene Gesserit" style technology of the quick mind. But I doubt this book advances the state of the art.
It's a war game, not a war.
on
Blink
·
· Score: 2, Interesting
So he should have been let finish, for glory points? Not what the game's about. War games are about gathering info. What if we change this or that parameter? Add this or that constraint? And so forth. If the game's been played out to a successful conclusion - guaranteed victory by one side or the other - then it's over. In other words, it wasn't one war game where they rigged the result, it became two war games, one in which David won, another in which Goliath won. Both chock full of useful info to be analysed.
Now, if someone really did invent unobtanium, the next nifty space ladder idea, would be one in solar orbit. Park the center of mass in earth's orbit a little way off to the side, and grow ladders down to Venus and up to Mars...
Escape velocity is for a ballistic trajectory. Ballistic, meaning unpowered after the launch. That is, if you chuck a rock at sea level upwards at that speed, it will slow and slow but never quite stop.
What you're talking about is escaping by just continually going upward, like climbing a ladder. Which you could, if there were a big enough ladder - but of course there isn't. So rather than standing on a solid, you have to continuously accelerate against gravity to even stay put. Possible - it's what a Harrier jump jet does when hovering at take-off - but expensive in fuel, meaning you can't do it long enough to get anywhere useful before the fuel runs out. It makes more sense to burn all your fuel as early as possible, accelerate as fast as possible, and coast most of the way ballistically. That way you get rid of the fuel fast (it's heavy and expensive to lug) and you don't waste effort just staying put.
No, trek is about the past. Specifically, the technocratic science-utopia ideals of the 1950s, the emerging civil rights movement of the 1960s, the 1980s liberal ideal of an greed-free moneyless society so utterly purged of "isms" that they've become inconcievable.
SF has always been about the present day as seen through a distorting lens. Trek was no exception.
And then, it painted itself into a corner. Typical left-utopia problem: nowhere to go, nothing to do, no hope of rising above equality except in science, arts, or the military. Effectively Trek disproved itsself. The only society-changing message it can send anymore is "avoid this".
They tried to keep it running on momentum, but Trek without a message, without reflections of reality, is just a dull and dated SF show.
Quoting the judge: after Lawrence, government can no longer rely on the advancement of a moral code [...] as a legitimate, let alone compelling, state interest. Meaning it can neither slip past the "strict scrutiny" test if fundamental rights are involved, nor even pass the lighter-weight "rational basis" test. It can't justify a law at all, period, case dismissed.
That basically at one stroke rules that the entire "social conserative" agenda may never be legislated, and reverses everything they already have on the books. I can practically hear their screams from here, and I'm in England.
If higher courts pick this up, it'll be the biggest thing since Roe v Wade. Heck, bigger.
Slashdot Mirror
Schrödinger's cat experiment?
Hmm, yeah, a major way of knowing you've hit real SF is that it doesn't end with "...the status quo ante was repaired, and everyone lived normally ever after" (I exclude from this the predictable lame-ass sequel hook with which hollywood routinely pollutes its products). It seems there's not much of a USA market for anything but affirmation of stasis. That's one reason why I like Japanese (animated) movies. They seem more willing to wreak change upon characters and settings in non-reversible ways.
BTW, that's also one reason "fantasy" settings annoy me. They need constant deus-ex maintainance to hang onto the status quo. As Pterry has proved, you let a fantasy setting run unhampered, and it will unravel into steampunk within a generation.
The problem is it's coded with the creaky, ancient widget library "motif". I cannot speak for its internals, but motif is older than linux, it's pure C, until fairly recently was commercial closed-source, and I've never seen a motif program that wasn't brittle and flaky. Not to mention unaesthetic, user hostile, non-integrated, and prone to ignoring the scroll wheel. None of which is acceptable anymore, not after using modern apps.
"we would probablly lack any auto immune response to be able to combat them."
It's easy enough to speculate on a vice versa: our modern earth bacteria are tough customers, honed by millennia of unending counter-immune war. Wimpy mars bacteria would cower in their meteorite, like preschoolers dumped in a rough biker bar.
Yes, scientific types, I'm blowing smoke, too. Vote me +1, funny.
...since there's nothing there to get put out by any mistake, except dust, rocks, and wind.
RTFA.
This is not hoodoo, it's fast subconscious prediction from patterns in normal 5-sense clues.
Brings a new dimension to the old practical joke of net-ordering your victim tons of pizzas.
Fast food with a blast radius!
Repetitive CPU-bound work is a strength of JIT compilation. Java should do fine.
You want speed out an RDBMS, the deciding factors are likely to be, in decreasing order of importance: good algorithms, well-designed tables and indexes, fast disk IO, abundant RAM.
I can summarize a working minimum of what you need to know about building in cob in one post. That's ridiculously easy compared to brick-and-wood housing!
FYI, here goes:
- Clay, sand, staw. Clay binds, sand prevents shrinking, staw acts as rebar. Use subsoil from the site, tread in the straw. Measure your subsoil by shaking it in water and letting it settle in layers, to see if you need to add clay or sand. Make up test bricks to see if you got the mix right for shrinkage, cracking, and strength. You'll need a higher percentage of sand than you expect. Sieve out rocks and gravel to avoid introducing weak spots.
- Apply it wet enough to squish, neither runny nor hard. Build upwards iteratively, stopping each course just before it starts to sag under its own weight. Measure the plumb with a spirit level and cut off soft cob to keep it from bulging or sagging. Walls can be straight or tapered, which is stronger and saves time/effort building the upper parts. Test taper by gluing a precisely angled bit of wood onto a spirit level. Tapered outside and plumb inside makes furniture an easier fit.
- Overengineer the thickness of the walls. Theoretically, precisely mixed cob applied with skill can be used in walls a foot thick, but build them two feet thick (or more) at the base.
- You need a stem wall, which is a short (waist height) hard and nonporous wall upon which to sit the cob. Stone, concrete or brick are good. This keeps the dried mud above damp ground and rain-runoff splatter. Make the top jagged so the cob sticks. You can skip this, but your house will have a limited "shelf life". Also, the roof needs to overhang enough to throw rain clear of the walls, and you need good drainage and a site which won't flood. In general, water flowing over cob will erode it, but rain won't.
- Cob functions as "thermal mass", bringing inside temperature towards the daily mean temperature (ie: it smooths out cold and heat into continuing warmth). It doesn't insulate much. Avoid using it where you get no sun (north slope) or where the climate is cold all day. Plan the house as a passive solar collector, with windows sited to admit and trap morning and evening sun.
- Joint the cob to woodwork, especially upstairs-floor beams and roof rafters, by burying anchor points of jaggedy wood into the cob wall. Logs stripped of bark with branch-stubs sticking out are good. Don't bury rafters and beams directly into the cob, because they can shift and tear loose due to settlement and heat-expansion. Non-opening window panes can simply be buried straight into walls, with expansion foam around the edges to prevent them being crushed.
- You can build furniture straight from the cob by cantilevering outwards (go slowly) or by carving in. Tamped cob can also be used to make floors - seal the final layer with boiled linseed oil.
- Never put nonporous materials over cob, especially outside. That includes oil based paints, cement based interior and exterior plasters. Cement exterior plaster is a major cause of cob wall collapse. Water runs in through cracks, down the inside and liquefies the wall base. Instead, use mud-straw plaster or lime-sand plaster. Whitewash and casein paints can be used inside and out.
There you go, that's pretty much the beginner's course and adequate if you ignore amenities.
In other words, C isn't really a language. It's a core upon which a language can be built. C plus the standard library plus posix is a language. And even that relies heavily on the preprocessor to mutate your code to match local implementation quirks.
You can do all that stuff, but I'm not the manual, go read it. Don't forget Ada was amongst other things designed for programming on the bare metal, for embedded (military) apps.
It has memory management, quite a sensible sort actually. First, you can manually deallocate things (like "free"). Second, you can take complete control of the memory allocation of a type via "storage pools" - allowing tricks like mark-and-release or garbage collection. Third, it's clever enough to free the storage for everything of a particular type, when that type goes out of scope. All of which makes a lot more sense than C's rather brute-force "malloc" and "free".
Also, Ada leaves C in the dust for bit-flipping. You can specify layout of data down to the byte-order and bit-width, the exact modulus of modular integers, the exact delta of fixed-point numbers, etc etc.
Personally I think the reasons Ada didn't catch on much more are down to an early lack of good compilers, and a stagnant library (no standard way to access sockets? Is this the 1980s?).
...because it's not just "foreach n in X loop", it's "declare type Array_Bounds is Integer range 1 .. 5; begin for I in Array_Bounds'Range loop [...] end loop; end;".
A proper type system is worth a heck of a lot more than a few characters saved typing!
Yes, you can write it legibly, but as I discovered that's not the problem. The real problem with Perl is that (a) its nonlinearities make it very nearly impossible to predict and intercept all failure modes of a (sub)program, and (b) it not merely fails to support, but actively subverts hard interfaces. In practise what this means is: you can never cleanly wall off a piece of Perl code and say "this is known to be correct and will fail informatively if misused". There is always some novel way for it to blow up, which will bite you in the ass when your program complexity rises above n (where n is actually quite small).
The whole GUI library - the shapes of widgets, the color scheme, the window layout with its floating menu - is very NeXT, and very very dated. Compare a modern app like firefox, on a modern desktop like KDE. Everything is there when you need it, but wastes minimum space when not. And it's not stylistically intrusive.
I hate to say this, because NeXT was a style god when it came out, but the state of the art has moved on since.
More like, the sheer volume of leechers, driving up bandwidth bills. Centralized media hosting simply got too expensive for amateurs.
In effect BT brings us back to the file-sharing web of the late '90s, and resurrects the old whack-a-mole gambit. Remember that? "They can't stop us all". They could and did when sites had to be big and centralized. But the game's different when centralization is just a matter of market attention.
Pretty much everything you mentioned is actually plausible in the next quarter decade. Robots are getting pretty impressive. Burt Rutan is working on supersonic civilian flight (the next big app for suborbital ships after space tourism is fast intercontinental travel).
As for the 20 hour work week, well... those 60 hours you presently work? You're spending at least 40 of them as an unpaid serf of the taxman. That's where the 20 hour work week went: it went to Washington. To get it back, elect a Libertarian.
Eh, well, I used fast judgement to tell me to avoid this book, because it smells not so much of new-age (which I often like), but of content-free anecdotes. The kind where you enliven a perfectly good one-page paper with 499 pages of illustrative example. If you've read the slashdot blurb, you've pretty much read everything the book has to say.
Now, what I wouldn't mind in the least is some steps towards developing a "Bene Gesserit" style technology of the quick mind. But I doubt this book advances the state of the art.
So he should have been let finish, for glory points? Not what the game's about. War games are about gathering info. What if we change this or that parameter? Add this or that constraint? And so forth. If the game's been played out to a successful conclusion - guaranteed victory by one side or the other - then it's over. In other words, it wasn't one war game where they rigged the result, it became two war games, one in which David won, another in which Goliath won. Both chock full of useful info to be analysed.
...point them at an ocean.
-Moving and static.
-I can pick it up but I can't.
-And paint won't stick!
Oh, the humanity!
...there won't be one to earth escape velocity.
Now, if someone really did invent unobtanium, the next nifty space ladder idea, would be one in solar orbit. Park the center of mass in earth's orbit a little way off to the side, and grow ladders down to Venus and up to Mars...
Escape velocity is for a ballistic trajectory. Ballistic, meaning unpowered after the launch. That is, if you chuck a rock at sea level upwards at that speed, it will slow and slow but never quite stop.
What you're talking about is escaping by just continually going upward, like climbing a ladder. Which you could, if there were a big enough ladder - but of course there isn't. So rather than standing on a solid, you have to continuously accelerate against gravity to even stay put. Possible - it's what a Harrier jump jet does when hovering at take-off - but expensive in fuel, meaning you can't do it long enough to get anywhere useful before the fuel runs out. It makes more sense to burn all your fuel as early as possible, accelerate as fast as possible, and coast most of the way ballistically. That way you get rid of the fuel fast (it's heavy and expensive to lug) and you don't waste effort just staying put.
"Trek is, and has been, about the future"
No, trek is about the past. Specifically, the technocratic science-utopia ideals of the 1950s, the emerging civil rights movement of the 1960s, the 1980s liberal ideal of an greed-free moneyless society so utterly purged of "isms" that they've become inconcievable.
SF has always been about the present day as seen through a distorting lens. Trek was no exception.
And then, it painted itself into a corner. Typical left-utopia problem: nowhere to go, nothing to do, no hope of rising above equality except in science, arts, or the military. Effectively Trek disproved itsself. The only society-changing message it can send anymore is "avoid this".
They tried to keep it running on momentum, but Trek without a message, without reflections of reality, is just a dull and dated SF show.
RIP
Quoting the judge: after Lawrence, government can no longer rely on the advancement of a moral code [...] as a legitimate, let alone compelling, state interest. Meaning it can neither slip past the "strict scrutiny" test if fundamental rights are involved, nor even pass the lighter-weight "rational basis" test. It can't justify a law at all, period, case dismissed.
That basically at one stroke rules that the entire "social conserative" agenda may never be legislated, and reverses everything they already have on the books. I can practically hear their screams from here, and I'm in England.
If higher courts pick this up, it'll be the biggest thing since Roe v Wade. Heck, bigger.
This article discusses FreeBSD's preference for sleep locks as versus the spin locks in Linux.
Anybody know why Linux went for the spin lock approach? What are the relative merits?