Certainly not transparent file system compression. Can save developers couple 10 GBs but hey (source code, binaries, debug symbols, all compress nicely).
"CF doesn't even host them, they just protect their sites from DDoS and DNS."
The #1 excuse people use. They do more than just DNS, they deliver the actual data, that would have been delivered by the original host, to visitors. So I'd consider them hosting an automatically updated mirror, and as bad as the original host.
I used to use Cloudflare for DNS, but I left because I was becoming uncomfortable with their policy regarding DDoS attack sites. We run our own Anycast CDN now for the HTTP, but I didn't want to have to deal with the DNS servers so I outsourced it to DNSimple.
Turns out that DNSimple unknownst to me started using Cloudflare's DNS servers under the hood. They were getting attacked by the DDoS attack sites Cloudflare hosts and it was threatening the service. I figured this out by doing a lookup of their nameserver IPs.
So my attempt to get away from using Cloudflare has meant that I'm just right back on Cloudflare's servers, again.
This is an insidious cycle that will not end well for the internet, or for our freedom on it. The internet will not be decentralized anymore if the entire thing sits on Cloudflare and depends on Cloudflare to function. Cloudbleed is a canary in the coalmine.
That point comes up every time a bad-HR related post is placed here. However, isn't it very short sighted to consider silencing/removing the accusers a protection of the company. This results in a bad culture and bad PR about that culture in developer circles.
Won't the reduced diversity and all that comes with it have bad effect on the company long term?
It isn't short-sighted, because a discrimination lawsuit has unbounded liability and gets widely reported on. Words are temporary and can be whitewashed, whereas few companies can afford an admission of guilt.
In a reputable company, HR will pass the message higher up (probably off the record), and a manager will look at the evidence and make a good judgment. In this case, the evidence is clear, the manager should have been fired, and the employee given a sincere (but not in writing) apology and compensation.
Note that HR is a legal role. HR will never advise an employee to consider filing a lawsuit against the company, but instead dissuade the employee by saying that there isn't good evidence, it was an honest mistake, he has a family to feed, try to work with someone else. The saying exists because advice from HR is not in the employee's best interest.
> isn't it very short sighted to consider silencing/removing the accusers a protection of the company.
Yes. It's also human psychology. See the church sex abuse scandals. The morality that people claim to have is less important than protecting the group.
The same thing applies to HR. The HR person who shuts down an accuser is doing it in order to protect their position in the hierarchy, and to protect the people in the hierarchy that they know. The fact that it's illegal, and can very well destroy the company is completely irrelevant.
In these cases, short-term focus is more important than long term goals.
It may be short-sighted, but, frankly, most people and organizations in the world act in most contexts in short-sighted pursuit of their goals. Foolish, sure, and unethical in the case of HR departments, but nonetheless, the behavior one can expect from them.
Plus the lawsuits that should be brought... except that bringing a lawsuit on a sexual harassment case results in even more of the same shit in court, plus potential employers hearing about it.
Why do you need a extension for that? Wouldn't it be enough for the client app to register a custom URL scheme handler and their website using that custom URL scheme to open the client?
I don't know exactly what the extension does behind the scenes, but I use Webex daily for my job and almost all my clients suggest just using the temporary application to join is a better experience by far. The extension constantly fails to launch the application correctly and from what I'm told does some other non-sense that causes CPU spikes and connectivity issues.
It also doesn't inspire confidence that this is the screenshot of the Chrome Extension they give users to encourage them to use the extension: http://imgur.com/a/Rsy3H
(For those who don't want to click, the screenshot showing the install has the rating from the Chrome Webstore, which is currently at 2 stars)
I mean, I applaud the honesty of showing us what users have rated it, but it just seems kind of sloppy to me.
You can, but that results in a ton of UI where the user has to navigate between "allow" custom protocol and then selecting what applications are allowed to launch via this protocol.
Currently it's a maze of dialogs only technical people are able to navigate successfully. Expecting people already in need of support to manage to bypass this deliberate inconvenience is simply unrealistic.
The company I work for used to maintain a solution based on this approach. It worked well until browser-vendors started tightening up security.
After that we had to come up with a different solution all together, because almost no users managed to configure our integration successfully.
(And that rewrite was a lot of work, so I can see why Cisco/WebEx has been postponing it as much as possible)
Couldn't the also have a webx file extension and launch it that way? Or abuse copy/paste abilities? The former would allow easy desktop bookmarks as well.
They could even, god forbid, accept that it's not possible instead of coming up with "clever" ways to make it possible.
That is not a sign of the quality of the language though. It is more a sign of how much money went into making a poor quality language perform well. Compare the speed of JS JIT VMs to Lua JIT VMs considering the investment respectively for example.
It's not about language quality, it's about barriers to entry.
You not only have to be "better" than JS (which I guess means some combination of performant and pleasing to code), but you have to do so to such a degree that it's worth losing access to/reimplementing the existing libraries, not to mention getting multiple browsers to implement AND getting everyone to install the newer versions of said browsers (not as bad as it was, but still an issue).
I currently do JS for a living, and I don't hate it, but most of the reasons to DO javascript coding have nothing to do with quality of language and instead have to do with how unlikely a viable competitor is to come about anytime soon.
I don't hate JS, but I do find it a bit taxing to write JavaScript that might have bugs due to unexpected behavior in the language. I'm in the process of rounding out my self-taught programming mojo with some intro to CS courses, and the professor started talking about syntactically correct code. He gave the example of something like `3 + "hi"` being syntactically incorrect, saying it wouldn't run (in Python). My first thought on seeing that example was "JavaScript will run that!", and I didn't mean that as a compliment.
Of course, I know that. But companies are rich. They both have their own major browsers. They can just pay to Mozilla and Apple (two remaining major browsers) to support their language(s). Libraries are not a problem for .Net, Go, Swift, Rust.
All four companies have success with their own programming languages, which is not an easy task to do. Some of them are also succeed with their own OSes too, which is even harder. They CAN replace JS if they push a language strong enough. They cannot do that because replacement languages are worse than JS.
It is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole.
Lua is better optimized because it is smaller. It's been the right decision to keep Lua small given where it specializes. Given where JavaScript specializes it's been the right decision to not keep it small but to evolve it. JavaScript is big because it can be big; it has the resources to make it so.
> It is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole.
I think this is fundamentally wrong. I think you're confusing the language itself with how the language has been implemented.
Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA.
These days JS generally gets JIT compiled and a tremendous amount of work has gone into improving the popular compilers. Lots of tricks are involved. These tricks are quite clever (though sometimes inelegant) and result in significant speedups. But they have nothing to do with the language itself.
Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA.
If so, you're basically agreeing with parent, in parent's disagreement with this from further upthread:
Of course the semantics of a language can impact how easy/hard it is to write a fast implementation for that language. And as far as I know, there isn't anything special about the ECMA specification that makes it any harder to speed up compared to other languages in the same space (dynamic languages, whose specifications were written with an interpreter approach in mind).
Still, in my mind, speeding up any sufficiently dynamic languages with eval and metaprogramming without straying at all from the language spec is like "fitting a square peg inside a round hole." And I think that has been done successfully with JS, at the cost of making it harder to reason about how the compiler is going to treat my code.
Most code isn't using eval. It's okay if that part is slow. But even the most basic operations in javascript have all sorts of weird hooks that slow down evaluation. Most of it is little to no benefit to the programmer while a huge pain to the implementation.
