fafner

GCC 5 will default to -std=gnu11 (C11 with GNU extensions)

> And I believe your example with the T{val} is C++14 so I don't know much about it.

No, it's C++11.

It's not gone from YT! It's certainly on its way out. But despite the announcement I still see Flash as default in Firefox and even in Chrome it sometimes falls back to Flash (happens to me when I start a video, put my laptop to sleep, and continue the video after resume).

Why do you need to know the exact type? Why does it matter so much for C++ but not for other languages? I mean there are templates in C++ and a lot of code even in C++98 was written not knowing the exact type and just assuming or expecting certain properties/methods to work.

Sorry, but your comment lacks substance because you don't provide any argument for the way you think. Why should it only be used for iterators and anonymous types?

There is a pretty good argument for using the

  auto var = T{val};

style of defining variables. The {}-initialization won't narrow literals. You can find more discussion about this in GotW.

Maybe you have a good reason for not liking the style and there certainly can be arguments against it. But from experience I find that many people opposing more use of auto simply oppose it because it is different to their old ways. Therefore I'd like to see a proper argument for your comment.

1. The new declaration style might look a bit strange to people used to the old style. But one could argue that using it will make it more consistent for the cases when you really do need to use it. Anyway it's just a matter of style. Not really a need to discuss it IMO.

2. Some people argue that

  auto v = T{x};

should be the new way of defining variables with types. The use of {}-initialization should prevent unnecessary narrowing. In this case () has to be used because a specific ctor is to be called. But using that style would make it more consistent with the rest.

GNU Emacs has something like that in Dired. It's called Wdired (writable dired) and allows editing the Dired buffer and then applies the changes. Think of it as editing `ls` output.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...

> fetches it at startup from Adobe's site

Source?

Anyway, even if you can download and sandbox the Adobe module it might be a violation of the license agreement. This can even be a criminal offence in many countries because of special laws about circumventing DRM!

What about operating systems and hardware platforms not supported by Adobe or Google? PowerPC, MIPS, Tizen, *BSD, etc.

To make matters worse: Three of the four major browser vendors are also DRM vendors. Google, Microsoft, and Apple all have their own DRM modules. EME therefore gives them a lot of control over the browser market and media market.

Four of them are also working on their own mobile devices/OS. Which gives them even more incentive to lock out competition.

There are actually changes to mail merge in this release. But it seems it is about performance and not the UI.

https://people.gnome.org/~michael/blog/2015-01-29-under-the-...

More detailed change log by Michael Meeks: https://people.gnome.org/~michael/blog/2015-01-29-under-the-...

> and the rest just falls naturally into place

No, the timezone string is messed up:

2006-01-02T15:04:05Z07:00

If they had picked

2000-01-02T15:04:05Z06:00

(03 would make more sense but then there would be issues with 12h vs 24h clock)

then they could even express ISO 8601 week number and the corresponding year. Something which is not possible at the moment. Although more difficult to remember it would be 52 and 1999. (For the 2006 it is 01 and 2006 not distinguishable)

That's not ISO format though.

Wahhabism and other extremist versions of Islam have a significant following. Polls regularly indicate support or acceptance towards extremist views within Muslim communities. It's therefore not as simple.

I think neals meant "modern" Christianity, as in what has become of Christianity thanks to the age of reason. This excludes some Western (especially US) branches of Christianity.

I don't understand how anyone could claim that CH published those comics "just for the purpose of offending". All of the CH comics had messages, very valuable messages in my opinion.

Breivik isn't a Christian terrorist. He described himself as not being overly religious. He is also very critical of modern (I think that's what's meant by Western here) Christianity, both in the Church of Norway and Catholicism.

> The person who wrote the article managed this easily enough.

Since it's a single data point I think it really says more about the author of the article than about Emacs...

You are not helping your point by insulting me. I know that EVFILT_DIR can be added. I never disputed that. But it needs changes to the kqueue API. And apparently it is not so easy because nobody has done it and even operating systems using kqueue have opted to do it differently. You can talk all day about how things could be done theoretically. But that doesn't matter if reality looks so much different. Maybe you should ask yourself why EVFILT_VNODE was so poorly designed.

That would be a good decision. So far I've only seen an attempt to implement inotify on top of kqueue. Which of course will be buggy and incomplete.

I have explained it several times now: The Linux devs had 5 years to come up with the inotify design because their API is more flexible. If you design things along the lines of "do one thing and do it well" instead of "let's cram everything into it" then you gain that flexibility. That's where the kqueue API fails and that's why it is not as good as the Linux approach. You talk about "extensible". But extensible really means touching the kqueue API because that's the only way to extend it. On Linux epoll is far more extensible because it just means adding a new descriptor type.

I don't know why you claim that Linux ignored the hard problem of generic event APIs. Unlike kqueue, Linux has a truly generic event API. That's what I've explaining since the beginning.

Even if Linux had added kqueue and added an EVFILT_DIR then there would have been no guarantee that the BSD's would adopt the same API. There is no committee in charge of kqueue. The licenses are not portable and even if they'd agree on being compatible for kqueue then this would touch parts beyond it. And then there is the huge questions, why a directory and a file should be treated differently, when the only difference is the provided meta data.

Apple apparently has added a completely different approach to fs notifications. Based on a device and a deamon. Why didn't they just add an EVFILT_DIR, if that's as easy as you claim? Why didn't the BSDs do it?

