If the news site uses AdSense, which quite a few do, then yes. But I'm not sure if Google's extra profit is that significant. Especially when compared to the benefits the news sites get.
While Google does have Facebook as a real competitor, that competition is not on the ad networks side. Google controls the vast majority of ad networks sales (i.e. ads placed on publisher's sites)
Google makes a significant portion of the value for each ad.
> For displaying ads with AdSense for content, publishers receive 68% of the revenue recognized by Google in connection with the service. For AdSense for search, publishers receive 51% of the revenue recognized by Google. [
0]
No, DOCs and PDFs aren't necessarily software, they can contain software, just like a webpage. And just like a webpage, Stallman can choose to use FOSS to view those files, and that software can choose to not run any scripts in those files.
I'm sure he'd agree that people should also not include proprietary software in those files as well, but doing so is far less common than webpages, at least for stuff the average user is going to run into.
And how many people are actually programming in HTML/CSS vs JavaScript? A proof of concept is one thing, but most users won't run into it.
> I'm going to pass on this one. How is /etc not 'extensible'?
Without commenting on systemd-homed, since I haven't watched the talk yet; regular users can't modify /etc. Granted, most applications have user local configuration or a command line option to specify a config file, but not all. That said, I suppose you could always user namespace overlay mount a custom directory over /etc to add custom files to it.
The common pattern is to have some system wide file in /etc or /usr/share that is used by default, and allowing the user to override this with a dot-file in their home directory or passing in a config file as a optional argument.
What is being proposed obliterates most of the workflows that people are use to: editing configuration files in the editor of the user's choice and then having the option of using normal backup or using source code repository tools to maintain and version them. Instead, we have the same windows registry mechanism, with some modern flourishes, that most people have ridiculed Microsoft for decades over.
As a user, I can 'strace -e open' and see what locations my program is trying to open. This is very helpful for what configuration data is being read. Everything is a file, and every file operation is a syscall. As a developer, JSON isn't appropriate for every kind of application.
Also, even disregarding security issues. Maybe you just don't want your video game to crash during a boss fight? Memory safety isn't just important for security; it can also prevent lots of annoying bugs.
GUI is definitely an open problem in Rust, but to be fair, cross platform GUI is hard. In all of programming, it seems that Qt is about the best that we have when it comes to cross platform GUI, and I don't think most Rust developers care enough about Windows to write and maintain native Windows-only GUI libraries. C# (or I guess F# or any of the other .NET languages) is definitely a better fit for Windows UI programming.
If I was doing windows programming I would definitely write a c# GUI everyday-all day over what's currently available in rust, but still do my business logic in Rust :) . I simply adore the language at this point.
I wonder if it is actually more complex. Emergent complexity is a thing, and one only needs to look at Go (the game; pun definitely (not) intended). The rules are dead-simple; you can learn them in under a minute. But to actually play the game well, you have to learn a lot more. You have to memorize openings, learn to identify and utilize patterns, etc. There is a lot of "meta-play" going on, and you could say that high-level Go play is full of abstractions. In fact, you won't have a chance without the abstractions. If you only see individual stones rather than shapes, you're done for. I think the same applies to languages like Go. You don't have generics, but if you want to effectively re-use code, you need abstractions. The difference now is that in languages like Rust, you have predefined and marked abstractions, while in Go, you define them yourself and need to recognize them yourself. Granted, Go also makes certain kinds of abstractions difficult or impossible to manually define within the language, so you may end up with copy-pasted code, but I imagine even that will be manually abstracted through naming and such.
The Rust iterator is a pretty simple abstraction in my opinion. It's essentially a lazy list. You see an iterator used, you know what you're getting. You see the map function used, you know it's the same as a for loop over all the elements. A fold/reduce is just a for loop over all elements with a result variable that gets returned. I really don't think using iterators is any more complex than a for loop, and with a for loop, you actually have to look through it to identify the pattern used and find out what it does. I'd say having to manually check for patterns is more work, but I couldn't say which one is more complex; maybe neither is.
