So the won't have to get rid of all their animals, and people, who breathe out the stuff. And their forests and other plant life gets to live, since they breathe in the stuff.
Some enterprising soul must have taught them biology since their last announcement...
For a long time the US postal service has been losing money, they posted a 5.6 billion loss in 2016.
There are three main reasons for them posting a loss:
1. They are the only division of the federal government required to fully fund their pension plan, rather than switching to a "cash balance" plan.
2. They are the only division of the federal government required to fully fund their medical plan, called "Mail Handler's Benefits Program". This is because they have to accept all federal employees who want to enroll in it (rather than private insurance offered in their own division). This is also the medical plan for all members of congress and their dependents.
3. Their bulk mail delivery operates at a negotiated loss. Which wouldn't be a problem, had the Direct Marketing Association not turned around, and turned all the flyers that used to be sent separately into one "coupon brochure" by making an outside "wrapper" page that folds in half, and the other pieces go inside it. Including things like the Trader Joe's Catalog that comes once a month or so.
So yes, they are posting a loss, because the DMA intermediated between them and the flyer senders to take all the profit, while leaving the post office to do the deliver... on one piece.
The fix is to raise their bulk rates -- which they are prohibited from doing.
And yes, I admit to having broken into some U.S. Air Force computers just to look around, back before there were "criminal trespass" laws, and it became illegal as hell to "go in and look".
Perhaps you'd have more security experts available, if they'd already leaned to think like a grey hat by doing.
You really have to think somewhat sideways or slantwise in order to know how to look for security holes, so that you can then plug them. Because most holes are in the gaps between what systems are intended to do, and what you can actually make them do instead.
Compare something that's on a traditional network that people actually watch. Empire is not it. If you pick something people actually watch, then people will probably recognize it.
For example, I know AMC does "The Walking Dead", because it always starts out "Last time, on AMC's The walking Dead...". I know CW does iZombie.
Yes, I watch stuff other than zombie content, it's just I thought of those two first. SyFy does Dark Matter, for example.
This was a solution in search of a problem. The problem in theory being "downloading precompiled binaries" like linux rpm's.
The actual problem that NaCl was originally sold to address was the ability to put video decoding and other expensive operations into native code. In other words, it was the equivalent of a JNI escape to native code.
There are performance reasons for this, but the primary one is video distribution with DRM and/or forced interposition of commercials, as a revenue model.
One of the examples they used to demo it was adding "native" mathematics package to the JavaScript in the browser to vaslty accelerate math operations by adding JavaScript verbs to access the added native code.
P.S.:
I agree that WebAssembly is a nuclear bomb, just waiting to go off. There's no way the JIT'ed code and the JavaScript code for the same site aren't running in the same DOM sandbox process.
What this basically means is there's an ability to use code to exploit other (presumably "safed during interning") code.
It's not like we are running on Harvard Architecture computers here.
Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).
Incorrect. The PNaCl (and NaCl) attack surface was intermediated by what a web site was permitted to do through JavaScript.
It would have been substantially more useful, and dangerous, had that not been the case.
The question is whether the JIT'ed code in WebAssembly is going to be smarter about sandboxing than Crome itself currently is (I don't see how that can be the case; there are already OnClick based persistent DOM's that are created by malicious sites to pop up advertisements -- and they defeat the sandbox by setting up timers to allow a cross-DOM attack through a URL rewrite hijack.
You can see these things everywhere, if you go to pirate video sites in order to determine what's going on.
But it's basically at that point a "windowless DOM" that just sits around as a "Google Chrome Helper" process.
Enough websites do this accidentally ("Leaking of DOMS") that you periodically have to either kill off all the helper processes, or you have to restart Chrome to get rid of the things. It's very annoying, in fact, on limited memory systems.
My expectation here is low, because I've so far been singularly unimpressed with the Android capability permissions model, and it's inability to prevent Android malware. I can't see anything they point in place (at least without a DKIM-like system utilizing DNS) being any better than what they've achieved with Android.
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
I feel like this is a stupid question, so this is probably over my head, but why is a bytecode interpreter worse on this front than an a compiler likewise accepting arbitrary code from the Internet?
The issue is the ability to create outbound connections/not/ through WebSockets, and the ability to interpose and modify code on its way down.
The advantage of WebSockets is that it has to connect to a server on the site where the script originated, in order to make an outbound socket connection. This makes it difficult to make a self-propagating attack vector, or a SPAM engine hidden in a game, and utilizing your outbound connection in order to relay SPAM in such a way as to distribute a SPAM engine, or a DDOS to a lot of machines.
So, for example, you can utilize Java to engage in this type of attack with relative impunity.
It's possible to make this "safer", but the primary argument of "better security" is entirely the argument in favor of Java: great security model in theory, but in practice, it tends to be a pretty horrible security model altogether.
I expect that they are going to end up adding the sort of "call filtering" that happens in the sandboxing that Apple implements in order to sandbox applications within the OS itself.
The problem with doing this in the WebAssembly case -- and the Java case -- is that the "capabilities requirements list" and the "application payload" come from the same source.
This opens you up to malicious sources -- I expect the primary one will be pirate video content, of the same sort which now, as an attack, requests that the user "update their Flash player" or "You must install this codec to access this content...download now?". People will permit it for the same reasons they permit those attacks on their systems: they want to access the content.
Again, however, we are gifted also with the ability for an attack on a single site, or an attack on a single gatekeeper, as an intermediary, to alter the code intermediate to it being delivered to the machine.
This is, by the way, the same way the recently revealed NSA SMB intermediation download attack operates.
So it opens up a pretty common attack surface, compared to NaCl/PNaCl.
I understand why they're doing it -- removing the PNaCl back end gives them room to jam in the WebAssembly JIT, rather than having to carry around twice as much code to get what (they incorrectly believe) is equivalent functionality. Essentially, they can do the same things without changing the code size. Only they can do more than the same things. And the bad guys can also do more than the same things.
I think it's going to therefore end up being a big mistake.
Americans have free speech in the US but, shockingly, US laws are not universal... the instant you set foot to another country you better realise a completely different set of protections (or lack of them) applies.
Simple solution...
If you don't like what's being said in the U.S., don't connect to our servers and download it.
Problem solved.
I think China has some technology you can license, if you need help with this.
I could get behind a "last mile" access rights law, however, with mandatory slots for at least 20 competitors.
Bandwidth is not limited in the way it is charged, either.
Specifically, an idle router takes no more electricity than a router operating at it's maximum rated capacity. Yet we get charged more for more use, even when there is idle capacity, rather than the capacity being fairly apportioned between subscribers.
This is primarily due to "oversubscription", which is a code word for "we're selling more bandwidth than we provide, because we expect you to consume content, rather than producing it".
This idiocy is "enforced" by charging for bandwidth above a certain utilization as if it were gold. In other words: it's a bad model propped up by an economic model which benefits the people who want to be paid for packets, rather than being paid for having a "dumb pipe" that they provide. They do not want to be commoditized down to "dumb pipe" status.
What my suggestion does is commoditize bandwidth from the CISCO unit(s) in the basement of the apartment complex utility room into "dumb pipe" status. IF it's done city-wide, then everything's a "dumb pipe".
This is precisely the situation which ISPs want to avoid, because it means they are also "dumb pipes", and thus a commodity.
They have been shitting themselves ever since we moved from circuit-switched communications hardware to packet switched hardware, trying to maintain the "long distance metered rate teat" that they had been feeding off of since the early days of telecom.
The 100+ yr old telecom wiring leases need to stop. Getting repaid over and over for something put in the ground 20 yrs ago is vile.
Which is precisely what I suggested, only somehow you aren't stupid, but choose to call me stupid. City owns the infrastructure, ISP owns the packets. Customer gets to pick who does or does not send them packets.
No matter who sends the packets: the "dumb pipes" are there, and the "dumb pipe" diameter remains the same -- and thus capacity remains the same. You want bigger "dumb pipes"? Pay more taxes.
"WebAssembly" is a virtual machine; it might as well be named "JVM".
PNaCl pushed down partially compiled code so that a compiler backend could localize it to Native code on the local machine. It used LLVM IMF (effectively) to implement ANDF -- Architecture Neutral Distribution Format, which was a promise Apple was never able to achieve -- which is why Apple has "Fat Binaries": single binaries with multiple images.
NaCl, by contrast, targeted a specific binary instruction set in the target, and people would use different wrappers for the actual code itself, via JavaScript, to select the architecture (ARM, x86, etc.) of the actual binaries being downloaded in NaCl form.
The question is whether you do the finalization work on the sender, or the receiver. Both systems, however, had as their primary intent the ability to extend JaveScript with native code plugins.
In the absolute limit, you'd write all your code in native code, and then ship it down with a small JavaScript shim, in order to call into that code's "main" with a thread context, and set it running as native code.
There are a number of Games which did this, and there's a (moderately common) use of NaCl to push down x86 games running in a PC emulator as a packaged lump in NaCl.
PNaCl -- which was platform independent -- and NaCl, which I would say has arguably failed as well -- failed because it was massively difficult to develop applications in it.
This is predominantly because there is insufficient glue code and no IDL in order to define JavaScript interfaces which also described C/C++ code containers for the compilers used to generate the native code on the front end.
This made it impractical to have what is -- in essence -- a browser-level jandboxed "JNI" equivalent for JavaScript.
So people simply didn't use it.
In other words, it was not a complete product, and like Mozilla in the early days, it was nearly impossible to build anything useful out of it that actually did anything that had any impact on anything.
NaCl -- apparently not (yet) deprecated -- still has this problem.
Think of it as having DCE or Sun RPC available as an interface between JavaScript and native code, and having no "rpcgen" and no "xdr" library available to use.
This is pretty typical of some Google products: they go 80% of the way there, and then, because they are organizationally not motivated to do things which are difficult -- because you can pretty much walk to any other job inside Google, should your manager ask you to do something you considered "unfun" -- no one finishes the remaining 20%.
I tried to resolve this in my 20% time at Google, but was rather constantly thwarted in the effort (the 20% time at Google is largely mythical) by providing an IDL in XML that would let you describe the interfaces, and then generate the JavaScript templates on one end, and the C code containers for the functions that needed to be written on the other, along with an "XDR" library for marshaling arbitrary data back and forth between the "C form" and the "externalized JavaScript" form.
Sadly, this project never came to fruition -- I was even, stupidly was writing it in Python, to make it politically acceptable to the people who were complaining the loudest, when I could have cranked it out in C in a couple of days -- Python is really slow/bad at XML, among other problem.
Personally, I think this deprecation and switch is a terrible idea.
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
WebAssembly is exactly that, only renamed from "Java", and not uninstallable or turn-offable.
Massively bad mistake.
The only saving grace is that I have no doubt that it will be "about as popular as NaCl/PNaCl", and it'll stop at 80% of the way to "people are now likely to use this thing to do their projects".
Yes, they are sandboxed, but they are sandboxed by constraining the assembly language generated.
PNaCl differs only in that it sends the intermediate compiled code down to the browser to be processed in the final LLVM stage backend into assembly language within the browser.
The major reason for deprecating it is that a compiler back end is a lot to carry around for little benefit.
The reason the benefit is small, however, has less to do with PNaCl itself, and a lot more to do with how Google handles projects within Google, and my inability to actually pry my 20% time -- that I was promised when I was hired -- out of Google to do work on the problem.
Have the city/county own the links, and have the ISP's offer service over the municipal infrastructure.
You want email? Talk to an ISP. You want television? Talk to an ISP. You want VOIP service? Talk to an ISP.
All ISP's have equal access to the market over the common infrastructure.
I should be able to live in Alaska, get my phone service from Utah, get my email from Virginia, and get my television channels from 6 or 7 places, unbundled.
Ha. Hahahaha. Hahaha. Ha. If you think teaching the very young is about reading, or math, or really any of the "educational" subjects you are sorely misled. Early education is primarily about social learning. Teaching little humans how to treat other little humans so they don't become TERRIBLE humans later in life
Honestly, I don't know what creche you were birthed in, #1577213.
Before creches, however, we used to have these things called "parents" whose job it was to teach children to be decent human beings.
Children only went to school to learn about reading, math, and any of the other "educational" subjects which were delegated to the schools.
"Social learning" was generally handled either by "siblings" or by "Go play the fuck outside with the neighborhood kids, I'm trying to make dinner here!".
I have to say: I'm already regretting the switch to "creche based child rearing"...
The problem is that it's impossible to get a job without a college degree. You can't expect genius level IQ from everyone.
I don't.
I only expect it from people who are not destined to ask "Would you like fries with that?".
We have more people than we need to produce everything we consume. Education is a force multiplier, automation is a force multiplier, and technology is a force multiplier.
Eventually, there will be one guy named "Bob" in Newark, New Jersey. It will be his job to roll out of bed on Monday, and press the button that tells the robots "Please don't shut down, the planet still has human occupants".
Slashdot Mirror
Yes. Prior to 1984.
Did you know Minuteman Missile launch control computers were basically IBM 360's with an additional "fine countdown mode" instruction?
Well, this significantly beats the previous plan.
Carbon Neutral means they still plan to emit it.
So the won't have to get rid of all their animals, and people, who breathe out the stuff.
And their forests and other plant life gets to live, since they breathe in the stuff.
Some enterprising soul must have taught them biology since their last announcement...
For a long time the US postal service has been losing money, they posted a 5.6 billion loss in 2016.
There are three main reasons for them posting a loss:
1. They are the only division of the federal government required to fully fund their pension plan, rather than switching to a "cash balance" plan.
2. They are the only division of the federal government required to fully fund their medical plan, called "Mail Handler's Benefits Program". This is because they have to accept all federal employees who want to enroll in it (rather than private insurance offered in their own division). This is also the medical plan for all members of congress and their dependents.
3. Their bulk mail delivery operates at a negotiated loss. Which wouldn't be a problem, had the Direct Marketing Association not turned around, and turned all the flyers that used to be sent separately into one "coupon brochure" by making an outside "wrapper" page that folds in half, and the other pieces go inside it. Including things like the Trader Joe's Catalog that comes once a month or so.
So yes, they are posting a loss, because the DMA intermediated between them and the flyer senders to take all the profit, while leaving the post office to do the deliver ... on one piece.
The fix is to raise their bulk rates -- which they are prohibited from doing.
Does it involve "arresting extremists"?
I understand you are not allowed access to computers in jail. Kind of makes it hard to create a throw-away account and post an extremist video.
By the way, where are all these extremists coming from; is there a factory somewhere? Maybe we can just shut that down...
Before a white hat, you have to be a grey hat.
However this is all highly illegal these days.
And yes, I admit to having broken into some U.S. Air Force computers just to look around, back before there were "criminal trespass" laws, and it became illegal as hell to "go in and look".
Perhaps you'd have more security experts available, if they'd already leaned to think like a grey hat by doing.
You really have to think somewhat sideways or slantwise in order to know how to look for security holes, so that you can then plug them. Because most holes are in the gaps between what systems are intended to do, and what you can actually make them do instead.
Why is the retailer responsible for what the parent/child will do?
For the same reason they are responsible for cigarette sales to people under 18 or liquor sales to people under 21.
It's an easy enforcement point.
That would encompass even the dumbest phone from 10 years ago.
So Blackberry's?
If I don't watch a show you can ask all you want.
I'll even pray to Zombie Jesus, if you think it'll help, but there's no way I'm going to be able to tell you the network for a show I never watch.
To do this correctly, they'd need to have a two phase question set:
1. What shows do you watch regularly? "X, Y, Z"
2. What network is X on? Y on? Z on?
As implemented, the survey is statistically crap.
"The FAA has rules and regulations in place to prevent this exact type of incident from happening,"
Well, it looks like they work great.
Good job, FAA! Keep up the good work on those regulations! Glad they prevented this mishap!
We should regulate against heart attacks next! Think of the lives that it will save!
Don't compare Jessica Jones and Empire.
Compare something that's on a traditional network that people actually watch. Empire is not it. If you pick something people actually watch, then people will probably recognize it.
For example, I know AMC does "The Walking Dead", because it always starts out "Last time, on AMC's The walking Dead...". I know CW does iZombie.
Yes, I watch stuff other than zombie content, it's just I thought of those two first. SyFy does Dark Matter, for example.
Not quite how I remember Henry Spencer.
On the other hand, he did do the getopt thing. His regex thing was far, far, far more important. Also: Perl, anyone?
Henry was an important, important person around that time. So was UToronto. Too bad UToronto kinda bailed on us all at the time of the BSD lawsuits.
Hi Henry; still alive. Yourself? ;^)
The problem is that NaCl exists.
This was a solution in search of a problem. The problem in theory being "downloading precompiled binaries" like linux rpm's.
The actual problem that NaCl was originally sold to address was the ability to put video decoding and other expensive operations into native code. In other words, it was the equivalent of a JNI escape to native code.
There are performance reasons for this, but the primary one is video distribution with DRM and/or forced interposition of commercials, as a revenue model.
One of the examples they used to demo it was adding "native" mathematics package to the JavaScript in the browser to vaslty accelerate math operations by adding JavaScript verbs to access the added native code.
P.S.:
I agree that WebAssembly is a nuclear bomb, just waiting to go off. There's no way the JIT'ed code and the JavaScript code for the same site aren't running in the same DOM sandbox process.
What this basically means is there's an ability to use code to exploit other (presumably "safed during interning") code.
It's not like we are running on Harvard Architecture computers here.
I think the only people who care about this are Mozilla, Inc..
Are you claiming that this is going to also be implemented in Safari or Microsoft Edge (the only othe browsers that matter)?
Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).
Incorrect. The PNaCl (and NaCl) attack surface was intermediated by what a web site was permitted to do through JavaScript.
It would have been substantially more useful, and dangerous, had that not been the case.
The question is whether the JIT'ed code in WebAssembly is going to be smarter about sandboxing than Crome itself currently is (I don't see how that can be the case; there are already OnClick based persistent DOM's that are created by malicious sites to pop up advertisements -- and they defeat the sandbox by setting up timers to allow a cross-DOM attack through a URL rewrite hijack.
You can see these things everywhere, if you go to pirate video sites in order to determine what's going on.
But it's basically at that point a "windowless DOM" that just sits around as a "Google Chrome Helper" process.
Enough websites do this accidentally ("Leaking of DOMS") that you periodically have to either kill off all the helper processes, or you have to restart Chrome to get rid of the things. It's very annoying, in fact, on limited memory systems.
My expectation here is low, because I've so far been singularly unimpressed with the Android capability permissions model, and it's inability to prevent Android malware. I can't see anything they point in place (at least without a DKIM-like system utilizing DNS) being any better than what they've achieved with Android.
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
I feel like this is a stupid question, so this is probably over my head, but why is a bytecode interpreter worse on this front than an a compiler likewise accepting arbitrary code from the Internet?
The issue is the ability to create outbound connections /not/ through WebSockets, and the ability to interpose and modify code on its way down.
The advantage of WebSockets is that it has to connect to a server on the site where the script originated, in order to make an outbound socket connection. This makes it difficult to make a self-propagating attack vector, or a SPAM engine hidden in a game, and utilizing your outbound connection in order to relay SPAM in such a way as to distribute a SPAM engine, or a DDOS to a lot of machines.
So, for example, you can utilize Java to engage in this type of attack with relative impunity.
It's possible to make this "safer", but the primary argument of "better security" is entirely the argument in favor of Java: great security model in theory, but in practice, it tends to be a pretty horrible security model altogether.
I expect that they are going to end up adding the sort of "call filtering" that happens in the sandboxing that Apple implements in order to sandbox applications within the OS itself.
The problem with doing this in the WebAssembly case -- and the Java case -- is that the "capabilities requirements list" and the "application payload" come from the same source.
This opens you up to malicious sources -- I expect the primary one will be pirate video content, of the same sort which now, as an attack, requests that the user "update their Flash player" or "You must install this codec to access this content ...download now?". People will permit it for the same reasons they permit those attacks on their systems: they want to access the content.
Again, however, we are gifted also with the ability for an attack on a single site, or an attack on a single gatekeeper, as an intermediary, to alter the code intermediate to it being delivered to the machine.
This is, by the way, the same way the recently revealed NSA SMB intermediation download attack operates.
So it opens up a pretty common attack surface, compared to NaCl/PNaCl.
I understand why they're doing it -- removing the PNaCl back end gives them room to jam in the WebAssembly JIT, rather than having to carry around twice as much code to get what (they incorrectly believe) is equivalent functionality. Essentially, they can do the same things without changing the code size. Only they can do more than the same things. And the bad guys can also do more than the same things.
I think it's going to therefore end up being a big mistake.
Americans have free speech in the US but, shockingly, US laws are not universal... the instant you set foot to another country you better realise a completely different set of protections (or lack of them) applies.
Simple solution...
If you don't like what's being said in the U.S., don't connect to our servers and download it.
Problem solved.
I think China has some technology you can license, if you need help with this.
Bandwidth is not unlimited everywhere.
I could get behind a "last mile" access rights law, however, with mandatory slots for at least 20 competitors.
Bandwidth is not limited in the way it is charged, either.
Specifically, an idle router takes no more electricity than a router operating at it's maximum rated capacity. Yet we get charged more for more use, even when there is idle capacity, rather than the capacity being fairly apportioned between subscribers.
This is primarily due to "oversubscription", which is a code word for "we're selling more bandwidth than we provide, because we expect you to consume content, rather than producing it".
This idiocy is "enforced" by charging for bandwidth above a certain utilization as if it were gold. In other words: it's a bad model propped up by an economic model which benefits the people who want to be paid for packets, rather than being paid for having a "dumb pipe" that they provide. They do not want to be commoditized down to "dumb pipe" status.
What my suggestion does is commoditize bandwidth from the CISCO unit(s) in the basement of the apartment complex utility room into "dumb pipe" status. IF it's done city-wide, then everything's a "dumb pipe".
This is precisely the situation which ISPs want to avoid, because it means they are also "dumb pipes", and thus a commodity.
They have been shitting themselves ever since we moved from circuit-switched communications hardware to packet switched hardware, trying to maintain the "long distance metered rate teat" that they had been feeding off of since the early days of telecom.
The 100+ yr old telecom wiring leases need to stop. Getting repaid over and over for something put in the ground 20 yrs ago is vile.
Which is precisely what I suggested, only somehow you aren't stupid, but choose to call me stupid. City owns the infrastructure, ISP owns the packets. Customer gets to pick who does or does not send them packets.
No matter who sends the packets: the "dumb pipes" are there, and the "dumb pipe" diameter remains the same -- and thus capacity remains the same. You want bigger "dumb pipes"? Pay more taxes.
The demise of PNaCl is really unfortunate.
"WebAssembly" is a virtual machine; it might as well be named "JVM".
PNaCl pushed down partially compiled code so that a compiler backend could localize it to Native code on the local machine. It used LLVM IMF (effectively) to implement ANDF -- Architecture Neutral Distribution Format, which was a promise Apple was never able to achieve -- which is why Apple has "Fat Binaries": single binaries with multiple images.
NaCl, by contrast, targeted a specific binary instruction set in the target, and people would use different wrappers for the actual code itself, via JavaScript, to select the architecture (ARM, x86, etc.) of the actual binaries being downloaded in NaCl form.
The question is whether you do the finalization work on the sender, or the receiver. Both systems, however, had as their primary intent the ability to extend JaveScript with native code plugins.
In the absolute limit, you'd write all your code in native code, and then ship it down with a small JavaScript shim, in order to call into that code's "main" with a thread context, and set it running as native code.
There are a number of Games which did this, and there's a (moderately common) use of NaCl to push down x86 games running in a PC emulator as a packaged lump in NaCl.
PNaCl -- which was platform independent -- and NaCl, which I would say has arguably failed as well -- failed because it was massively difficult to develop applications in it.
This is predominantly because there is insufficient glue code and no IDL in order to define JavaScript interfaces which also described C/C++ code containers for the compilers used to generate the native code on the front end.
This made it impractical to have what is -- in essence -- a browser-level jandboxed "JNI" equivalent for JavaScript.
So people simply didn't use it.
In other words, it was not a complete product, and like Mozilla in the early days, it was nearly impossible to build anything useful out of it that actually did anything that had any impact on anything.
NaCl -- apparently not (yet) deprecated -- still has this problem.
Think of it as having DCE or Sun RPC available as an interface between JavaScript and native code, and having no "rpcgen" and no "xdr" library available to use.
This is pretty typical of some Google products: they go 80% of the way there, and then, because they are organizationally not motivated to do things which are difficult -- because you can pretty much walk to any other job inside Google, should your manager ask you to do something you considered "unfun" -- no one finishes the remaining 20%.
I tried to resolve this in my 20% time at Google, but was rather constantly thwarted in the effort (the 20% time at Google is largely mythical) by providing an IDL in XML that would let you describe the interfaces, and then generate the JavaScript templates on one end, and the C code containers for the functions that needed to be written on the other, along with an "XDR" library for marshaling arbitrary data back and forth between the "C form" and the "externalized JavaScript" form.
Sadly, this project never came to fruition -- I was even, stupidly was writing it in Python, to make it politically acceptable to the people who were complaining the loudest, when I could have cranked it out in C in a couple of days -- Python is really slow/bad at XML, among other problem.
Personally, I think this deprecation and switch is a terrible idea.
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
WebAssembly is exactly that, only renamed from "Java", and not uninstallable or turn-offable.
Massively bad mistake.
The only saving grace is that I have no doubt that it will be "about as popular as NaCl/PNaCl", and it'll stop at 80% of the way to "people are now likely to use this thing to do their projects".
PNaCl and NaCl are *not* virtual machines!
Yes, they are sandboxed, but they are sandboxed by constraining the assembly language generated.
PNaCl differs only in that it sends the intermediate compiled code down to the browser to be processed in the final LLVM stage backend into assembly language within the browser.
The major reason for deprecating it is that a compiler back end is a lot to carry around for little benefit.
The reason the benefit is small, however, has less to do with PNaCl itself, and a lot more to do with how Google handles projects within Google, and my inability to actually pry my 20% time -- that I was promised when I was hired -- out of Google to do work on the problem.
I talk about it in another post.
This is really easy to solve.
Have the city/county own the links, and have the ISP's offer service over the municipal infrastructure.
You want email? Talk to an ISP. You want television? Talk to an ISP. You want VOIP service? Talk to an ISP.
All ISP's have equal access to the market over the common infrastructure.
I should be able to live in Alaska, get my phone service from Utah, get my email from Virginia, and get my television channels from 6 or 7 places, unbundled.
Who wrote the C version while converting the game from 32 bit to 24 bit Hollerith code on a Harris H-800 at Weber State University n the 1980's.
P.S.: It was Open Source when I did that; it had been declared public domain.
P.P.S.: Public domain is better than a freaking license.
Ha. Hahahaha. Hahaha. Ha. If you think teaching the very young is about reading, or math, or really any of the "educational" subjects you are sorely misled. Early education is primarily about social learning. Teaching little humans how to treat other little humans so they don't become TERRIBLE humans later in life
Honestly, I don't know what creche you were birthed in, #1577213.
Before creches, however, we used to have these things called "parents" whose job it was to teach children to be decent human beings.
Children only went to school to learn about reading, math, and any of the other "educational" subjects which were delegated to the schools.
"Social learning" was generally handled either by "siblings" or by "Go play the fuck outside with the neighborhood kids, I'm trying to make dinner here!".
I have to say: I'm already regretting the switch to "creche based child rearing"...
Then by that same token, I "care" about people's mental health being impacted by having something to keep them occupied.
I just don't "care" (your other definition) to force other people to provide them with what they need to help them with that -- i.e. jobs.
The problem is that it's impossible to get a job without a college degree. You can't expect genius level IQ from everyone.
I don't.
I only expect it from people who are not destined to ask "Would you like fries with that?".
We have more people than we need to produce everything we consume. Education is a force multiplier, automation is a force multiplier, and technology is a force multiplier.
Eventually, there will be one guy named "Bob" in Newark, New Jersey. It will be his job to roll out of bed on Monday, and press the button that tells the robots "Please don't shut down, the planet still has human occupants".
And Bob will be the only one who has a job.
Exactly.
M.I.T. is even more strongly endowed, via its patent portfolio.