ruediger

There is a PPA for the snapshot

https://launchpad.net/~cassou/+archive/emacs

http://emacs.naquadah.org/ (Debian)

Complete list http://www.gnu.org/software/emacs/NEWS.24.1

They could add support for GCC (MinGW) and ship it.

No APL code? I'm disappointed!

Can you elaborate on that? Why does Unicode suck for Japanese text?

> Also UTF-8 string can't be cut at arbitrary position.

Neither can be any other kind of Unicode string because of Combining Characters. That's why the Unicode standard (or an Annex) recommends algorithms for text segmentation.

(And if you really need to cut at a certain length then you can easily backtrack and find the beginning of the sequence by looking for the first byte with the MSB = 0)

ICU has some UTF-8 functionality. But ICU is really ugly.

http://userguide.icu-project.org/strings/utf-8

The problem with start ups is that engineering is fun but business and administration is no fun. Nobody is enthusiastic about filling out tax forms and yelling at people because they are missing deadlines. People with experience in administration are rarely looking for a chaotic start up that can't pay a good salary.

Linux and *BSD have a fixed ABI for C++.

What about lwn.net?

Did you report that? It seems you should rather discuss that on the gcc mailinglists with the gcc developers.

I guess the reason for Google to start contributing to Clang and using it for their tools is the availability of the frontend. As far as I know the GCC developers made it extra hard to separate the frontend from the compiler because they feared that people would use it on proprietary backends. But this really left us in a situation were for decades people couldn't work on creating amazing static analysis, autocompletion, refactoring tools for C and C++. In the end this decision probably did more damage to the free software movement. GCC now comes with a plugin interface and with the Clang frontend available I hope that this will change quickly.

Why is the competition not-so-friendly? I believe GCC has already improved due to Clang at least a lot of the error message improvements in the last releases seem to be inspired by Clang and GCC has finally added Plugin support.

No. I'd rather like to see Linus talk about Linux (or git) and Bjarne talk about C++. That would be far more interesting than having them fight a flame war over such a silly issue as C vs. C++.

That's just the question of having a license. Not whether the implementation is open source.

Microsoft is threatened. Selling Office (and Windows) licenses is the backbone of Microsoft and that's what's financing all the other adventures. Large companies have to buy Office licenses for every workstation. Even with large customer discount they still pay millions on license fees. With LibreOffice now being independent of a large company it becomes a viable alternative for those large corporations. It's much cheaper to hire a LibreOffice developer or get a company like SuSE for contract work on it to do all the required customizations than buying MSOffice licenses.

People complain a lot about the GUI of LibreOffice. But in fact it can be an advantage because it is much closer to Office 2003 than the new Office versions. And it seems that Office 2003 is still the de-facto standard in a lot of corporations. So moving to LibreOffice might in fact require less training than new versions of Microsoft Office.

There are other alternatives like Google Docs etc.

Therefore it is a threat to Microsoft. Will LibreOffice/Google Docs etc. kill MSOffice in the next Years/Month/Hours? Of course not. But it will have an impact on Office sales and MS would be stupid not to consider it a threat.

And of course there are still some technical issues. E.g. a missing alternative to MS Exchange. I know that there are some commercial open source alternatives. But there is not the one true alternative on the horizon. Another problem of course is backward compatibility, SharePoint, etc. But all of that can be fixed in the long run and will be with more support from companies like Intel.

> In order to "fully open source" it, they would have to include an open source H264/mp4 decoder. Which would probably not be allowed by everyone who owns H264. Alas.

There are existing open source implementations of H264. Even the best encoder (x264) is open source. But I guess there are license issues with third party code/libraries used in Flash.

Apple doesn't use glibc.

I'd guess something between 150 MiB and 4 GiB.

> He did this so it would work better with tools like diff, patch, and version control in general.

git supports a --color-words option which is quite handy for text.

> I thought "hey, worth a shot", tried it, and found it too clumsy for me during the writing process and abandoned it soon after.

use auto fill and don't manually break lines :)

You can have all of that in Emacs and probably in vim as well.

See ctags/etags, cedet, ropemacs (refactoring Python), xrefactory (refactoring C and C++), wrangler (refactoring Erlang), etc.

That lsb_release is "an optional package in many distributions" is only a minor complain:

> There's already the lsb_release tool for this, why don't you just use that? Well, it's a very strange interface: a shell script you have to invoke (and hence spawn asynchronously from your C code), and it's not written to be extensible. It's an optional package in many distributions, and nothing we'd be happy to invoke as part of early boot in order to show a welcome message. (In times with sub-second userspace boot times we really don't want to invoke a huge shell script for a triviality like showing the welcome message). The lsb_release tool to us appears to be an attempt of abstracting distribution checks, where standardization of distribution checks is needed. It's simply a badly designed interface. In our opinion, it has its use as an interface to determine the LSB version itself, but not for checking the distribution or version.

And I guess distributions are far more reluctant to install a shell script than adding a file to /etc

No, I'm treating OSX as a UNIX. It is advertised as such. I know that you can use the app bundles. But they are only useful for GUI applications. I usually run applications like octave or gnuplot from the terminal or other applications (e.g., Emacs).

I prefer Linux over OS X as well. The OSX userland is a strange mixture of GNU and BSD tools in sometimes ancient versions. OSX has a UNIX certification but there are some bugs in their POSIX API or even missing functions like clock_gettime. Linux seems more POSIX compliant.

The OSX package managers suck. I tried fink, macports, and homebrew. A lot of packages are simply broken especially now after Apple switched to clang. You end up in all kinds of weird situations. A friend of mine recently wanted to install Octave and gnuplot with homebrew and it took him several days until he gave up.

It's hard to get help with problems in OSX. This might have been improved. But back when I started using OSX in 2005/6 it was really bad. It was rare to find people with a good knowledge of the deeper layers of OSX. It was a complete different culture than Linux or even Windows. Maybe that has improved now that OSX is much more popular.

And it feels like Apple is more and more ignoring the UNIX folks.

You still have to worry about combining characters.

The web consists of a lot of markup and javascript. That's all in ASCII compatible characters. So on the web UTF-8 usually wins even for Japanese or Chinese texts. For example take a random page of the Japanese Wikipedia and encode it in UTF-8 and in UTF-16. In all my tries UTF-8 was smaller.

I wouldn't use UTF-16 unless having to work with a legacy system. A lot of software claiming to handle UTF-16 is broken and really only works with UCS-2. You have to worry about endianess and so on.

If you develop an application for the international market you should probably go with UTF-8 as well. Maybe if you develop only for the Asian market it's a bit different. But in my experience significant amounts of text usually come in some form of data or markup format (HTML, XML, JSON, etc.) and usually those markup formats are defined in the ASCII subset. So UTF-8 still wins. Just take a random page from the Japanese Wikipedia and encode it in UTF-8 and in UTF-16. You'll see that UTF-8 almost always wins.

I know. But for serious application a real drawing capability is needed. This should actually be possible to implement on top of the GTK+ layer.

I wish Emacs would provide a canvas like API to draw in buffers. That way integrated graphics could be easily added. This would create a completely new Emacs experience.