The link to the repo was NOT reported as being the link to.NET Core, but to a set of libraries that could be used with it. This makes it irrelevant unless I decide to use Mono.
Sorry, but when I checked the article I didn't see anything about the release of.NET core under any particular license. There was a link to GitHub where they had released some libraries, to which I presume your response applies, though I'm not sure. (Yes, I could have checked that, but I didn't, and don't intend to unless it becomes important. It's basically irrelevant unless I adopt the approach, and if I do I'll probably get the code from a standard system repository. I'm not a lawyer, and don't like playing lawyer games. The article didn't say what the license was, so I presume that there's something unexpected going on, even if I don't know what.)
The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces.
A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.2 MB, but that includes more powerful run-time support.
meant that the go compiler was basically a "byte-code compiler", and that this code was run through an interpreter.
By "byte-code compiler" I actually mean it was used to generate a bunch of calls to library routines that did the actual work. I wasn't actually presuming that the op-codes were single bytes, as I consider that irrelevant.
The claim that "it runs as fast as C" is one that I've heard most interpreted languages since Java make, so I pretty much ignored it. I did note that they considered the LLVM to be too slow, but I interpreted this as meaning they build a customized virtual machine.
OTOH, the gcc version of go does compile to machine code, so there's nothing inherently improbable in it actually compiling to machine code. That's just not the way I read things. (I also think of Java as an interpreted language, and Python, and Ruby...though at least in the case of Java and Python the more technically correct phraseology is that they are compiled to a virtual machine.)
For that matter one could say that UCSD Pascal was compiled to a virtual machine, but it was always called an interpreted language.
Sorry, eventually I may consider.NET, now that it's officially been opened, but I'll need to see how the community development goes. If nobody but MS can touch it, I won't trust it.
FWIW, even though Java is mainly FOSS licensed, I don't trust it, and that's BECAUSE Oracle is such a bastard. Suing over API interface identity? Sorry, but how can I trust you? I know they lost the suit (at one level...did they appeal?), but that they would even consider it makes me dubious about them. OTOH, the GPL is pretty strong, so I still feel reasonably comfortable with the parts of Java that are covered by the GPL. But if I were to publish I'd generate the documentation with Doxygen rather than javadoc.
As for.NET... I'll wait and see how it develops. In some ways C# looks interresting, but nothing dramatic, and I don't develop for the web, so... What's in it for me?
Have you read the bit about "Concurrency is not MultiProcessing" (or something that means the same thing). Go is a single threaded language, which is concurrent but not multiprocessing. So there's basically no payoff in many cases from using it, and you've got to run it through an interpreter (unless you use the gcc version).
The problem with Objective-C is its libraries. Nobody has put much work into the cross-platform ones for a decade, and it shows. And since I don't use Apple, Cocoa is of no interest to me, but all the documentation refers to it. So I ignore Objectve C.
I find it a very interesting language that's hobbled by lack of usable documentation. (Even for cross-platform stuff I got redireected to the Apple site.)
So you claim you could implement a B+Tree in Whitespace? BrainFuck?
Sorry, but different languages have different strengths, otherwise we'd all be programming in TML (Turing Machine Language). I could have said assembler, or machine language, but both of those are easier to use.
OTOH, I'll admit that I tend to flit from language to language more than is necessary, and I've still skipped some, like Haskell and CaML. Sometimes a language doesn't look like it would make anything I'm doing easier.
OTOH, I once did list processing in Fortran IV. You can do nearly anything in any common language...but some things are easier to do in some languages than in others. I'd never even try to write a B+Tree in Snobol. You could do it (though the interpreter might choke), but it's obviously the wrong tool for the job.
Well, I don't have much evidence, but if batteries had been half the cost I would have gotten twice as many solar cells, enough batteries, and cut loose from the grid. Anecdote is not data, but that's what I would have done. As it was I figured the benefit wasn't worth the cost, and only got enough solar cells to bring our power use below the threshold where there's a rate increase.
FWIW, I don't think this is the use case that utilities are worried about. What they're worried about is people still on the grid who generate power irregularly, and thus destabilize the network.
Do note, however, that I live in a city. If I lived in a rural area power independence would have been much more valuable. (Where I live power outages are very rarely more than an hour.)
Even typo changes need justification because, as you remarked, "These 'trivial' changes often cause merge conflicts with other trees."
As for this kind of change...if its a real issue, then there needs to be a policy, e.g., "always avoid the singular they". (Personally I often use it, if I remember to. But it sure isn't what I was taught in school. Still, I find it much better than "s/he", though in some contexts I'll use "s/he/it".)
Well, it's snarky, but this time I think xkcd is stupid...though more informed than most people.
It's not an equation that tells you what the answers are, it's an equation that lists your areas of uncertainty. Nobody has come up with a better approach (unless you claim "I don't care" is a better approach). And yes, the areas that are unknown are pretty big, which is good. My suspicion is that if they were better known it would be a very depressing equation. The most obvious simultaneous solution to the Fermi Problem and the Drake Equation is that the lifetime of a technological civilization is quite short.
If you assume the lifespan of a technological civilization is not infintie, you could probably work the Birthday paradox in. It's not exactly a "modulo", but its related.
(That said, I don't see it. Just because I think you could probably work it in doesn't mean I find it at all obvious.)
What idiot modded thie parent offtopic? I could see flamebait, or even, vaguely, troll, but offtopic?
OTOH, I don't see it as particularly useful. Not without a context, that, for me at least, is missing. (Personally, I think of it [without context] as overrated, even at -1.)
Well, sending spent fuel into orbit isn't a bad idea, but it should be enclosed in a thermionic generator when you do it. You don't need Plutonium for that if you don't want to use a minimal weight for a long period of time. If;you're willing to use a bit more weight, or run out of power a bit sooner, there are lots of other choices.
But it's the "umberella" part that I don't trust. You can't get the handle without getting the ribs, too. And sometimes all I want is a small part of the handle.
That the terminal manager is spun off from the kernel is fine. That it becomes another reason to install systemd is terrible. There are too many interconnected dependencies.
Encasing it in glass ingots doesn't waste it, it merely makes it a bit more difficult to access when you come up with a good use for it...but it keeps it relatively safe until you do.
Burying it at the bottom of a subduction trench, now, that's wasting it.
Geosync orbit is a bad idea. That orbit is very useful for other purposes and already a bit crowded.
OTOH, it wouldn't need to be *very* much higher to be much more reasonable...but be sure to put it all in one place. You don't want even more junk spread around.
Well, I'm a current Debian user, and I switched from testing to stable because of problems with systemd. OTOH, there's a good reason that it's called testing.
Still, while I don't hate systemd, I also don't trust it. My current intention is to remain on stable while things shake themselves out, and then decide what to do. And the Devuan timeline doesn't show it being available even as a "testing" distribution until next spring. (I gather the current version is sort of a compromise between prototype and unstable[sid], or even experimental.)
By the time I need to decide, I expect I'll know how things are going to shake out. But I expect that I'll be keeping an eye on Devuan, and a few others. And perhaps systemd won't be as bad as I expect. Still, any init system that marks problems with its logging system as "won't fix" is dubious. That the main logging system is binary just makes things much worse. So does expansions like having the "init system" include things like terminal manager, etc. It even makes me tempted to go back to Etch (yah, that's a rediculuous thing to suggest, as the current stable works fine without systemd).
Another problem is that it's based on the fallacy that economics is a zero-sum game. And that physical money is a good analog of financial money. Both are false.
Another assumption is that feeding the starving is a reasonable approach. But population growth is exponential until a limiting factor is reached, and exponential growth cannot be sustained. Ever. So if you plan to "feed the starving multitude" you'd better have some plan in mind to feed twice that number of people in 20 years.
Personally, I think we are already beyond the sustainable capacity of the planet. We're emptying the seas of fish and the land of anything we can't eat. At some point we're going to crash, and crash badly. It would be highly deisreable if at that point there were some self-sufficient colonies elsewhere. But we are, to be optomistic, decades away from being able to do that.
Your point, while partially valid, is nevertheless misguided. ALL viruses are specialist parasites. What you need to "infect" a planet with life is something like a lichen, bacteria, or plant.
FWIW, if you have enough energy then synthetic gasoline can be manufactured. It's not the most efficient of processes, however. Using it for fuel would probably be unwise. (I think electric cars would work out better.) But you can also build lubricants.
Mind you, this process doesn't sound efficient enough to make the process practical.
Slashdot Mirror
The link to the repo was NOT reported as being the link to .NET Core, but to a set of libraries that could be used with it. This makes it irrelevant unless I decide to use Mono.
To what does that license refer?
Sorry, but when I checked the article I didn't see anything about the release of .NET core under any particular license. There was a link to GitHub where they had released some libraries, to which I presume your response applies, though I'm not sure. (Yes, I could have checked that, but I didn't, and don't intend to unless it becomes important. It's basically irrelevant unless I adopt the approach, and if I do I'll probably get the code from a standard system repository. I'm not a lawyer, and don't like playing lawyer games. The article didn't say what the license was, so I presume that there's something unexpected going on, even if I don't know what.)
I had assumed that:
meant that the go compiler was basically a "byte-code compiler", and that this code was run through an interpreter.
By "byte-code compiler" I actually mean it was used to generate a bunch of calls to library routines that did the actual work. I wasn't actually presuming that the op-codes were single bytes, as I consider that irrelevant.
The claim that "it runs as fast as C" is one that I've heard most interpreted languages since Java make, so I pretty much ignored it. I did note that they considered the LLVM to be too slow, but I interpreted this as meaning they build a customized virtual machine.
OTOH, the gcc version of go does compile to machine code, so there's nothing inherently improbable in it actually compiling to machine code. That's just not the way I read things. (I also think of Java as an interpreted language, and Python, and Ruby...though at least in the case of Java and Python the more technically correct phraseology is that they are compiled to a virtual machine.)
For that matter one could say that UCSD Pascal was compiled to a virtual machine, but it was always called an interpreted language.
I haven't looked at it often, but it the last time I looked it still looked the same. However the real problem is the documentation.
What's the license?
Sorry, eventually I may consider .NET, now that it's officially been opened, but I'll need to see how the community development goes. If nobody but MS can touch it, I won't trust it.
FWIW, even though Java is mainly FOSS licensed, I don't trust it, and that's BECAUSE Oracle is such a bastard. Suing over API interface identity? Sorry, but how can I trust you? I know they lost the suit (at one level...did they appeal?), but that they would even consider it makes me dubious about them. OTOH, the GPL is pretty strong, so I still feel reasonably comfortable with the parts of Java that are covered by the GPL. But if I were to publish I'd generate the documentation with Doxygen rather than javadoc.
As for .NET ... I'll wait and see how it develops. In some ways C# looks interresting, but nothing dramatic, and I don't develop for the web, so... What's in it for me?
Sounds more like linked-in got hacked, and this hack could be used to sign into Slashdot.
Have you read the bit about "Concurrency is not MultiProcessing" (or something that means the same thing). Go is a single threaded language, which is concurrent but not multiprocessing. So there's basically no payoff in many cases from using it, and you've got to run it through an interpreter (unless you use the gcc version).
So why bother?
The problem with Objective-C is its libraries. Nobody has put much work into the cross-platform ones for a decade, and it shows. And since I don't use Apple, Cocoa is of no interest to me, but all the documentation refers to it. So I ignore Objectve C.
I find it a very interesting language that's hobbled by lack of usable documentation. (Even for cross-platform stuff I got redireected to the Apple site.)
So you claim you could implement a B+Tree in Whitespace? BrainFuck?
Sorry, but different languages have different strengths, otherwise we'd all be programming in TML (Turing Machine Language). I could have said assembler, or machine language, but both of those are easier to use.
OTOH, I'll admit that I tend to flit from language to language more than is necessary, and I've still skipped some, like Haskell and CaML. Sometimes a language doesn't look like it would make anything I'm doing easier.
OTOH, I once did list processing in Fortran IV. You can do nearly anything in any common language...but some things are easier to do in some languages than in others. I'd never even try to write a B+Tree in Snobol. You could do it (though the interpreter might choke), but it's obviously the wrong tool for the job.
No, no. The police are SOME of the terrorists. There do exist terrorists who are not police.
Well, I don't have much evidence, but if batteries had been half the cost I would have gotten twice as many solar cells, enough batteries, and cut loose from the grid. Anecdote is not data, but that's what I would have done. As it was I figured the benefit wasn't worth the cost, and only got enough solar cells to bring our power use below the threshold where there's a rate increase.
FWIW, I don't think this is the use case that utilities are worried about. What they're worried about is people still on the grid who generate power irregularly, and thus destabilize the network.
Do note, however, that I live in a city. If I lived in a rural area power independence would have been much more valuable. (Where I live power outages are very rarely more than an hour.)
Even typo changes need justification because, as you remarked, "These 'trivial' changes often cause merge conflicts with other trees."
As for this kind of change...if its a real issue, then there needs to be a policy, e.g., "always avoid the singular they". (Personally I often use it, if I remember to. But it sure isn't what I was taught in school. Still, I find it much better than "s/he", though in some contexts I'll use "s/he/it".)
The problem is that as technological capabilities increase, so do the capabilites for destructive action, until you reach to point where a small group possesses the capability to destroy the entire civilization. Since there are a LOT more small groups than large groups, that means you need an ever increasing amount of stability if you are going to survive. We've already had some extremely close calls, and for us a small group (was) still the size of the US or Russia. These days we're approaching the point where a small group is the size of Turkey. In a decade or so it might be down to the size of North Korea. At some point, some small group headed by someone too unhappy with the current social system will decide to do a Samson act and pull down the temple. So by one projection our maximum expected life as a technological civilization is less than an additional century. And I left out the effect of accidents, or "AprÃs moi, le déluge" (though Lois didn't intend that as a result, some people would).
Well, it's snarky, but this time I think xkcd is stupid...though more informed than most people.
It's not an equation that tells you what the answers are, it's an equation that lists your areas of uncertainty. Nobody has come up with a better approach (unless you claim "I don't care" is a better approach). And yes, the areas that are unknown are pretty big, which is good. My suspicion is that if they were better known it would be a very depressing equation. The most obvious simultaneous solution to the Fermi Problem and the Drake Equation is that the lifetime of a technological civilization is quite short.
If you assume the lifespan of a technological civilization is not infintie, you could probably work the Birthday paradox in. It's not exactly a "modulo", but its related.
(That said, I don't see it. Just because I think you could probably work it in doesn't mean I find it at all obvious.)
What idiot modded thie parent offtopic? I could see flamebait, or even, vaguely, troll, but offtopic?
OTOH, I don't see it as particularly useful. Not without a context, that, for me at least, is missing. (Personally, I think of it [without context] as overrated, even at -1.)
Well, sending spent fuel into orbit isn't a bad idea, but it should be enclosed in a thermionic generator when you do it. You don't need Plutonium for that if you don't want to use a minimal weight for a long period of time. If ;you're willing to use a bit more weight, or run out of power a bit sooner, there are lots of other choices.
But it's the "umberella" part that I don't trust. You can't get the handle without getting the ribs, too. And sometimes all I want is a small part of the handle.
That the terminal manager is spun off from the kernel is fine. That it becomes another reason to install systemd is terrible. There are too many interconnected dependencies.
Encasing it in glass ingots doesn't waste it, it merely makes it a bit more difficult to access when you come up with a good use for it...but it keeps it relatively safe until you do.
Burying it at the bottom of a subduction trench, now, that's wasting it.
Geosync orbit is a bad idea. That orbit is very useful for other purposes and already a bit crowded.
OTOH, it wouldn't need to be *very* much higher to be much more reasonable...but be sure to put it all in one place. You don't want even more junk spread around.
Well, I'm a current Debian user, and I switched from testing to stable because of problems with systemd. OTOH, there's a good reason that it's called testing.
Still, while I don't hate systemd, I also don't trust it. My current intention is to remain on stable while things shake themselves out, and then decide what to do. And the Devuan timeline doesn't show it being available even as a "testing" distribution until next spring. (I gather the current version is sort of a compromise between prototype and unstable[sid], or even experimental.)
By the time I need to decide, I expect I'll know how things are going to shake out. But I expect that I'll be keeping an eye on Devuan, and a few others. And perhaps systemd won't be as bad as I expect. Still, any init system that marks problems with its logging system as "won't fix" is dubious. That the main logging system is binary just makes things much worse. So does expansions like having the "init system" include things like terminal manager, etc. It even makes me tempted to go back to Etch (yah, that's a rediculuous thing to suggest, as the current stable works fine without systemd).
Another problem is that it's based on the fallacy that economics is a zero-sum game. And that physical money is a good analog of financial money. Both are false.
Another assumption is that feeding the starving is a reasonable approach. But population growth is exponential until a limiting factor is reached, and exponential growth cannot be sustained. Ever. So if you plan to "feed the starving multitude" you'd better have some plan in mind to feed twice that number of people in 20 years.
Personally, I think we are already beyond the sustainable capacity of the planet. We're emptying the seas of fish and the land of anything we can't eat. At some point we're going to crash, and crash badly. It would be highly deisreable if at that point there were some self-sufficient colonies elsewhere. But we are, to be optomistic, decades away from being able to do that.
Your point, while partially valid, is nevertheless misguided. ALL viruses are specialist parasites. What you need to "infect" a planet with life is something like a lichen, bacteria, or plant.
FWIW, if you have enough energy then synthetic gasoline can be manufactured. It's not the most efficient of processes, however. Using it for fuel would probably be unwise. (I think electric cars would work out better.) But you can also build lubricants.
Mind you, this process doesn't sound efficient enough to make the process practical.
Unfortunately, she wasn't a do nothing. A do nothing would have been a VAST improvement. I'm usually in favor of King Log over King Stork.