stass

Which Google applications are actually used on the iOS? The only one I have installed is Youtube and only because the mobile version of the website is even worse than the app.

I don't think the disappearance of Youtube app in it's current form would make any difference.

This is not a fair comparison. English is an international language of science and technology unlike Chinese and other languages.

What's wrong with prolog syntax?

SmugMug is great! It's a little bit different from Flickr though -- SmugMug is more of a personal photo hosting/portfolio website, while Flickr is more about photographers community. I believe the social aspects of Flickr are much more important than it's actual photo storage capabilities!

This is extremely biased. A lot of people, myself included, find it easy and pleasant to use. Honestly, I'm not aware of a single alternative with a better UI/UX -- 500px maybe?

As for programmatic access -- Flickr has a good API interface.

jemalloc is unaffiliated with FB. It was developed and integrated into FreeBSD and Firefox long before the author started working for Facebook.

There are multiple issues you are dealing with here. First, no tools "will output UTF8 if they think that's a good idea". All properly designed application are required to respect the LANG setting (or equivalent LC_XXX environment variables) and use character encoding specified in them. This is the basis of character encoding support in most (all?) modern UNIXes. There's no risk running with LANG set to something other than en_EN.UTF-8 when using properly implemented software (most of it), and as a matter of fact a lot of UNIX variants has C as default (actually, the only two I know which don't are Linux and OS X). I have been running with LANG set to C (or KOI8-R on OS X) on FreeBSD, Linux and OS X for more than 10 years, and yet to hit the problem. Now, there are always issues with dealing with UTF-8 data (or different 1 byte encoding to a lesser extent), but see below.

Second, you keep treating UTF-8 as some special encoding (ein OS, ein encoding?), but it's certainly not. Even if you are using UTF-8 as a system encoding, you are going to have problems dealing with non-UTF8 data, and it's actually going to be worse than dealing with UTF-8 when using LATIN1. Mind you, most systems don't use UTF-8 as default encoding: most Linux distributions do, but Windows uses UTF-16, Mac OS X has it's own somewhat incompatible version of UTF-8, Java is UTF-16, and so on. One will have problems dealing with all these systems if his encoding is set to UTF-8.

Lastly, the Python example is not really representative. Some language implementations have better support for multi-byte encodings, and some worse. Ruby, for example, has a very good support for dealing with UTF-8 data even when not using it a system encoding.

