Everyone has the power to create debt. Money is just readily transferable debt, which is the entire point of it: I do some work now for someone, and they don't produce anything that I need right now, then they give me some tokens representing the debt. I can use these tokens to exchange for some useful product or service from someone else who doesn't directly want anything that I produce.
Saying that money is backed by debt is a nice libertarian talking point, but it doesn't actually convey any information. Money exists so that you can balance unequal trades with a promise that they will be equalised in the future, and any promise of future balance is debt.
There's an old stock market scam. You open 100 accounts. You invest randomly. After a week, roughly half will be turning a profit. You close the ones that aren't, and do another round of random investing. Again, roughly half make a loss, half a profit. After a few rounds of this, you have lost quite a lot of money, but you have one account that looks really stellar - huge returns on investment. You then open this up to investment, with the disclaimer that past performance does not guarantee future results, and wait for the money to roll in (you can then invest this in your own companies, or just take it and run away).
Much the same applies with CEOs. You take a few thousand business graduates each year and put them in management positions. They all make random decisions. Then you cherry pick the handful that have made decisions that turned out well. Then you say 'Superstar CEO, please pay enormous salary'.
The counter argument to this is simple: Memory allocations accounts for 99% of all scarce resource allocation in a typical program (and all of the resources that they're actually likely to exhaust: when was the last time you saw a program that had so many file descriptors open at once that it was hard to keep track of them and they came anywhere close to the system limit? It happens, but in very unusual code). Saying 'well, I have to do it for 1%, I may as well do it for the other 99%' is really not a very compelling argument.
Given their recent track record, I'd trust ICANN under its current leadership significantly less than the UN, the Russian Mafia, or a random homeless guy.
The problem is, adding a copyright notice when you are not the copyright holder is legally dubious, and so if there isn't one in the file you have to maintain the license information separately. This leads to a load of LICENSE.GPL, LICENSE.LGPL, LICENSE.BSD, and so on files in your tree, and separate lists of which files each relate to. It saves everyone time to just stick your license template in the top of every new file that you create.
Clang/LLVM does not include any libc. All of the BSDs, however, ship their own (BSD licensed) libc. The libc in Android is mostly code from FreeBSD libc.
Not having a license on every file is a colossal pain for people wanting to take part of your code and integrate it into something else. I recently went through this with OpenIndiana: they wanted to take some of my code from another project and include it in their libc. This is fine - the license I'm using is more permissive than their libc so there's no legal problem - but I'd forgotten to include the license text in the file, I'd only put it in a LICENSE file in the repository root. Keeping track of the license for one file that is different from the others in the project imposes a burden for them and, without the copyright in the file, potentially means that others will grab that file and think it's under a different license.
In short: Please put licenses in files. It makes life much easier for anyone wanting to use your code. If you don't want people to use your code, then you can save effort by not publishing it in the first place.
David F Bacon designed some GCs for realtime applications that used reference counting with deferred cycle detection. The longer you defer cycle detection for, the higher the probability that the object will already have been proven to be non-garbage (by having its reference count incremented again) or garbage (by having its reference count reach 0 and it being collected). The trade for this is that it increases the maximum time for the cycle detector to run. You can adjust the delay based on the latency constraints of your application.
In principle, Objective C the language can be used for dynamic binding; in practice, the Objective C runtime, as represented in crt1.o, and in the dyld and later dyle dynamic linkers, it can't be. This was an intentional decision by Apple to prevent a dynamic binding override from changing aspects of the UI, and to prevent malicious code being injected into your program - this is a position Apple strengthened by adding code signing.
I have to wonder what you're talking about here. First of all, the Objective-C runtime is not in crt1.o. This contains some symbols that allow dyld to find things in the executable. The Objective-C runtime is in libobjc.dyld. Every message send (method invocation) in Objective-C goes via one of the objc_msgSend() family of functions and these all do late binding. You can define a category on a system class and override methods, or you can use method swizzling via explicit APIs such as class_replaceMethod(). Apple does absolutely nothing to stop this, because the OS X and iOS security model does not depend on the integrity of system shared libraries within a process. It is based on the MAC framework from FreeBSD and enforces limits on interactions of the process with the wider system. A process is free to do whatever it wants within its own address space without violating the security model.
The core issue is that GC vs no GC is a false dichotomy. You can't get away without GC, the question is whether you use a general-purpose algorithm, like tracing or reference counting with cycle detection, or a special-purpose design. This is especially true on mobile: if a desktop application leaks memory then it will take a while to fill up swap, but it might not be noticed. Apple provides a very coarse-grained automatic GC for iOS: applications notify the OS that they have no unsaved data and then can be kill -9'd in the background and restarted on demand. They also provide reference counting (with explicit cycle breaking via weak references, no automatic cycle collection) as a tool for developers to build per-application memory management strategies. Android, in contrast, provides a finer-grained automatic GC based on generational tracing.
It confuses me that many of the advocates of avoiding automatic GC seem to follow a train of reasoning something like this:
Memory management is a hard problem.
Therefore, we can't trust a team of skilled programmers to get a general solution right.
Therefore, we will trust every average developer to get it right.
Most of the time, GC can be cleanly integrated with event delivery in interactive applications: you set the GC to only collect if memory is exhausted while handling an event and allow application memory to grow, and you then do a more aggressive collection when there are no pending events. This doesn't work for large multiuser server applications, because they can easily do a few hundred GBs of allocations in between idle periods, but it's surprisingly effective for typical desktop and mobile apps.
You know, first well-know "harsh" conversation from Linus was the one with Tanembaum, if you see my point
The one where the person that now develops a kernel that ships with FUSE and CUSE, and which has its largest install base running on top of the Xen microkernel in cloud deployments or an L4-derived microkernel in mobile deployments, was saying that microkernels are bad?
Someone recently cc'd him on a post on the LLVM mailing list, and he decided to chime in with a long rant where he was both rude and technically incorrect. It made me very glad that I don't use Linux, and just that little bit less likely to respond to bug reports that only affect people who do. Meanwhile, I recently got a bug report from one of the OpenBSD developers (a community with a reputation for being somewhat... acerbic). It was detailed, polite, and proposed two possible fixes. It was followed up by testing of the fix that I proposed. I don't use OpenBSD either, but I'm a lot more likely to fix bugs for people who do because this report was characteristic of my interactions with their developers.
Using.local is a bad idea, because it's also the domain used for mDNS. This caused quite a few places problems when they started getting Macs with mDNS support appearing on the network. Now most operating systems support it, so people have had to work around it. For a while, some systems were putting.local in the search domains list, which made things all sorts of fun...
That seems to be a fairly recent thing. The 1903 edition of Websters lists two definitions for ass: a donkey and a stupid person. This is pretty much in keeping with English usage. The conflating of ass and arse is more recent.
Exporting encryption has not been illegal in the USA for some time. Certain forms of encryption, however, are still illegal to export to countries under arms embargoes.
ZFS RAM usage depends on the size of your pool, whether you need deduplication, and your performance needs. The rule of thumb for ZFS is 1GB of RAM per TB of storage, 2GB if you want deduplication. This, however, assumes that you are using mechanical disks and either using the pool locally or via something like iSCSI over GigE. If you're using it over WiFi, then you can get away with a really small ARC, because a cache miss won't slow things down that much, especially if the miss is filled by something that can do random reads quickly.
I don't have the glibc sources to hand, but du in/usr/src/lib/libc on FreeBSD tells me that the libc sources are around 13MB./usr/src/lib/msun (the libm sources) are another 1.9MB.
Wow, that's the most oversimplified attempt at discussing economics I've seen for a long time. Hint: economics is complicated - if it were easy we'd have a simple working system that everyone could agree one (or, at least, the people who worked out out would get very rich by betting on the economy 100% correctly and other people would notice) - and any explanation that simple is likely to be wrong.
Consider the following counter example:
The government builds and maintains a road between two places. This employs people, taking them out of the labour pool where they could be doing other things, so it's a cost. But it also allows the two places to trade more cheaply, which increases wealth production. Similarly, employers at either end of the road would have access to a wider pool of employees and potential employees to a wider pool of employers and so people would end up in more productive employment.
Now, would the same apply if private industry built the road? This is where it starts to get more complicated. First, who would build the road? It might be some consortium of businesses at both ends who wanted to use it. If so, then they might charge money to anyone not part of the consortium to use it, which would give them a competitive advantage, but be less healthy for the economy as a whole by producing a barrier to competition (and, most specifically, a barrier to entry for new companies).
It might be a third party that thought that the road would be profitable, who would run it as a 'common carrier' toll road. This, however, would provide a disincentive for people to use it. If they priced it too low, then they'd go out of business (which would discourage future road-building companies). If they priced it too high, then they'd make it unprofitable for some users to use it, however given that the cost of the road is now a sunk cost the economy as a whole benefits if as many people as would gain any benefit at all from it use it.
In some cases, the benefit to the economy may be significantly lower than the cost of the road, so it would not make sense for the government to make the investment. It's often difficult to make that call, however. In the UK, be Beeching Report identified a large number of unprofitable railway lines and, to save taxpayer money, the nationalised railway service closed them. Unfortunately, it turned out that a lot of the unprofitable lines were ones that got people from near where they lived to a more profitable line. When they were closed, people at the edges ended up having to buy cars, which meant that they no longer used the larger lines either, and so pushed those into unprofitability (and so there was a second Beeching Report some years later which repeated the entire mistake). The cost to the economy of no longer having a widespread, cheap, railway network is widely agreed by economists to be significantly greater than the savings from closing the lines.
A nationally owned private rail operator may have seen further ahead, but most likely they'd have had shareholders making the same demands: sell off the unprofitable lines and concentrate on the profitable ones. A larger number of smaller railway operators would have had similar problems, with the ones operating the unprofitable lines going out of business and reducing demand on the profitable ones.
Take a look at C++11, it's pretty hideous. It works, as long as you make sure that everything you use in the closure is either copied or a smart pointer, but you have to be pretty careful not to end up with cycles.
The problem is mostly one of marketing. If you're a top tier university, students will trust that teaching you Scheme or whatever is sensible because you've got a good reputation. If you're a second tier university, then students (and parents) have heard of Java and C# and know that industry likes them, and if one university uses them as a teaching language but you don't, then it's hard to convince them that it really does make sense. And your reputation is dependent on how well your former students do, which depends on the quality of your intake.
Slashdot Mirror
Everyone has the power to create debt. Money is just readily transferable debt, which is the entire point of it: I do some work now for someone, and they don't produce anything that I need right now, then they give me some tokens representing the debt. I can use these tokens to exchange for some useful product or service from someone else who doesn't directly want anything that I produce.
Saying that money is backed by debt is a nice libertarian talking point, but it doesn't actually convey any information. Money exists so that you can balance unequal trades with a promise that they will be equalised in the future, and any promise of future balance is debt.
The City never sleeps, but sometimes the people do. And then the City eats them.
There's an old stock market scam. You open 100 accounts. You invest randomly. After a week, roughly half will be turning a profit. You close the ones that aren't, and do another round of random investing. Again, roughly half make a loss, half a profit. After a few rounds of this, you have lost quite a lot of money, but you have one account that looks really stellar - huge returns on investment. You then open this up to investment, with the disclaimer that past performance does not guarantee future results, and wait for the money to roll in (you can then invest this in your own companies, or just take it and run away).
Much the same applies with CEOs. You take a few thousand business graduates each year and put them in management positions. They all make random decisions. Then you cherry pick the handful that have made decisions that turned out well. Then you say 'Superstar CEO, please pay enormous salary'.
The counter argument to this is simple: Memory allocations accounts for 99% of all scarce resource allocation in a typical program (and all of the resources that they're actually likely to exhaust: when was the last time you saw a program that had so many file descriptors open at once that it was hard to keep track of them and they came anywhere close to the system limit? It happens, but in very unusual code). Saying 'well, I have to do it for 1%, I may as well do it for the other 99%' is really not a very compelling argument.
Given their recent track record, I'd trust ICANN under its current leadership significantly less than the UN, the Russian Mafia, or a random homeless guy.
So, did the person submitting this request own the copyright to the VLC media player?
The problem is, adding a copyright notice when you are not the copyright holder is legally dubious, and so if there isn't one in the file you have to maintain the license information separately. This leads to a load of LICENSE.GPL, LICENSE.LGPL, LICENSE.BSD, and so on files in your tree, and separate lists of which files each relate to. It saves everyone time to just stick your license template in the top of every new file that you create.
Clang/LLVM does not include any libc. All of the BSDs, however, ship their own (BSD licensed) libc. The libc in Android is mostly code from FreeBSD libc.
Not having a license on every file is a colossal pain for people wanting to take part of your code and integrate it into something else. I recently went through this with OpenIndiana: they wanted to take some of my code from another project and include it in their libc. This is fine - the license I'm using is more permissive than their libc so there's no legal problem - but I'd forgotten to include the license text in the file, I'd only put it in a LICENSE file in the repository root. Keeping track of the license for one file that is different from the others in the project imposes a burden for them and, without the copyright in the file, potentially means that others will grab that file and think it's under a different license.
In short: Please put licenses in files. It makes life much easier for anyone wanting to use your code. If you don't want people to use your code, then you can save effort by not publishing it in the first place.
Care to explain why I'm wrong? You have to collect garbage somehow (unless you are using an infinitely long tape instead of RAM).
David F Bacon designed some GCs for realtime applications that used reference counting with deferred cycle detection. The longer you defer cycle detection for, the higher the probability that the object will already have been proven to be non-garbage (by having its reference count incremented again) or garbage (by having its reference count reach 0 and it being collected). The trade for this is that it increases the maximum time for the cycle detector to run. You can adjust the delay based on the latency constraints of your application.
In principle, Objective C the language can be used for dynamic binding; in practice, the Objective C runtime, as represented in crt1.o, and in the dyld and later dyle dynamic linkers, it can't be. This was an intentional decision by Apple to prevent a dynamic binding override from changing aspects of the UI, and to prevent malicious code being injected into your program - this is a position Apple strengthened by adding code signing.
I have to wonder what you're talking about here. First of all, the Objective-C runtime is not in crt1.o. This contains some symbols that allow dyld to find things in the executable. The Objective-C runtime is in libobjc.dyld. Every message send (method invocation) in Objective-C goes via one of the objc_msgSend() family of functions and these all do late binding. You can define a category on a system class and override methods, or you can use method swizzling via explicit APIs such as class_replaceMethod(). Apple does absolutely nothing to stop this, because the OS X and iOS security model does not depend on the integrity of system shared libraries within a process. It is based on the MAC framework from FreeBSD and enforces limits on interactions of the process with the wider system. A process is free to do whatever it wants within its own address space without violating the security model.
The core issue is that GC vs no GC is a false dichotomy. You can't get away without GC, the question is whether you use a general-purpose algorithm, like tracing or reference counting with cycle detection, or a special-purpose design. This is especially true on mobile: if a desktop application leaks memory then it will take a while to fill up swap, but it might not be noticed. Apple provides a very coarse-grained automatic GC for iOS: applications notify the OS that they have no unsaved data and then can be kill -9'd in the background and restarted on demand. They also provide reference counting (with explicit cycle breaking via weak references, no automatic cycle collection) as a tool for developers to build per-application memory management strategies. Android, in contrast, provides a finer-grained automatic GC based on generational tracing.
It confuses me that many of the advocates of avoiding automatic GC seem to follow a train of reasoning something like this:
Most of the time, GC can be cleanly integrated with event delivery in interactive applications: you set the GC to only collect if memory is exhausted while handling an event and allow application memory to grow, and you then do a more aggressive collection when there are no pending events. This doesn't work for large multiuser server applications, because they can easily do a few hundred GBs of allocations in between idle periods, but it's surprisingly effective for typical desktop and mobile apps.
Good idea. By the way Sarah, over at the FreeBSD project, we try to treat developers with respect and would welcome contributions to our USB stack...
You know, first well-know "harsh" conversation from Linus was the one with Tanembaum, if you see my point
The one where the person that now develops a kernel that ships with FUSE and CUSE, and which has its largest install base running on top of the Xen microkernel in cloud deployments or an L4-derived microkernel in mobile deployments, was saying that microkernels are bad?
Someone recently cc'd him on a post on the LLVM mailing list, and he decided to chime in with a long rant where he was both rude and technically incorrect. It made me very glad that I don't use Linux, and just that little bit less likely to respond to bug reports that only affect people who do. Meanwhile, I recently got a bug report from one of the OpenBSD developers (a community with a reputation for being somewhat... acerbic). It was detailed, polite, and proposed two possible fixes. It was followed up by testing of the fix that I proposed. I don't use OpenBSD either, but I'm a lot more likely to fix bugs for people who do because this report was characteristic of my interactions with their developers.
Using .local is a bad idea, because it's also the domain used for mDNS. This caused quite a few places problems when they started getting Macs with mDNS support appearing on the network. Now most operating systems support it, so people have had to work around it. For a while, some systems were putting .local in the search domains list, which made things all sorts of fun...
That seems to be a fairly recent thing. The 1903 edition of Websters lists two definitions for ass: a donkey and a stupid person. This is pretty much in keeping with English usage. The conflating of ass and arse is more recent.
Exporting encryption has not been illegal in the USA for some time. Certain forms of encryption, however, are still illegal to export to countries under arms embargoes.
ZFS RAM usage depends on the size of your pool, whether you need deduplication, and your performance needs. The rule of thumb for ZFS is 1GB of RAM per TB of storage, 2GB if you want deduplication. This, however, assumes that you are using mechanical disks and either using the pool locally or via something like iSCSI over GigE. If you're using it over WiFi, then you can get away with a really small ARC, because a cache miss won't slow things down that much, especially if the miss is filled by something that can do random reads quickly.
I don't have the glibc sources to hand, but du in /usr/src/lib/libc on FreeBSD tells me that the libc sources are around 13MB. /usr/src/lib/msun (the libm sources) are another 1.9MB.
Wow, that's the most oversimplified attempt at discussing economics I've seen for a long time. Hint: economics is complicated - if it were easy we'd have a simple working system that everyone could agree one (or, at least, the people who worked out out would get very rich by betting on the economy 100% correctly and other people would notice) - and any explanation that simple is likely to be wrong.
Consider the following counter example:
The government builds and maintains a road between two places. This employs people, taking them out of the labour pool where they could be doing other things, so it's a cost. But it also allows the two places to trade more cheaply, which increases wealth production. Similarly, employers at either end of the road would have access to a wider pool of employees and potential employees to a wider pool of employers and so people would end up in more productive employment.
Now, would the same apply if private industry built the road? This is where it starts to get more complicated. First, who would build the road? It might be some consortium of businesses at both ends who wanted to use it. If so, then they might charge money to anyone not part of the consortium to use it, which would give them a competitive advantage, but be less healthy for the economy as a whole by producing a barrier to competition (and, most specifically, a barrier to entry for new companies).
It might be a third party that thought that the road would be profitable, who would run it as a 'common carrier' toll road. This, however, would provide a disincentive for people to use it. If they priced it too low, then they'd go out of business (which would discourage future road-building companies). If they priced it too high, then they'd make it unprofitable for some users to use it, however given that the cost of the road is now a sunk cost the economy as a whole benefits if as many people as would gain any benefit at all from it use it.
In some cases, the benefit to the economy may be significantly lower than the cost of the road, so it would not make sense for the government to make the investment. It's often difficult to make that call, however. In the UK, be Beeching Report identified a large number of unprofitable railway lines and, to save taxpayer money, the nationalised railway service closed them. Unfortunately, it turned out that a lot of the unprofitable lines were ones that got people from near where they lived to a more profitable line. When they were closed, people at the edges ended up having to buy cars, which meant that they no longer used the larger lines either, and so pushed those into unprofitability (and so there was a second Beeching Report some years later which repeated the entire mistake). The cost to the economy of no longer having a widespread, cheap, railway network is widely agreed by economists to be significantly greater than the savings from closing the lines.
A nationally owned private rail operator may have seen further ahead, but most likely they'd have had shareholders making the same demands: sell off the unprofitable lines and concentrate on the profitable ones. A larger number of smaller railway operators would have had similar problems, with the ones operating the unprofitable lines going out of business and reducing demand on the profitable ones.
Take a look at C++11, it's pretty hideous. It works, as long as you make sure that everything you use in the closure is either copied or a smart pointer, but you have to be pretty careful not to end up with cycles.
The problem is mostly one of marketing. If you're a top tier university, students will trust that teaching you Scheme or whatever is sensible because you've got a good reputation. If you're a second tier university, then students (and parents) have heard of Java and C# and know that industry likes them, and if one university uses them as a teaching language but you don't, then it's hard to convince them that it really does make sense. And your reputation is dependent on how well your former students do, which depends on the quality of your intake.
The key word there is 'properly implemented'. This, it turns out, is very hard and a lot of people get it wrong.