321–330 of 338 posts
Earlier quoted context omitted.
You're suggesting that a scrappy startup in a field everybody else wrote off which eventually grew to be one of the biggest companies in Silicon Valley was actually just a front and not a real business the whole time? That strains credulity — really far.
Ever heard of Operation Mockingbird? http://en.wikipedia.org/wiki/Operation_Mockingbird
Earlier quoted context omitted.
Octane is Google's own benchmark suite. I don't think getting beaten on your own hand-picked set of performance metrics satisfies any definition of "impressive".
It sure is far better than idiotic SunSpider. They are close to real-life application examples. If they really wanted to hand-pick they would not include asm.js benchmarks, where Firefox has a certain advantage.
The notable thing about this achievement is that for a very long time V8 was miles ahead of the competition on its own benchmark (first V8bench, and now Octane), as the graphs at http://arewefastyet.com/ show.
Earlier quoted context omitted.
Does IE run on anything but Windows these days? (Edit: Doesn't look like it. Alas.)
So what? Safari is also stuck in Apple land.
Firefox, Chrome, Opera and others are not so picky about which operating system they run on.
Earlier quoted context omitted.
Plus it doesn't forbid people to make a donation to support the software they like right ? That's what I do, knowing FFx isn't making any money from me, and knowing that I'm using years and years of development is a good enough reason for me.
When you donate it goes to Mozilla Foundation while search deal money goes to Mozilla Corporation AFAIK. That means they actually need donations for the foundation to run (but its not 800 employees so its much less money). Legally you can't fund the Foundation with the Corporation money - since that would make 2 Corporation and zero Foundation then :) I don't know if the opposite is possible (send donations from Foun…
The Foundation is the sole owner of the Corporation. The Corporation pays dividends to the Foundation.
Now the amount of those dividends can't be too much if the Foundation wants to keep its nonprofit status. "Too much" is determined by how much people donate: the restriction is on fraction of money that comes from non-donations.
Earlier quoted context omitted.
I mean the services Google provides to users in the form of web applications, yes. The terminology is sucky. As for concrete examples, Hangouts only works in non-Chrome browsers (including ones with WebRTC support) if you install a Google-provided binary blob. Which you may not be able to do. Gmail only supports offline access in Chrome (see https://support.google.com/mail/answer/6557?hl=en the "two exceptions" bit).…
This is a huge problem for the overall strength of the open web and Mozilla unfortunately is no less guilty of this. Many of the tools developed for FxOS are targeted for Gecko and wont run on other rendering engines. More and more it seems the only people actually building libs for the open web are independent developers and small shops. :(
That said, I agree that more FxOS bits need to end up on standards tracks. The permissions issue really needs solving to make serious progress there.
Earlier quoted context omitted.
I can't entirely blame them for this one considering the alternative is either using something standard (localStorage) where they're only going to be able to store a really insignificant amount of information or creating something proprietary for multiple web browsers which is difficult to maintain. If there was a web standard way of caching 5GB of files locally then I would be annoyed.
IndexedDB is supported on all major browsers by now.
Earlier quoted context omitted.
This is a misconception. You are flat put wrong, and spreading misinformation about it doesnt help anyone. If you use any rust, and that includes dependencies and the standard library with unsafe code, bugs in the unsafe code can and do cause segmentation faults. Its easy to say, 'well, thats a bug in the library, not a problem with rust', but thats the same as with C++ isnt it? If you can assert any code is 100% bug…
I guess I should have been more explicit that I was talking about the language itself (without the unsafe keyword). Not libraries written in other languages, not compilers. It's the job of theorem provers and whatnot to make those safe. In other words I'm talking about code the programmer makes themselves. >Its easy to say, 'well, thats a bug in the library, not a problem with rust', but thats the same as with C++ is…
Thats the point.
You cannot assert your rust program cannot crash.
Even if your code is perfect, there may be bugs in either the std library or some dependency you use that does crash.
Im not saying everyone uses unsafe code (or should) in their own code. Far from it.
Im saying that every rust program invokes unsafe code at some point.
So this myth of the 'pure rust' that is 'completely safe' is just that. A myth.
I dont understand why this is difficult idea for people to accept. Just use the good bits of rust. rust doesnt need to be 100% safe; its not, and thats completely ok.
Earlier quoted context omitted.
This is a misconception. You are flat put wrong, and spreading misinformation about it doesnt help anyone. If you use any rust, and that includes dependencies and the standard library with unsafe code, bugs in the unsafe code can and do cause segmentation faults. Its easy to say, 'well, thats a bug in the library, not a problem with rust', but thats the same as with C++ isnt it? If you can assert any code is 100% bug…
How often has one of your Rust programs segfaulted for you, when it wasn't a bug in your own unsafe code (as opposed to that in the standard library)? For me, the count still stands at zero. I've been writing Rust for well over a year. I like to abuse new features and I've found many compiler bugs, but my code doesn't crash at runtime. I'm not saying it doesn't happen, and the plural of anecdote is not data, but I th…
maybe once a fortnight for me?
I'm certainly not trying to bash rust, and I do apologise if it comes across that way.
I just think a bit of realism makes everything look much more sincere and plausible.
As you say 'Rust cannot crash' is false. 'Rust has never crashed for me' could well be a completely true thing to say. Also, 'Its so much easier to write rust code (than say c) that doesnt crash!'
I completely ok with all of those.
..but 'you can do anything in rust and its always perfectly safe!' or 'rust programs dont have to worry about security issues' or 'It is effectively impossible to have an unsafe memory access error in Rust'?
Those are people being enthusiastic (good) but unfortunately spreading misinformation (bad) and making the rust community look bad (very bad).
I just wish people could be excited about the the things that are actually exciting about rust. I feel like this whole safety thing is a massive distraction.
fast, low level, concurrent and managed memory with no cost is both accurate and exciting about rust.
'helps avoid bugs and race conditions' isn't very exciting to me, but I acknowledge its important.
I guess 'completely provably safe!' is exciting to some people; but since its not true, Id prefer not to get people excited about rust that way.
Earlier quoted context omitted.
It is effectively impossible to have an unsafe memory access error in Rust Please, don't say that. Lets be reasonable. Rust is great, but Rust code crashes and segfaults too, just like any language, programs have bugs, and those bugs can cause program failure. Rust just has less of them, because it has a smart compiler. ...but it's not right to suggest that it has none. Remember: There is no way of ensuring that a ru…
This is misleading. Apart from bugs in the core code (compiler and stdlib) you shouldn't be memory unsafe in an exploitable way. Even segfault from deref null should be rare. It's like saying Java isn't safe because it might call some JNI. While pedantically true, it's qualitatively different. That's why effectively impossible is an OK statement. Unless you go out of your way, your program will not contain such bugs.
Rust has many other unsafe code paths than ffi; low level optimisations, dynamic libraries, etc.
Unless you go out of your way or are doing low level work, your code will not contain such bugs, and if you used no dependencies that do anything meaningful, what you said is plausibly true.
...but what are we trying to argue here?
That you can build a contrived rust program that doesn't crash?
Or that if you build an arbitrary program in rust, using arbitrary dependencies to do meaningful work (that will invoke a c library at some point, and talk to device drivers), that it wont crash?
In my view 'effectively impossible' is faaaaaar over stepping the bounds of reality.
Earlier quoted context omitted.
What's so evil about Google?
It doesn't matter. (disclaimer: googler) I see it as a hubris against the idea that Google claimed to not be evil, and the fact that evil is such a poorly defined concept, and whether or not Google meets the bar depends entirely on the values of the perceiver. Many perceivers, for instance, miss the distinction between "Don't be evil." and "Don't do evil.". The former is a mindset, strategy, and intention, while the…