The original question was about the command line. When managing servers it's perfectly accessible to use LATIN1 if one does not expect to deal with UTF-8 data (examining processes, VM states, changing configuration, etc). If that's not the case, one can use UTF-8 or some other encoding for that matter (i.e. I routinely have to deal with non-UTF non-ASCII filenames and text, using UTF-8 won't cut here either).

The question is, do you need to handle UTF-8? In most cases of sever management having LATIN1 would suffice, or appropriate localized 8-byte encoding.

You can apply the same argument to any other obscure encoding scheme, not just UTF-8. The answer is really to pick the encoding which will suite the most usecases and won't be painful to use.

That is actually due to a lack of rich abstraction mechanisms in Java.

Symbol versioning came from Solaris, originally, and the actual de-facto standard was specified by Sun.

Bugginess of one particular implementation (and let's be fair here -- most of the stuff in glibc is quite ugly and hacky, a direct consequence of the bazaar model) has nothing to do with dynamic linking. Both PAM and NSS have been used successfully in a dozen of other operating systems for decades, and that's dynamic linking that facilitated these technologies.

Are you arguing that glibc code quality will magically go up if they abandon dynamic linking?

Specialization is what compilers do really well. :) Humans -- not so much.

It is by all accounts. It pretty much relies on the underlying machine memory model, and ordering of operations in a C++ program directly corresponds to the resulting ordering of the operations on the machine it is running on. Furthermore, the language itself is clearly speicific to register machines and follows the corresponding semantics -- it'd be hard to target other kinds of computers from C++.

As cgabios noted below low-level code obduscates intended behaviour. Ever tried to write a C optimizer? A trivial example is a for loop vs map -- the former has inherent ordering semantics and compiler does not have any way of knowing if this behavior needs to be preserved, while the latter just tells that a particular operation needs to be applied to each element so compiler is free to reorder/parallelize/etc. There are much worse situations that arise from low-level language having to preserve the underlying machine memory semantics (that is one of the reasons why it is hard to compile low level languages like C or C++ to e.g. Javascript. Compiling x86 assembly would reuire a full machine emulation).

This is discussed in detail in most introductory CS books if you would like to learn more.

To avoid overhead people implement specialized compilers suited for the task at hand. If anything, going down to C, and especially assembly will hurt performance as low-level code is much harder to optimize for obvious reasons. Above all of that real-world performance comes from proper system-level design, not micro-optimizations, and using a low-level language (be it C, C++ or assembly) will prevent one from quickly iterating over different ideas.

> FB/Google have a reputation to uphold and they strive to make sure their name isn't associated with subpar stuff. Plus, they have a lot of brilliant developers to work on this stuff.

Why do you think so? My experience was quite the opposite... One can argue that large companies don't care about their reputation as much as small companies and individuals do as responsibility gets diluted among the larger number of people. This was certainly the case with most of the tech companies.

This is a great tool.

However, he authors/documentation seem to be confused about bash vs shell. In the documentation these terms seems to be used interchangeably. In the code, the main script depends on bash directly (and for it to be installed in a very particular place) but does not seem to use any bash-specific features. However, the script it launches at the end is launched via "sh" which is not bash, so if there're bash specific features in it it would fail.

"PathPicker should work with most Bash environments" -- what does that even mean?

The title is misleading. It only works on Windows, OS X and Linux. It does not support any other OSes at all.

You can use kqueue/kevent to poll on a file. That's what tail(1) and other system utilities are using.

That's subjective. I don't recall a single product from them that came after search and didn't suck. But the real problem with them is these solutions are being pushed down people throats whether they like it or not similar to what Microsoft was doing in the 90s. This is just another example.

Is it necesseraly bad? Netflix making deals with ISPs is exactly what market self-regulation is.

Are you referring to GNU sed? Other sed implementations I know of actually use -E for extended regular expressions support. I could never understand why GNU picked up -r for sed...

As for dd, it came from a non-UNIX OS and kept the original syntax.

Great accomplishment! Congratulations to OpenBSD folks!

Google by itself is much worse than NSA. At least, NSA does not screw up the industry and does not try to destroy local economies. I'm surprised there's not a lot of public backslash against Google and their employees.

Linux? FreeBSD? Haiku? There's plenty of choices, and all of them have modern web browsers available (and frankly, better browsers than Chrome. People should really stop drinking google kool aid and take a look at the chrome codebase first before using it).

Why doesn't it?

I didn't say at all that C is bad, as a matter of fact I write most of my code in C. It is, however a low-level programming language not much different from assembly.

The reason it is that it operates on concepts that are not abstract but are of register machines. A high completely abstracts underlying architecture so the code can be executed in any possible environment by means of translation, be it a $10MM Cray or a cellular automaton or a mechanical computer. In essence, a high level language provides an abstract notation for computation.

C, however, is not abstract at all. Variables? How those will map to a dataflow computation? Pointers? Would not work beyond register CPUs (e.g. it is very cumbersome to translate C programs to Javascript as a result and usually leads to a memory array emulation). Fixed-width types? Volatile pointers? Returns from the middle of a procedure? Gotos? Come on, how those are even going to run on a non-conventional architecture?

C also does not completely define the language semantics leaving certain operations implementation-specific or undefined. It also (before C11) didn't define any memory model, thus making it impossible to even describe an algorithm that depends on specific properties of memory accesses in a way that will be portable across different register machines. C algorithms are close to impossible to translate to be run on memory-less computation devices as the whole concept of C is based around having local memory and a stack space with certain properties (unless one wants to emulate a register machine, see JavaScript remark above).

In certain areas it lead to some ugly solutions like Cuda where the language looks like C but semantics is completely different and GPUs are the closest thing to he original C target as you can get.

No, C is as low level as you can get. It directly maps into the instructions of a register machine in runs on.

That's true that it allows faster-than-light communication is some sense, however it is not clear if it is possible to use quantum entanglement for faster than light information transfer: to extract the particle stat one has to perform a measurement which immediately destroys the state it is in.