Claiming that inotify is a hack or incoherent is just beyond ridiculous. Inotify is far better than anything kqueue offers. So if anything then kqueue is a hack and badly thought out...

If the BSD folks would simply adopt inotify then it would be one less painful thing to deal with when porting applications to BSD. All I hear nowadays is BSD folks complaining that the Linux folks are doing things differently and BSD has a hard time getting all the software to run they want. So adopting inotify would make it easier for the BSDs. In the end I don't care. But at least they should come up with a somewhat decent API. Doesn't matter if it's inotify or some NIH'ing.

If you begin your comment with "Bah. This is complete nonsense." then you should at least address all of my points...

Especially when you confirm one thing I've said in your first sentence. EVFILT_VNODE's design it too limited. It can watch directories (which after being opened are just a file descriptor). But it doesn't give you the information you need although they are available when the event is generated. The only explanation for this I can think of is because the API designers wanted to cover every event even if they didn't understand the particular use case. Which is exactly what's going to happen when you try to design an API in such a way.

Yes, you could change kqueue and add another event type. But then why keep EVFILT_VNODE, except for legacy reasons?

You complain about nonsense and then you compare a paper covering kqueue, which again is an API trying to do everything, to the documentation of inotify, which only covers a single class of events. And then you are disingenuous enough to only look at the README and not at the provided manpages and other material. inotify actually has pretty good documentation. But if you want to compare the 30 lines README to the kqueue paper ... well the kqueue paper covers EVFILT_VNODE with 19 lines, 7 of which simply list the possible actions.

inotify is single purpose because it follows the "do one thing and do it right"-principle. The Linux folks had the freedom and time to come up with a good enough API because inotify wasn't forced into epoll, which itself follows the "do one thing and do it right"-principle.

Meanwhile the kqueue designers came up with an fs notification API that is even inferior to what w32 offers...

I think the kqueue interface is a lot worse than the Linux way. With kqueue everything is forced through one interface. In Linux it's just file descriptors and epoll to deal with them. It is a nice extension of the "everything is a file" mechanism and it embodies the "do one thing and do it right".

This becomes apparent when you look at fs notifications. You've already mentioned how inotify is superior to kqueue. I mean seriously, the kqueue fs notifications are designed in such an incredibly bad way, it almost looks like a trolling attempt. E.g., when you try to watch a directory the kernel knows which files are manipulated. But the API has no way of telling you. The documentations usually suggest to keep a file list and update it. But this is complicated and racy and will certainly result in buggy behaviour.

And that really shows that having one interface do everything is a bad approach. The kqueue designers had to cover every event type that could happen. And thus they added an API for something they apparently didn't understand properly. And since it's stuck now in their API they would have to deprecate parts of it, if they ever have the interest in fixing it.

The inotify API is not perfect. But it does its job pretty well and it is the best fs notification API I have seen. fanotify solves a different use case. And that's really the flexibility that the Linux interface has. They can easily come up with new event APIs for new use cases because all they have to do is provide a file descriptor.

I wish the BSD folks would simply implement inotify. But it seems they are unwilling to fix their API and if they did then they'd probably design their own interface simply out of spite. Right now their crappy fs notification interface is a real pain. And since the lowest common denominator is very influential when it comes to portability libraries like glib, Qt, etc. everybody is suffering because of BSD. And they only get away with it because OSX has the same API. I haven't looked at FSEvents. Is it a new API or simply based on kqueue?

</rant>

This law makes me angry. How could have anybody been so stupid? Did the publishers really think Google would just hand them over money? Google announced even before it passed that they'd drop the content. They underestimated what power Google has and if they drop you from the index then you lose not them.

Now they are all handing over royalty-free access to Google. But all other companies and people still have to pay. I mean the publishers think they can make at least a bit of money that way. But they again don't seem to realise that this only strengthens Google because all (potential) competitors have to pay...

The Google folks must be really celebrating over this. A law specifically designed to target Google has only strengthened them.

I think one of the main reasons why Plan 9 didn't succeed, was simply the fact that it wasn't free software from the beginning. Plan 9 was released around the same time as Linux. But it was treated as a secret and then tried to be directly marketed. That way it simply missed the opportunity that Linux took because Linux was free software. Only in 2002 was Plan 9 released under a free software license.

lesspipe is not a GNU project...

People like you are the toxic part of the community. If you don't like dbus or systemd then either come up with a better alternative or use whatever else you prefer. But attacking someone on a personal level because you don't like their stuff is just incredible toxic and annoying. Especially if you have nothing to show for yourself.

I wasn't asking hp.

If you make comments like that then show us what amazing work and contributions you have made to the community.

I think the kqueue API is worse than the epoll API. They make it try to do too much by dealing directly with all kind of events. epoll on the other hand simply deals with file descriptors and there are other APIs to get file descriptors for events (timerfd, signalfd, eventfd, inotify, etc.). That makes epoll a lot more flexible. It's more of a "do one thing and do it right" approach and it adopts the "everything is a file" mantra to "everything is a file descriptor".

One way where the problem with this is showing, is the filesystem notification API of kqueue. It is a ridiculously bad API. E.g., you can't properly watch a directory with it. Replacing it with something saner would require changes to kqueue. If it had been designed like epoll then it would only require adding a different API to create a filesystem notification file descriptor.