But at the end of the day its still up to the developer to take advantage of those capabilities.
True, although there are some ways around this. For example, you can quite easily with capscium create an application launcher that opens a set of file descriptors and then execs an untrusted application. It's also relatively easy to integrate this functionality into a filesystem browser or application launcher, so if you try to run an application that is not on a whitelist it will run it in a sandbox. This is likely to appear by default around FreeBSD 10.0.
In UNIX, everything that interacts with anything outside of the process goes via file descriptors. Capsicum provides special file descriptors with capabilities. When you enter capability mode, the kernel no longer allows you to create new arbitrary file descriptors. This means you can't create new sockets, you can't touch the filesystem, and you can't touch any devices. You are completely isolated unless some other process passes you a file descriptor or you create one via a set of special rights. For example, if you have the correct permission, you can use open_at() to create a new file in a directory for which you have a descriptor. This allows you to, for example, set up a sandbox where an application can store files in a per-application location and can use a temporary directory. If it wants to open a socket, it has to ask another process. If it wants to open other files, it has to ask another process. The typical way of handling the second is to have a file-chooser application that allows the user to select files and then passes the rights to access them into the sandbox.
Disclaimer: I am a FreeBSD developer, and was visiting cl.cam.uk last week.
Capsicum is very much under active development. It's being used in Cambridge in several projects, funded by DARPA and Google. It is no longer developed on github because it is now merged upstream into FreeBSD. As TFS said, it is part of FreeBSD 9, and the core FreeBSD utilities are slowly being modified to use it (it's easy to incrementally deploy capsicum). If you want up to date documentation, check the man pages.
So, we have our first solid metric: it's 220 times as hard to make Windows secure as it is for BSD or Linux.
BSD or Linux? Check the paper. It took 100 lines of code with Capsicum, 200 with SELinux, 605 with Linux-with-chroot, 11,301 with Linux-with-seccomp and 22,350 with Windows. So (with your metric) it is somewhere between 2 and 10 times as hard to make Windows as secure as Linux and between 2 and 10 times as hard to make Linux as secure as FreeBSD. And the best score for Linux - the SELinux sandbox - requires enabling SELinux which is a massive blob of code and has introduced several of its own security holes in the last couple of years, while Capsicum is much simple and easier to audit.
Did you know its kind of pointless as ChromeOS is a giant fail?
Did you know that ChromeOS (a Linux-based OS) is completely irrelevant in an article about a FreeBSD feature that is now used in Chromium (a web browser)? The only vague relevance is that one of the people mentioned in TFS works on both the Chrome / Chromium and ChromeOS projects. But don't let that get in the way of a good anti-Google rant.
The problem is not that these things are legal - they aren't - it's that the risk/reward ratio is wrong. If you cheat and win, then you get to run the country. If you get caught, you get a slap on the wrist.
I work on a C++ compiler, and I've been playing with the features as they're implemented. Which doesn't answer my question: who is making these '50% code reduction' claims. Nothing I've seen in C++11 makes me think them at all credible.
My example is a trivial example. Go and look at some real code. In big applications, we use this pattern in Objective-C all the time. It's a trivial way of constructing localised strings. Now go and look at the mess of template metaprogramming that people use to do the same thing in C++...
Java is only 5% slower than stripped C++. Java is significantly faster than C++ with the -g flag.
Umm, what? -g / stripping just determines whether the DWARF metadata is in the binary. If you are not running the code in a debugger, then this data just sits on disk and is never touched. If you're on OS X, it's not even in the same file as the executable code by default. If you're finding that it's making a noticeable difference to performance, then you should consider that your benchmarks are being done poorly.
If, on the other hand, you are talking about -O0 (which is usually added with -g), then this can make a huge difference to C++ performance. C++ optimisations are usually pretty destructive towards debugging info, and the difference between unoptimised and optimised C++ is usually at least 50%. Again, if you're not seeing a big difference between a debug and an optimised build, then you're doing it wrong.
Most estimates show that the average code size of a C++11 coded program is half the size of a C++ program
Who is making these estimates? I've been playing with C++11 for a bit (and implemented some parts) and I'd be very surprised to see more than a 10% reduction in size. Unless we're talking about very small projects and counting Boost towards their total code count...
printf() isn't typesafe, but it's a fuckton more readable than all that cout formatting stuff
Readable? Meh. Localisable? Now that is an important attribute. Consider this trivial bit of code:
printf("The %s %s\n", colour, object);
You want to localise this, so you wrap each string in a function that returns the localised version (by the way, gcc and clang have an attribute that you can put on functions that says if the output is safe to use as a format string in any case where the input is). So now you have something that looks like this:
Harder to read? Maybe, but the tokens are all in the order that they'll appear in the output, so I'll give C++ that one. Now let's localise it. How about something like:
That's fine, right? No more complex than the C version. Well, almost. Let's make French the target language. We want to turn 'the black cat' into French. Now we have a problem. In French, the word order is different. The result we want has the colour after the noun. No problem in the C version, the format string is just translated as "Le %2$s %1$s". The arguments are reversed (well, it's a little more complex because you also need agreement between the noun and the article, but I'll skip over that for now - it can be solved in the same way). What about the C++ version? Well, because the word order is in the code, not the data, you need different code paths for English and French. And that's just with a three-word sentence. Now consider the kind of sentence that actually appears in a typical UI. Consider German word-order rules. Your simple C / Objective-C strings file has to be replaced by a huge tangle of C++ code.
No, but the only value that Facebook has is that other people are using it. No one would put pictures on Facebook for private storage, people put them there to share with friends. The fewer of their friends who use Facebook, the less chance there is of this happening.
Facebook can't share anything you don't put on there.
Which is fine for the likes of you and me, who understand that 'put on Facebook' means 'shared with anyone who is willing to pay'. A lot of other people, however, think of Facebook like the postal service. They think that if they put something on Facebook with a limit on who can view it then only those people can view it - that it's essentially private and is protected legally in the same way as something that you put in an envelope and post to your friends. This is the real problem with Facebook: that it gives the illusion of private communication, without the fact.
Don't have your current phone number, IM or email address? They're probably not real friends then. Given how rarely these things change, and how you typically don't change them all at once, someone who you can't be bothered to let know that, since they last talked to you, all of your contact details have changed is probably someone who you don't have any real interest in talking to.
True in some cases, but not always. For example, all of the examples you listed use libicu to provide all of their unicode support on most platforms. Support for things like regular expression matching on unicode strings is very complex (especially if you don't want it to be painfully slow). They may all expose it via different APIs - as you'd hope, since the C APIs don't naturally fit into the patterns of other languages - but they are all calling the same libraries underneath. They're all likely to be using Cairo for 2D graphics. They're all using FreeType for font parsing and glyph generation.
The trick is to do it gradually. You don't make people pay to remove advertising immediately. You give them a useful product, then a bit later you introduce a small, easy to ignore, amount of advertising. Then you give them the option of paying to turn it off. It's easy to ignore, so most people won't bother. You also add some new (minor, easy-to-implement) features or, better yet, a security fix, at the same time, so people will want to get the update. Then you increase the number of ads. Now people are locked into your app or, at the very least, used to using it. Now they'll pay to remove the ads. Repeat and you've got a revenue stream.
This is a small variation of the business model of a lot of proprietary software where you pay for 'major updates' which include features like 'not crashing on launch when you run it on the new version of the OS' or 'not corrupting your documents'.
I've come across this behaviour so many times that I now have a standard reaction: find the open source program that's closest to the proprietary one and give them a donation equal to the cost of the upgrade. The problem is that other people are willing to continue to pay companies that have screwed them over in the past.
What's with the new share link next to the "Reply to This"?
It now hides the obnoxious twitter / facebook / whatever things unless you click on the link. It's not as good as simply not having them at all, but it's better than having them visible on every post.
The problem is in evaluation. It is very difficult to define good metrics for teachers. We've tried a lot of things.
We tried judging on test scores, but this just made teachers coach their students for the test, rather than provide them with a good education.
We've tried judging them on test score deltas, but this just makes teachers concentrate on students who are close to grade boundaries - getting someone from a high C to just scraping a B, but ignoring the ones that could go from a low B to a high B (and then maybe to an A next year).
We've tried judging them based on pupil evaluation, but that just encourages teachers to be lenient on students who don't deserve it, and spend more time trying to be liked than on teaching.
If you have a metric that lets us identify the bad teachers, then please let us know. Education systems around the world would love to use it...
Seriously? Why would you spend $35/month on something you didn't need. Not sure about where you live, but that's a few nights in the pub or a nice meal out a month - I can think of a lot of things I'd rather do with $35 each month than give it to a phone company.
I bought an HTC Desire recently. Hardware's pretty nice, Android sucks, but not appreciably more than any of its competitors. It cost £100. I usually pay about £1-2 for the calls I make. I don't have a data plan: I'm usually either near WiFi or somewhere where I don't care about being online so it's of little benefit to me. With OSMAnd I can store maps on the device, so I can use it for navigation without needing Internet connectivity.
Subscripts and superscripts in TeX work fine in math mode. _{this is subscript} and ^{this is superscript}. For chemistry, you probably want to be typesetting all chemical formulae in math mode, e.g.
Poor old Joe, he's dead and gone\\
His face you'll see no more\\
For what he thought was $H_2O$\\
Was $H_2SO_4$.
Really? Because I used Word 6 in 1995 on a machine with 5MB of RAM. It showed the splash screen for a well over 30 seconds before launching and I couldn't then run an image editor without exiting Word or the machine would thrash and become unusable. Saving a multi-page document would often take 5-10 seconds during which time Word froze. Word 2 was a bit faster (although saving was still slow). Oh, and Word 2 took about 15% of my total hard disk space just for a standard install...
think about the RISC processor. It was developed by the guys at Acorn to run their RISC-OS.
This made me cringe. The RISC processor was developed at UCB. The ARM processor was developed at Acorn, inspired by the RISC processor and the 6502. Given that ARM processors now outsell Intel processors about 10 to 1, I don't think it's so unthinkable.
Also, while some programmers have got lazier, others have not. Many algorithms have got much, much faster.
And those layered APIs that the grandparent complains about make this easier. Now we don't have everyone implementing searching and sorting themselves, someone does it once and it's shoved into a shared library. The same with more complex things like image compositing.
Slashdot Mirror
But at the end of the day its still up to the developer to take advantage of those capabilities.
True, although there are some ways around this. For example, you can quite easily with capscium create an application launcher that opens a set of file descriptors and then execs an untrusted application. It's also relatively easy to integrate this functionality into a filesystem browser or application launcher, so if you try to run an application that is not on a whitelist it will run it in a sandbox. This is likely to appear by default around FreeBSD 10.0.
In UNIX, everything that interacts with anything outside of the process goes via file descriptors. Capsicum provides special file descriptors with capabilities. When you enter capability mode, the kernel no longer allows you to create new arbitrary file descriptors. This means you can't create new sockets, you can't touch the filesystem, and you can't touch any devices. You are completely isolated unless some other process passes you a file descriptor or you create one via a set of special rights. For example, if you have the correct permission, you can use open_at() to create a new file in a directory for which you have a descriptor. This allows you to, for example, set up a sandbox where an application can store files in a per-application location and can use a temporary directory. If it wants to open a socket, it has to ask another process. If it wants to open other files, it has to ask another process. The typical way of handling the second is to have a file-chooser application that allows the user to select files and then passes the rights to access them into the sandbox.
Disclaimer: I am a FreeBSD developer, and was visiting cl.cam.uk last week.
Capsicum is very much under active development. It's being used in Cambridge in several projects, funded by DARPA and Google. It is no longer developed on github because it is now merged upstream into FreeBSD. As TFS said, it is part of FreeBSD 9, and the core FreeBSD utilities are slowly being modified to use it (it's easy to incrementally deploy capsicum). If you want up to date documentation, check the man pages.
So, we have our first solid metric: it's 220 times as hard to make Windows secure as it is for BSD or Linux.
BSD or Linux? Check the paper. It took 100 lines of code with Capsicum, 200 with SELinux, 605 with Linux-with-chroot, 11,301 with Linux-with-seccomp and 22,350 with Windows. So (with your metric) it is somewhere between 2 and 10 times as hard to make Windows as secure as Linux and between 2 and 10 times as hard to make Linux as secure as FreeBSD. And the best score for Linux - the SELinux sandbox - requires enabling SELinux which is a massive blob of code and has introduced several of its own security holes in the last couple of years, while Capsicum is much simple and easier to audit.
Did you know its kind of pointless as ChromeOS is a giant fail?
Did you know that ChromeOS (a Linux-based OS) is completely irrelevant in an article about a FreeBSD feature that is now used in Chromium (a web browser)? The only vague relevance is that one of the people mentioned in TFS works on both the Chrome / Chromium and ChromeOS projects. But don't let that get in the way of a good anti-Google rant.
The problem is not that these things are legal - they aren't - it's that the risk/reward ratio is wrong. If you cheat and win, then you get to run the country. If you get caught, you get a slap on the wrist.
I work on a C++ compiler, and I've been playing with the features as they're implemented. Which doesn't answer my question: who is making these '50% code reduction' claims. Nothing I've seen in C++11 makes me think them at all credible.
My example is a trivial example. Go and look at some real code. In big applications, we use this pattern in Objective-C all the time. It's a trivial way of constructing localised strings. Now go and look at the mess of template metaprogramming that people use to do the same thing in C++...
Java is only 5% slower than stripped C++. Java is significantly faster than C++ with the -g flag.
Umm, what? -g / stripping just determines whether the DWARF metadata is in the binary. If you are not running the code in a debugger, then this data just sits on disk and is never touched. If you're on OS X, it's not even in the same file as the executable code by default. If you're finding that it's making a noticeable difference to performance, then you should consider that your benchmarks are being done poorly.
If, on the other hand, you are talking about -O0 (which is usually added with -g), then this can make a huge difference to C++ performance. C++ optimisations are usually pretty destructive towards debugging info, and the difference between unoptimised and optimised C++ is usually at least 50%. Again, if you're not seeing a big difference between a debug and an optimised build, then you're doing it wrong.
The poor craftsman blames the tools.
The good craftsman picked decent tools before he started.
Most estimates show that the average code size of a C++11 coded program is half the size of a C++ program
Who is making these estimates? I've been playing with C++11 for a bit (and implemented some parts) and I'd be very surprised to see more than a 10% reduction in size. Unless we're talking about very small projects and counting Boost towards their total code count...
printf() isn't typesafe, but it's a fuckton more readable than all that cout formatting stuff
Readable? Meh. Localisable? Now that is an important attribute. Consider this trivial bit of code:
You want to localise this, so you wrap each string in a function that returns the localised version (by the way, gcc and clang have an attribute that you can put on functions that says if the output is safe to use as a format string in any case where the input is). So now you have something that looks like this:
Okay, no problem. Now let's consider the C++ equivalent:
Harder to read? Maybe, but the tokens are all in the order that they'll appear in the output, so I'll give C++ that one. Now let's localise it. How about something like:
That's fine, right? No more complex than the C version. Well, almost. Let's make French the target language. We want to turn 'the black cat' into French. Now we have a problem. In French, the word order is different. The result we want has the colour after the noun. No problem in the C version, the format string is just translated as "Le %2$s %1$s". The arguments are reversed (well, it's a little more complex because you also need agreement between the noun and the article, but I'll skip over that for now - it can be solved in the same way). What about the C++ version? Well, because the word order is in the code, not the data, you need different code paths for English and French. And that's just with a three-word sentence. Now consider the kind of sentence that actually appears in a typical UI. Consider German word-order rules. Your simple C / Objective-C strings file has to be replaced by a huge tangle of C++ code.
No, but the only value that Facebook has is that other people are using it. No one would put pictures on Facebook for private storage, people put them there to share with friends. The fewer of their friends who use Facebook, the less chance there is of this happening.
No, not all politicians. Only the ones that do what he asks. Not all corporate execs. Only the ones that pay him.
Facebook can't share anything you don't put on there.
Which is fine for the likes of you and me, who understand that 'put on Facebook' means 'shared with anyone who is willing to pay'. A lot of other people, however, think of Facebook like the postal service. They think that if they put something on Facebook with a limit on who can view it then only those people can view it - that it's essentially private and is protected legally in the same way as something that you put in an envelope and post to your friends. This is the real problem with Facebook: that it gives the illusion of private communication, without the fact.
Don't have your current phone number, IM or email address? They're probably not real friends then. Given how rarely these things change, and how you typically don't change them all at once, someone who you can't be bothered to let know that, since they last talked to you, all of your contact details have changed is probably someone who you don't have any real interest in talking to.
True in some cases, but not always. For example, all of the examples you listed use libicu to provide all of their unicode support on most platforms. Support for things like regular expression matching on unicode strings is very complex (especially if you don't want it to be painfully slow). They may all expose it via different APIs - as you'd hope, since the C APIs don't naturally fit into the patterns of other languages - but they are all calling the same libraries underneath. They're all likely to be using Cairo for 2D graphics. They're all using FreeType for font parsing and glyph generation.
The trick is to do it gradually. You don't make people pay to remove advertising immediately. You give them a useful product, then a bit later you introduce a small, easy to ignore, amount of advertising. Then you give them the option of paying to turn it off. It's easy to ignore, so most people won't bother. You also add some new (minor, easy-to-implement) features or, better yet, a security fix, at the same time, so people will want to get the update. Then you increase the number of ads. Now people are locked into your app or, at the very least, used to using it. Now they'll pay to remove the ads. Repeat and you've got a revenue stream.
This is a small variation of the business model of a lot of proprietary software where you pay for 'major updates' which include features like 'not crashing on launch when you run it on the new version of the OS' or 'not corrupting your documents'.
I've come across this behaviour so many times that I now have a standard reaction: find the open source program that's closest to the proprietary one and give them a donation equal to the cost of the upgrade. The problem is that other people are willing to continue to pay companies that have screwed them over in the past.
What's with the new share link next to the "Reply to This"?
It now hides the obnoxious twitter / facebook / whatever things unless you click on the link. It's not as good as simply not having them at all, but it's better than having them visible on every post.
The problem is in evaluation. It is very difficult to define good metrics for teachers. We've tried a lot of things.
We tried judging on test scores, but this just made teachers coach their students for the test, rather than provide them with a good education.
We've tried judging them on test score deltas, but this just makes teachers concentrate on students who are close to grade boundaries - getting someone from a high C to just scraping a B, but ignoring the ones that could go from a low B to a high B (and then maybe to an A next year).
We've tried judging them based on pupil evaluation, but that just encourages teachers to be lenient on students who don't deserve it, and spend more time trying to be liked than on teaching.
If you have a metric that lets us identify the bad teachers, then please let us know. Education systems around the world would love to use it...
Seriously? Why would you spend $35/month on something you didn't need. Not sure about where you live, but that's a few nights in the pub or a nice meal out a month - I can think of a lot of things I'd rather do with $35 each month than give it to a phone company.
I bought an HTC Desire recently. Hardware's pretty nice, Android sucks, but not appreciably more than any of its competitors. It cost £100. I usually pay about £1-2 for the calls I make. I don't have a data plan: I'm usually either near WiFi or somewhere where I don't care about being online so it's of little benefit to me. With OSMAnd I can store maps on the device, so I can use it for navigation without needing Internet connectivity.
Poor old Joe, he's dead and gone\\
His face you'll see no more\\
For what he thought was $H_2O$\\
Was $H_2SO_4$.
Really? Because I used Word 6 in 1995 on a machine with 5MB of RAM. It showed the splash screen for a well over 30 seconds before launching and I couldn't then run an image editor without exiting Word or the machine would thrash and become unusable. Saving a multi-page document would often take 5-10 seconds during which time Word froze. Word 2 was a bit faster (although saving was still slow). Oh, and Word 2 took about 15% of my total hard disk space just for a standard install...
think about the RISC processor. It was developed by the guys at Acorn to run their RISC-OS.
This made me cringe. The RISC processor was developed at UCB. The ARM processor was developed at Acorn, inspired by the RISC processor and the 6502. Given that ARM processors now outsell Intel processors about 10 to 1, I don't think it's so unthinkable.
Also, while some programmers have got lazier, others have not. Many algorithms have got much, much faster.
And those layered APIs that the grandparent complains about make this easier. Now we don't have everyone implementing searching and sorting themselves, someone does it once and it's shoved into a shared library. The same with more complex things like image compositing.