The thing is that it *is* self-consistent. And it doesn't deny any known results. So to deny it because it sounds silly leaves you unable to justify quantum theory or relativity.
My problem with it is that there doesn't seem to be any reasonable way to test it, but perhaps that's a part of what they're going to be doing.
I've at times been taken with the idea that the universe is a video game and that we are playing it. In which case if you break out it might turn out to be time for dinner, or bed, or something analogous.
He's assuming more than that, he's assuming the world outside the simulation is essentially the same as the world within the simulation.
FWIW, my bet would be that we live in something that can be exactly modeled by a simulation, but which isn't one. But I can't think of any way to prove that. OTOH, even knowing the exact model of the simulation could turn out to be quite useful. But perhaps not. Sometimes the only way to get the result is to compute all the intermediate steps.
The thing is, is it's actual research, then you can't predict what will turn out to be useful. If we do live in either a simulation or something that could be mapped to a simulation, that this could lead to way to take advantage of of the implementation to do??? Teleportation or FTL doesn't seem unreasonable. Unlikely, I'll grant you, but most research is unlikely to turn up anything useful, we progress by accumulating the ones that do.
One of the problems with the current society is that all research is expected to know ahead of time what the result will be, and that puts strong limits on what can be discovered.
Pseudoscience? Well, no. It seems unlikely that we live in a simulation, but there's no evidence against it, and that may develop evidence either in favor of or against that hypothesis. Though my prediction would be that it won't.
Being usable during a brief local outage is a valid use case for cellular. During every reported widespead outage cell phones have immediately stopped working. They didn't bother to give the cell towers backup power supplies. This could obviously easily be fixed, but it won't be if they don't have to, because it costs more.
POTS service generally has lasted during widespread blackouts that lasted over a day, if not for several days. I don't know if that's still true, because they may have been allowed to slack on maintenance.
OTOH, only one telephone in my house will work without external electrical power, but the rest have battery backup that's good for about an hour of infrequent use. (Manufacturer's spec, I've never tested, and my memory is probably being conservative over what was promised.)
The 'adapter' presents a POTS interface and typically has GPS built in, and presents a landline CLI. To all intents of purposes it's identical to a landline so far as the responders are concerned. This is a non-issue unless it's a real emergency, and the power is out.
N.B.: The copper lines also needed electricity, but they operated on batteries that the newer systems don't bother with, because it's cheaper not to, and nobody's making them care. There's really nothing inherently better about copper, though the electrical conductivity makes it easier to power remote devices, but mainly it's design. The older devices were required to be reliable in case of disaster, the new ones not...and it's cheaper not to care.
Unfortunately, in a major disaster cellphones are nearly guaranteed to stop working for an indefinite period of time. Land lines have been a lot more durable.
I'm not sure it *is* misleading, even given your elaboration. How many customers with know that VOIP means the line stops working if the power goes out? If they don't know, then they can't properly justify it.
What happens if the tech doesn't get the suggested percentage of upgrades?
I'm not sure the headline *is* misleading. I agree it might be, but there have been so many shady business practices recently that I am reluctant to give them the benefit of the doubt.
As I said, premature optimization. That shouldn't have been baked into the language specs. Neither should the precision of an int. (Well, there would be nothing wrong with having int8, int16, int32,...there's value in that, but which one corresponds to an int should not be a part of the language spec. And in java because everything the user builds is an object you can specify Integer64, but if you want an int64 you say long, and there is not way to get int128.)
gcj existed, but I was never told that it was a good implementation. When I looked into using I quickly became discouraged. There were some compilers that compiled jdk1.1 code to native code, but I never encountered one that even almost kept up with the standard. They may exist, but I've never encountered them.
Yeah, I'm afraid that Vala is a dead end. That's a pity because I liked the basic design.
I've never bothered to learn C# as when I was interesting in it several years ago the Linux versions were terrible. I believe, however, that it uses utf-16 strings. I'm not sure whether it can properly decide whether or not a character (utf-32 character) is punctuation. Java can't. (I wrote a custom routine to do that back when I was experimenting on using Java.)
Java has a lot of decent features, but it also made some very bad decisions....sometimes because of premature optimization. E.g., character strings should be either utf-8 or utf-32. Utf-16 was a mistake. My guess is that utf-8 is the best general standard, but there are arguments in favor of utf-32. I know of no valid argument in favor of utf-16.
Also the decision to not compile to native code limited the reasonable domain of use. For many purposes there's no problem with using the jvm, but for others it's a serious or critical problem.
Then there's the decision to only support objects....except sometimes. That is a bad decision. Or the decision to not support structs (i.e., data structures with a defined memory allocation, byte size, and and byte level positioning). I believe that you can actually finagle things around to accomplish this in Java, but it sure isn't easy, and that has more than once caused me to rule it out for use.
FWIW, my current languages are D (dmd) and Python. I keep looking at Vala, but the documentation is pitiful and it doesn't seem able to get out of pre-beta stability. Go and Rust have stylistic requirements that repulse me even more strongly than does Lisp, so I can't judge their quality. I keep thinking that I ought to seriously consider Ada, but the user community seems to continue to shrink. Eiffel had real promise a couple of decades ago, but it also seems to have turned in upon itself. And Vala shows signs of going the same way, without even first reaching a post-beta version. This is partially because it's tied into the gobject model, but it's hard to say what they should have done instead.
Do I think flawed languages tend to cause flawed programs...yes. This doesn't mean I think their choices of non-flawed languages are valid. And each language also has, at best, only a limited range of problems correctly addressed in it. For some problems assembler is better than anything else, but for others that would be a ridiculous approach. Usually you can depend on libraries to extend range of tasks a language is useful for, but even then there are limits.
So. I want a language that supports structs, that has built in hash tables, that makes memory management something I barely need to consider, and that can handle unicode well... Of the languages I know that means D. If I didn't need structs and wasn't really worried about efficiency I'd pick Python, because it's easier to use and has better library support. What alternatives are there? C++ fails immediately on several counts. C is worse. Java also fails, though it's nearly good enough if I don't need structs and am willing to compromise heavily on unicode handling. But Java also has hash tables that are clumsy and difficult to use compared to either D or Python.
Now imagine I wanted to tackle this project in C. I need to implement custom hash tables with type dependent memory management functions. I need to write lots of unicode handling routines. I need to use a complex pseudo-object construction mechanism whenever I need to deal with indirect objects, including perhaps reference counted pointers, but I'd better make sure there aren't any referential loops. Etc. This at minimum quintuples the errors. And I probably wouldn't write the most efficient implementations. C++ is a bit better, as I can use STL hash tables, but unicode handling is still a real problem, and I haven't yet even discussed concurrency, messaging, etc.
So for the range I problem I'm looking at C and C++ are unreasonable choices. Java has problems that cause continual vexation. (There's also something about memory size limitations, but I've never built something far enough to run into that problem.) Python has the GIL, which the multiprocessing module only partially addresses. When I was doing a toy application I actually used UDP networking to handle concurrency. So the language I chose was D. I avoid a tremendous number of problems by off-loading hash table,..., concurrency onto the language. Avoiding those problems removes a tremendous number of errors that I would have created while trying to implement things I would need to research how to do.
But the junk you're trying to reach is also moving exactly at orbital velocity for whatever orbit it's in, it's just at a slightly different angle. And almost all of it is moving in nearly the same orbit. So the difference in velocity would be relatively small. Of course, "relatively small" is still pretty large, but the GP's estimate of 400 mph is probably a reasonable guess. But the masses are low, so a reasonable catcher is probably possible. But you'd need to wait until a shard approached you (preferably on an skew course), and then shoot out a net to catch it. Not easy. Much easier to scavenge from the second stage that launched you.
Sorry, the missing piece is a closed cycle ecology. Well, nearly closed. This could be important, but it's not crucial as there are other ways of making ion rockets work in near-solar space. But the closed cycle ecology is needed if you want to get people living away from Earth. (i.e., the general category of "flexible ion rocket" is extremely important, this particular gadget is one possible implementation. But even all together without a [nearly] closed cycle ecology you're only facilitating robot exploration.)
P.S.: when you're talking about a habitat large enough to rotate for gravity, and with a good radiation shield to protect from the sun, you're talking something significantly heavy. Don't expect an ion-rocket of any sort to move you quickly. For an ion rocket 30 pounds of thrust is unbelievably large, and when you apply 30 pounds of thrust to something that masses 1,000 tons you're going to get very slow changes in momentum. (I grabbed "30 pounds" out of the air, but it resonates with some memory I can't identify, a Google search turned up "...the VASIMR has 4 Newtons of thrust (0.9 pounds) with a specif..." http://www.universetoday.com/4...
It's not the editor that's bad, it's the way it handles files. But some people like it.
P.S.: I used a number of text editors on a number of different systems before I encountered EMACS. EMACS file handling is the only one that really annoyed me. (I'm not a real fan of multi-key commands where the keys need to be pressed simultaneously either, but by comparison that's minor.)
There are lots of valid reasons to hate systemd. Unfortunately there are also lots of good reasons to hate sysV init.
On the balance I preferred sysV init, and this kind of bug is what I expect to show up repeatedly in systemd. Large complex programs tend to have more bugs and potential for abuse, and I've perceived no particular value from systemd, whereas for a long time it made some of my sysems unbootable (I could get at them by re-writing the boot tracks on the hard disk, so there wasn't any good reason for them to be unbootable.) There's also the problem that newer systems that want to use UUIDs rather than relative paths break whenever a new install is done...but that's not exactly systemd dependent, and is done as an attempt to resolve boot order among devices. It works for THAT purpose, but if I don't rewrite things to use relative paths before I do a new install, things break. Complex systems tend to break in unexpected circumstances, and the more complex something is the less you are able to test all reasonable paths of execution.
So I don't like systemd. It's a bad decision. It also slows boot time in a most remarkable way for a system that's supposed to speed up boot time. This isn't usually important, but it's annoying, and every time they tell me it speed up boot times it reminds me that they are lying to me.
Unfortunately, many programs are adopting mechanisms that won't work outside the context of systemd. One such is KDE. This is so annoying that I repeatedly consider switching to some BSD, but I like the ext4 file system, and switching would be a lot of work. So I haven't thoroughly investigated it yet. YET. But it was a really bad decision, and the main reason it was bad is that it's a lot more complex. Ordinary bugs can be fixed when found. Complexity is more difficult.
Insulin shock is slow compared to anaphylactic shock, so your analogy fails. And insulin injection isn't intended to avert insulin shock, it's a potential cause of it (if you don't eat enough sugars afterwards). Even when insulin shock is coming on the normal treatment is to either eat some hard candies or drink a bit of glucose solution...not an injection.
Yes, but it's not clear to me that it's even possible to write a generic prescription for an epinephrine injector. It looks as if they were approved as separate drug+delivery systems, and thus the prescription may well need to specify which one.
If it's an actual generic, I always get the switch happening automatically. But there are things which are essentially generic, but which are different. There is also corruption, like the withdrawal of generic colchicine from the market so that only the trademarked version of the same drug can be purchased, at a vastly increased price. It *was* a generic, but not anymore.
This appears to be a case where each slightly different injector is considered a separate delivery system so it's not a generic equivalent. As such the drug+delivery system is not multiple source, and probably also not generic even though functionally it is equivalent. So you need a prescription for the precise brand, and if the pharmacy doesn't have that brand in stock, you don't get it.
IOW, it's not generic and it's not multiple source, even though there are arguments as to why it should be.
It's not multiple source unless there are multiple sources. I'd go further and say it's not multiple source unless there are multiple sources that are covered by the same prescription/insurance plan.
If they want to not be considered single source, they need to be taking steps to ensure that there is actual competition.
Well, when my doctor wanted me to carry something like that around, he filled a couple of disposable syringes with adrenaline, put them in a plastic case, and said "Use them if you need to. They should be good for a year if you keep them sealed and don't get them too hot." He also wrote out a prescription for Epipen if I felt more comfortable with that approach. As I happens I never had to use them.
Slashdot Mirror
The thing is that it *is* self-consistent. And it doesn't deny any known results. So to deny it because it sounds silly leaves you unable to justify quantum theory or relativity.
My problem with it is that there doesn't seem to be any reasonable way to test it, but perhaps that's a part of what they're going to be doing.
I've at times been taken with the idea that the universe is a video game and that we are playing it. In which case if you break out it might turn out to be time for dinner, or bed, or something analogous.
He's assuming more than that, he's assuming the world outside the simulation is essentially the same as the world within the simulation.
FWIW, my bet would be that we live in something that can be exactly modeled by a simulation, but which isn't one. But I can't think of any way to prove that. OTOH, even knowing the exact model of the simulation could turn out to be quite useful. But perhaps not. Sometimes the only way to get the result is to compute all the intermediate steps.
The thing is, is it's actual research, then you can't predict what will turn out to be useful. If we do live in either a simulation or something that could be mapped to a simulation, that this could lead to way to take advantage of of the implementation to do??? Teleportation or FTL doesn't seem unreasonable. Unlikely, I'll grant you, but most research is unlikely to turn up anything useful, we progress by accumulating the ones that do.
One of the problems with the current society is that all research is expected to know ahead of time what the result will be, and that puts strong limits on what can be discovered.
Useless, probably, but not certainly.
Pseudoscience? Well, no. It seems unlikely that we live in a simulation, but there's no evidence against it, and that may develop evidence either in favor of or against that hypothesis. Though my prediction would be that it won't.
Being usable during a brief local outage is a valid use case for cellular. During every reported widespead outage cell phones have immediately stopped working. They didn't bother to give the cell towers backup power supplies. This could obviously easily be fixed, but it won't be if they don't have to, because it costs more.
POTS service generally has lasted during widespread blackouts that lasted over a day, if not for several days. I don't know if that's still true, because they may have been allowed to slack on maintenance.
OTOH, only one telephone in my house will work without external electrical power, but the rest have battery backup that's good for about an hour of infrequent use. (Manufacturer's spec, I've never tested, and my memory is probably being conservative over what was promised.)
The 'adapter' presents a POTS interface and typically has GPS built in, and presents a landline CLI. To all intents of purposes it's identical to a landline so far as the responders are concerned. This is a non-issue unless it's a real emergency, and the power is out.
N.B.: The copper lines also needed electricity, but they operated on batteries that the newer systems don't bother with, because it's cheaper not to, and nobody's making them care. There's really nothing inherently better about copper, though the electrical conductivity makes it easier to power remote devices, but mainly it's design. The older devices were required to be reliable in case of disaster, the new ones not...and it's cheaper not to care.
Unfortunately, in a major disaster cellphones are nearly guaranteed to stop working for an indefinite period of time. Land lines have been a lot more durable.
I'm not sure it *is* misleading, even given your elaboration. How many customers with know that VOIP means the line stops working if the power goes out? If they don't know, then they can't properly justify it.
What happens if the tech doesn't get the suggested percentage of upgrades?
I'm not sure the headline *is* misleading. I agree it might be, but there have been so many shady business practices recently that I am reluctant to give them the benefit of the doubt.
Not really. Have you even looked at the VP candidates.
As I said, premature optimization. That shouldn't have been baked into the language specs. Neither should the precision of an int. (Well, there would be nothing wrong with having int8, int16, int32,...there's value in that, but which one corresponds to an int should not be a part of the language spec. And in java because everything the user builds is an object you can specify Integer64, but if you want an int64 you say long, and there is not way to get int128.)
gcj existed, but I was never told that it was a good implementation. When I looked into using I quickly became discouraged. There were some compilers that compiled jdk1.1 code to native code, but I never encountered one that even almost kept up with the standard. They may exist, but I've never encountered them.
Yeah, I'm afraid that Vala is a dead end. That's a pity because I liked the basic design.
I've never bothered to learn C# as when I was interesting in it several years ago the Linux versions were terrible. I believe, however, that it uses utf-16 strings. I'm not sure whether it can properly decide whether or not a character (utf-32 character) is punctuation. Java can't. (I wrote a custom routine to do that back when I was experimenting on using Java.)
But those logs are binary files, which isn't good. (The rest of your point seems valid.)
Java has a lot of decent features, but it also made some very bad decisions....sometimes because of premature optimization. E.g., character strings should be either utf-8 or utf-32. Utf-16 was a mistake. My guess is that utf-8 is the best general standard, but there are arguments in favor of utf-32. I know of no valid argument in favor of utf-16.
Also the decision to not compile to native code limited the reasonable domain of use. For many purposes there's no problem with using the jvm, but for others it's a serious or critical problem.
Then there's the decision to only support objects....except sometimes. That is a bad decision. Or the decision to not support structs (i.e., data structures with a defined memory allocation, byte size, and and byte level positioning). I believe that you can actually finagle things around to accomplish this in Java, but it sure isn't easy, and that has more than once caused me to rule it out for use.
FWIW, my current languages are D (dmd) and Python. I keep looking at Vala, but the documentation is pitiful and it doesn't seem able to get out of pre-beta stability. Go and Rust have stylistic requirements that repulse me even more strongly than does Lisp, so I can't judge their quality. I keep thinking that I ought to seriously consider Ada, but the user community seems to continue to shrink. Eiffel had real promise a couple of decades ago, but it also seems to have turned in upon itself. And Vala shows signs of going the same way, without even first reaching a post-beta version. This is partially because it's tied into the gobject model, but it's hard to say what they should have done instead.
Do I think flawed languages tend to cause flawed programs...yes. This doesn't mean I think their choices of non-flawed languages are valid. And each language also has, at best, only a limited range of problems correctly addressed in it. For some problems assembler is better than anything else, but for others that would be a ridiculous approach. Usually you can depend on libraries to extend range of tasks a language is useful for, but even then there are limits.
So. I want a language that supports structs, that has built in hash tables, that makes memory management something I barely need to consider, and that can handle unicode well... Of the languages I know that means D. If I didn't need structs and wasn't really worried about efficiency I'd pick Python, because it's easier to use and has better library support. What alternatives are there? C++ fails immediately on several counts. C is worse. Java also fails, though it's nearly good enough if I don't need structs and am willing to compromise heavily on unicode handling. But Java also has hash tables that are clumsy and difficult to use compared to either D or Python.
Now imagine I wanted to tackle this project in C. I need to implement custom hash tables with type dependent memory management functions. I need to write lots of unicode handling routines. I need to use a complex pseudo-object construction mechanism whenever I need to deal with indirect objects, including perhaps reference counted pointers, but I'd better make sure there aren't any referential loops. Etc. This at minimum quintuples the errors. And I probably wouldn't write the most efficient implementations. C++ is a bit better, as I can use STL hash tables, but unicode handling is still a real problem, and I haven't yet even discussed concurrency, messaging, etc.
So for the range I problem I'm looking at C and C++ are unreasonable choices. Java has problems that cause continual vexation. (There's also something about memory size limitations, but I've never built something far enough to run into that problem.) Python has the GIL, which the multiprocessing module only partially addresses. When I was doing a toy application I actually used UDP networking to handle concurrency. So the language I chose was D. I avoid a tremendous number of problems by off-loading hash table, ..., concurrency onto the language. Avoiding those problems removes a tremendous number of errors that I would have created while trying to implement things I would need to research how to do.
But the junk you're trying to reach is also moving exactly at orbital velocity for whatever orbit it's in, it's just at a slightly different angle. And almost all of it is moving in nearly the same orbit. So the difference in velocity would be relatively small. Of course, "relatively small" is still pretty large, but the GP's estimate of 400 mph is probably a reasonable guess. But the masses are low, so a reasonable catcher is probably possible. But you'd need to wait until a shard approached you (preferably on an skew course), and then shoot out a net to catch it. Not easy. Much easier to scavenge from the second stage that launched you.
Sorry, the missing piece is a closed cycle ecology. Well, nearly closed. This could be important, but it's not crucial as there are other ways of making ion rockets work in near-solar space. But the closed cycle ecology is needed if you want to get people living away from Earth. (i.e., the general category of "flexible ion rocket" is extremely important, this particular gadget is one possible implementation. But even all together without a [nearly] closed cycle ecology you're only facilitating robot exploration.)
P.S.: when you're talking about a habitat large enough to rotate for gravity, and with a good radiation shield to protect from the sun, you're talking something significantly heavy. Don't expect an ion-rocket of any sort to move you quickly. For an ion rocket 30 pounds of thrust is unbelievably large, and when you apply 30 pounds of thrust to something that masses 1,000 tons you're going to get very slow changes in momentum. (I grabbed "30 pounds" out of the air, but it resonates with some memory I can't identify, a Google search turned up "...the VASIMR has 4 Newtons of thrust (0.9 pounds) with a specif..." http://www.universetoday.com/4...
It's not the editor that's bad, it's the way it handles files. But some people like it.
P.S.: I used a number of text editors on a number of different systems before I encountered EMACS. EMACS file handling is the only one that really annoyed me. (I'm not a real fan of multi-key commands where the keys need to be pressed simultaneously either, but by comparison that's minor.)
There are lots of valid reasons to hate systemd. Unfortunately there are also lots of good reasons to hate sysV init.
On the balance I preferred sysV init, and this kind of bug is what I expect to show up repeatedly in systemd. Large complex programs tend to have more bugs and potential for abuse, and I've perceived no particular value from systemd, whereas for a long time it made some of my sysems unbootable (I could get at them by re-writing the boot tracks on the hard disk, so there wasn't any good reason for them to be unbootable.) There's also the problem that newer systems that want to use UUIDs rather than relative paths break whenever a new install is done...but that's not exactly systemd dependent, and is done as an attempt to resolve boot order among devices. It works for THAT purpose, but if I don't rewrite things to use relative paths before I do a new install, things break. Complex systems tend to break in unexpected circumstances, and the more complex something is the less you are able to test all reasonable paths of execution.
So I don't like systemd. It's a bad decision. It also slows boot time in a most remarkable way for a system that's supposed to speed up boot time. This isn't usually important, but it's annoying, and every time they tell me it speed up boot times it reminds me that they are lying to me.
Unfortunately, many programs are adopting mechanisms that won't work outside the context of systemd. One such is KDE. This is so annoying that I repeatedly consider switching to some BSD, but I like the ext4 file system, and switching would be a lot of work. So I haven't thoroughly investigated it yet. YET. But it was a really bad decision, and the main reason it was bad is that it's a lot more complex. Ordinary bugs can be fixed when found. Complexity is more difficult.
Thanks. I'll try to remember that if I ever think I need one.
Insulin shock is slow compared to anaphylactic shock, so your analogy fails. And insulin injection isn't intended to avert insulin shock, it's a potential cause of it (if you don't eat enough sugars afterwards). Even when insulin shock is coming on the normal treatment is to either eat some hard candies or drink a bit of glucose solution...not an injection.
Yes, but it's not clear to me that it's even possible to write a generic prescription for an epinephrine injector. It looks as if they were approved as separate drug+delivery systems, and thus the prescription may well need to specify which one.
If it's an actual generic, I always get the switch happening automatically. But there are things which are essentially generic, but which are different. There is also corruption, like the withdrawal of generic colchicine from the market so that only the trademarked version of the same drug can be purchased, at a vastly increased price. It *was* a generic, but not anymore.
This appears to be a case where each slightly different injector is considered a separate delivery system so it's not a generic equivalent. As such the drug+delivery system is not multiple source, and probably also not generic even though functionally it is equivalent. So you need a prescription for the precise brand, and if the pharmacy doesn't have that brand in stock, you don't get it.
IOW, it's not generic and it's not multiple source, even though there are arguments as to why it should be.
Massing in the streets, perhaps, but without the torches and pitchforks.
It's not multiple source unless there are multiple sources. I'd go further and say it's not multiple source unless there are multiple sources that are covered by the same prescription/insurance plan.
If they want to not be considered single source, they need to be taking steps to ensure that there is actual competition.
Well, when my doctor wanted me to carry something like that around, he filled a couple of disposable syringes with adrenaline, put them in a plastic case, and said "Use them if you need to. They should be good for a year if you keep them sealed and don't get them too hot." He also wrote out a prescription for Epipen if I felt more comfortable with that approach. As I happens I never had to use them.