To be fair, science is effectively a belief system
Absolutely not. Belief systems say 'this is true'. Science says 'this is a story, and if we accept this story is true then we get these useful predictions out. If we find that the predictions are not true, then we need to reevaluate the story. In some cases (e.g. Newtonian motion), the predictions may still be useful, as they still work within a particular range and the story is simpler to understand than one that gives accurate predictions everywhere, but we still accept that it's wrong. If there is no story we can think of that correctly matches our observations, then it's fine to admit ignorance.'
As an example of how this institution has varied, consider that in the mid nineteenth century in England it was considered legal for a man to try to sell his wife.
And from that link:
Although the custom had no basis in law and frequently resulted in prosecution, particularly from the mid-19th century onwards
And the other big one: you don't need collaborators. One of the things that tempted me back into academia was that a lot of the problems that I'd encountered really needed expertise in fields complementary to my own. I could spend 5-10 years learning everything I needed to solve them (by which time they'd likely be irrelevant or solved by someone else), or I could work with other people, many of whom also have interesting problems that can benefit from my experience. There are increasingly few fields where you can make a significant contribution by yourself.
I came a slightly unusual route, getting my PhD quite quickly and then spending five years freelancing, before being tempted back to academia. Oh, and I'm in the UK - it's a bit different in the USA. The base salary for a postdoc is not too exciting, but there are a few other things that make it attractive.
The first is that you get a lot more freedom than as a PhD student (or a junior employee in a corporate R&D lab). You start to be able to set your own research agenda. This depends a lot on institutions, but where I work there are a couple of projects with multi million dollar funding that are led by postdocs (a tenured faculty member has to be the name on the grant, but it's purely nominal). You may be able to supervise PhD students.
The second is the flexible working hours. I have a few hours a week when I actually need to be in the lab. The rest of the time, as long as I'm not blocking anyone else from getting things done, no one cares where I am (or what I'm doing, as long as some papers come out periodically).
The third is that I get to play with some very shiny toys. I'm typing this from a latest-generation MacBook Pro with all of the upgrades (2.6GHz CPU, 1TB SSD), which the lab bought for me yesterday, but that isn't too unusual for corporate side. Slightly more unusual is that when I started working here the only thing thing on my desk was an $8,000 FPGA board, which is just about to be replaced by a better one, and there's a big box of them if I need more than one (we're starting to play with boxes with 4 of the newer boards). The same thing extends to travel budgets. I've had a few months over the last year where I've claimed more in expenses than salary (which is less impressive when you remember the postdoc salary), and every time I go on a trip it's fairly common to tack some vacation time on. I don't really have to justify travel much beyond saying 'I'd like to visit this conference / university, it's probably sensible,' although part of that is the combination of funding rules that make it difficult to spend grant money on things that are not travel.
The fourth is that you are not limited to the working for the university. Most companies that want you to work full time expect you to work entirely for them. When I asked about consulting in my interview here, the reply was that of course they expected me to consult, how else would I stay up to date with trends in industry? You can add quite a lot (100% isn't too unusual) to your postdoc salary by consulting, and the flexible working hours make this very easy.
I interviewed at Google at the same time as I interviewed here. Google offered me quite a bit more money, but I don't regret making the choice I did. If you're thinking of a postdoc as a way of becoming more employable, then you're probably doing it wrong (unless you're aiming for a lectureship or a senior post in industrial R&D), but if you're looking on it as a way of being paid to have fun then it's a good deal. I'm basically doing now the things that I was doing in my spare time before, but now I have a lot more resources and I get paid for it. It sure beats working for a living...
Oh, and the $50K number you quote is close to the base salary for a postdoc here. It goes up to around $75K. I just checked a salary comparison site and apparently the postdoc salary is about the same as a software engineer would expect to be paid here, and about double the median salary.
MS Office also has change tracking and can show you who made which changes to a document. It works well, except if you have more than one document, in which case tying versions together is very hard. Oh, and there's no merging support, so you can't have two people independently editing a document. Oh, and you can't split documents up for different people to work on different sections, because then cross-references break.
But that's probably okay, because no enterprise actually has more than one employee or one document....
How do you know if your employees like it if they don't use it? It's a big part of the reason for this kind of mandate: you have a large pool of people internally who can tell you if the product sucks, but only if they actually use it.
The posited advantage of an hereditary monarchy is not so much that the new is the son of the old ruler, it's that he is raised from birth to rule adn the responsibilities that this entails. This can be a better idea than having someone with a sufficiently big ego to decide that they ought to be in power. The first problem is that you don't have a good fallback - if the next in line to the throne is a poor choice then ideally you'd have a dozen other candidates to pick from. The second is that monarchies traditionally don't provide a good way of deselecting the ruler. Perhaps the biggest selling point of democracy is that you get to have a revolution and overthrow the government every few years, without anyone having to die.
And the problem here is awarding academic funding to people because they're good at non-academic activities. How about decoupling them entirely? Seems to work everywhere else...
Executives are paid high salaries because (good ones at least) are sought after
There are a very small number of truly exceptional C?Os and most of those know a single industry very well and do badly when translated to other markets. According to a study that was on Slashdot a couple of years ago, the vast majority make decisions that are no better for the company that a random selection. You can replace most Fortune 500 CEOs with a magic 8 ball and get about the same performance. That's not true of most of the other employees, including the janitors, so why are they paid several orders of magnitude more? Because most of the CEOs are on the boards of other companies and approve large salaries in exchange for the same favour being paid to them.
With a ground-pointing camera and an estimation of altitude you can use feature detection to get a moderately accurate estimate of speed. This won't work if you're above the clouds, but if you are then doing the same thing with the clouds will give you a rough estimate of air speed, as clouds are approximately stationary relative to the air that contains them.
BeOS 5 is not easy to compromise remotely because the network stack crashes under load, or after a few minutes of low load. Does Haiku have the same feature?
The grid losses are about 7%, but that's because the distances are kept quite small. Most consumers are in the same state as their power stations, and often a lot closer. There's a reason power stations are built quiet close to cities. Try powering the coasts from a solar array in the middle of the USA and you'll see much bigger losses. And the middle of the USA is exactly where you want to have large-scale solar collectors: where you have lots of empty space with lots of sunshine.
Solar is not great for powering the grid, where the supply and demand must be balanced and where you want to put the supply and demand close together to minimise transmission losses. It's much better for workloads that are effectively charging batteries. If you stick big solar collectors in the middle of the desert, connecting that up to the grid for the rest of the USA is pretty difficult and you'll still have the problem that there are big demand spikes just as the solar sun starts to set. In contrast, if it's all producing hydrogen (or charging batteries), then you can build up a small surplus to cover times when demand spikes above production temporarily and you just need pipes to ship the water in and trains to ship the power out.
There's a difference, which is that most crappy corporate software isn't attempting to define standards and a platform for everyone else to build on top of. OpenStack claims to be developing a vendor-agnostic standard and reference implementation for interoperable systems.
With multiple file systems per drive, a given file system doesn't necessarily know the drive is idle so some other process would need to do the delayed TRIM which is what Canonical is suggesting.
Why would a filesystem need to know? On FreeBSD, the filesystem just spits a BIO_DELETE command into the GEOM layer, and it is up to GEOM to schedule when to dispatch it - it's free to reorder it, as long as it doesn't move it after a BIO_WRITE with an overlapping range. If the filesystem needs to know about the status of other filesystems then that's a serious layering problem. The FS should not be making the decision about whether to send the BIO_DELETE, because it's the responsibility of something lower down the stack to decide what to do with it. For example, a RAM disk can use it to free the underlying memory. You don't want every filesystem to have to know about every possible kind of device.
And TRIM is enabled by default on OS X if you use the stock drives. If you use an after-market replacement then you do need to explicitly enable it (which sucks). With FreeBSD, it's enabled for UFS by default since 9.0 and ZFS by default since 9.2. It is also enabled in software raid configurations by default in 10.0. I'm very surprised Linux doesn't enable it by default.
Because that would require the flash to do deduplication and know that the blocks were full of FF and so could be copy-on-write (and, in your scheme, block-level compression). You're thinking of an SSD as if it were a big RAM chip, full of blocks of flash with a simple addressing scheme. It isn't. It's a load of flash cells, which wear out over time, and a very complicated controller that maps blocks to cells. The point of TRIM is not to erase the block, it is to remove the block from the remapping tables so that that the wear levelling knows it has an unused block that can be erased whenever it makes sense to do so. The erasure happens on a cell granularity, and cells are some multiple of the block size (not sure what they are these days, probably 64-128KB). Knowing that all blocks in a cell are free is great, because the controller can then erase the entire cell. Knowing that only one block is in use and it hasn't been modified for a while means that it can defragment by erasing one cell, moving the individual infrequently modified blocks to that cell, and then add their old cells to the free list for erasure.
It's also worth noting that there are two modes for TRIM. One enforces the invariant that two reads of the same block will give the same value if there are no writes between them, the other only requires this invariant for blocks that have not been marked as erased. There's often a performance difference between them, because the latter lets the drive just leave the block as spare and overwrite it during a GC and then reallocate it on write (a good implementation would mark it as zero'd and always return zeros until there is a write, but this requires slightly more space in the remapping tables and so isn't always done). It sounds like Linux is still using the former version, which can be very slow on some drives.
Bitcoins have experienced drops in value over the course of a single day that are greater than the drop in value of the US dollar over the entire great depression, or its total deflation over the last 100 years. It's not cratering because it's value is effectively a random number and it will keep going up for as long as people are making money from the wild fluctuations in value of an unregulated instrument. When the big speculators cash out and the rest realise that they just own a magic number that no one with significant assets has ever promised to accept in payment, you'll see what cratering really means.
And yet SELinux went in. And if you look at the last decade of CVEs for the Linux kernel, see how many come with the note 'Does not affect users not using SELinux'. A great many of them were in the null pointer dereference checker, and were an entire category of exploit that was unknown until the NSA contributed SELinux. But, sure, go on believing that Linus keeps you safe from the NSA if that makes you happy.
If I make a web page that crashes IE6, am I at fault?
If you make a web site and it happens to crash IE6, then you're not at fault. If you make a web site that intentionally crashes IE6 and encourage IE6 users to visit it, then I don't see why it would be treated any differently from any other DoS attack. If I find a bug that crashes Apache from a malformed URL and then stick a link to someone's Apache server with such a URL on my web page, I don't think there's any doubt that it's malicious.
In the case of Google, they intentionally exploited a security hole in Safari to collect information about the user. This seems like something that is a pretty clear cut case of violating whatever the US equivalent of the Computer Misuse Act is. $17m seems like a very low fine considering the number of people who were affected. It's under $1 per incident, which doesn't seem enough to discourage a company like Google.
Can I now sue Verizon for crapwares that make my phone vulernable?
If they install them for the purpose of making your phone vulnerable, yes. If they exploit the holes introduced by the crapware for profit (or for other purposes), then yes.
I guess I am asking others: What line the sand did Google step across?
They identified a vulnerability in a piece of software, and instead of reporting it they decided to exploit it.
More specifically, Apple does not and never has allowed GPLv3 code into the building. They're not stripping out GPLv3 code, they're staying with old versions of projects that switched to GPLv3 until a permissively licensed replacement is finished. This is not a strategy exclusive to Apple - a lot of companies were unhappy with GPLv2 and now find GPLv3 quite scary. We've had quite a few companies start to contribute to FreeBSD and related projects as a result of GPLv3.
Slashdot Mirror
In Wales, the charge has been in place for over a year.
To be fair, science is effectively a belief system
Absolutely not. Belief systems say 'this is true'. Science says 'this is a story, and if we accept this story is true then we get these useful predictions out. If we find that the predictions are not true, then we need to reevaluate the story. In some cases (e.g. Newtonian motion), the predictions may still be useful, as they still work within a particular range and the story is simpler to understand than one that gives accurate predictions everywhere, but we still accept that it's wrong. If there is no story we can think of that correctly matches our observations, then it's fine to admit ignorance.'
As an example of how this institution has varied, consider that in the mid nineteenth century in England it was considered legal for a man to try to sell his wife.
And from that link:
Although the custom had no basis in law and frequently resulted in prosecution, particularly from the mid-19th century onwards
And the other big one: you don't need collaborators. One of the things that tempted me back into academia was that a lot of the problems that I'd encountered really needed expertise in fields complementary to my own. I could spend 5-10 years learning everything I needed to solve them (by which time they'd likely be irrelevant or solved by someone else), or I could work with other people, many of whom also have interesting problems that can benefit from my experience. There are increasingly few fields where you can make a significant contribution by yourself.
Teaching classes is a lot of fun when you have good students...
The first is that you get a lot more freedom than as a PhD student (or a junior employee in a corporate R&D lab). You start to be able to set your own research agenda. This depends a lot on institutions, but where I work there are a couple of projects with multi million dollar funding that are led by postdocs (a tenured faculty member has to be the name on the grant, but it's purely nominal). You may be able to supervise PhD students.
The second is the flexible working hours. I have a few hours a week when I actually need to be in the lab. The rest of the time, as long as I'm not blocking anyone else from getting things done, no one cares where I am (or what I'm doing, as long as some papers come out periodically).
The third is that I get to play with some very shiny toys. I'm typing this from a latest-generation MacBook Pro with all of the upgrades (2.6GHz CPU, 1TB SSD), which the lab bought for me yesterday, but that isn't too unusual for corporate side. Slightly more unusual is that when I started working here the only thing thing on my desk was an $8,000 FPGA board, which is just about to be replaced by a better one, and there's a big box of them if I need more than one (we're starting to play with boxes with 4 of the newer boards). The same thing extends to travel budgets. I've had a few months over the last year where I've claimed more in expenses than salary (which is less impressive when you remember the postdoc salary), and every time I go on a trip it's fairly common to tack some vacation time on. I don't really have to justify travel much beyond saying 'I'd like to visit this conference / university, it's probably sensible,' although part of that is the combination of funding rules that make it difficult to spend grant money on things that are not travel.
The fourth is that you are not limited to the working for the university. Most companies that want you to work full time expect you to work entirely for them. When I asked about consulting in my interview here, the reply was that of course they expected me to consult, how else would I stay up to date with trends in industry? You can add quite a lot (100% isn't too unusual) to your postdoc salary by consulting, and the flexible working hours make this very easy.
I interviewed at Google at the same time as I interviewed here. Google offered me quite a bit more money, but I don't regret making the choice I did. If you're thinking of a postdoc as a way of becoming more employable, then you're probably doing it wrong (unless you're aiming for a lectureship or a senior post in industrial R&D), but if you're looking on it as a way of being paid to have fun then it's a good deal. I'm basically doing now the things that I was doing in my spare time before, but now I have a lot more resources and I get paid for it. It sure beats working for a living...
Oh, and the $50K number you quote is close to the base salary for a postdoc here. It goes up to around $75K. I just checked a salary comparison site and apparently the postdoc salary is about the same as a software engineer would expect to be paid here, and about double the median salary.
MS Office also has change tracking and can show you who made which changes to a document. It works well, except if you have more than one document, in which case tying versions together is very hard. Oh, and there's no merging support, so you can't have two people independently editing a document. Oh, and you can't split documents up for different people to work on different sections, because then cross-references break. But that's probably okay, because no enterprise actually has more than one employee or one document....
How do you know if your employees like it if they don't use it? It's a big part of the reason for this kind of mandate: you have a large pool of people internally who can tell you if the product sucks, but only if they actually use it.
The posited advantage of an hereditary monarchy is not so much that the new is the son of the old ruler, it's that he is raised from birth to rule adn the responsibilities that this entails. This can be a better idea than having someone with a sufficiently big ego to decide that they ought to be in power. The first problem is that you don't have a good fallback - if the next in line to the throne is a poor choice then ideally you'd have a dozen other candidates to pick from. The second is that monarchies traditionally don't provide a good way of deselecting the ruler. Perhaps the biggest selling point of democracy is that you get to have a revolution and overthrow the government every few years, without anyone having to die.
And the problem here is awarding academic funding to people because they're good at non-academic activities. How about decoupling them entirely? Seems to work everywhere else...
Executives are paid high salaries because (good ones at least) are sought after
There are a very small number of truly exceptional C?Os and most of those know a single industry very well and do badly when translated to other markets. According to a study that was on Slashdot a couple of years ago, the vast majority make decisions that are no better for the company that a random selection. You can replace most Fortune 500 CEOs with a magic 8 ball and get about the same performance. That's not true of most of the other employees, including the janitors, so why are they paid several orders of magnitude more? Because most of the CEOs are on the boards of other companies and approve large salaries in exchange for the same favour being paid to them.
With a ground-pointing camera and an estimation of altitude you can use feature detection to get a moderately accurate estimate of speed. This won't work if you're above the clouds, but if you are then doing the same thing with the clouds will give you a rough estimate of air speed, as clouds are approximately stationary relative to the air that contains them.
BeOS 5 is not easy to compromise remotely because the network stack crashes under load, or after a few minutes of low load. Does Haiku have the same feature?
The grid losses are about 7%, but that's because the distances are kept quite small. Most consumers are in the same state as their power stations, and often a lot closer. There's a reason power stations are built quiet close to cities. Try powering the coasts from a solar array in the middle of the USA and you'll see much bigger losses. And the middle of the USA is exactly where you want to have large-scale solar collectors: where you have lots of empty space with lots of sunshine.
Solar is not great for powering the grid, where the supply and demand must be balanced and where you want to put the supply and demand close together to minimise transmission losses. It's much better for workloads that are effectively charging batteries. If you stick big solar collectors in the middle of the desert, connecting that up to the grid for the rest of the USA is pretty difficult and you'll still have the problem that there are big demand spikes just as the solar sun starts to set. In contrast, if it's all producing hydrogen (or charging batteries), then you can build up a small surplus to cover times when demand spikes above production temporarily and you just need pipes to ship the water in and trains to ship the power out.
There's a difference, which is that most crappy corporate software isn't attempting to define standards and a platform for everyone else to build on top of. OpenStack claims to be developing a vendor-agnostic standard and reference implementation for interoperable systems.
With multiple file systems per drive, a given file system doesn't necessarily know the drive is idle so some other process would need to do the delayed TRIM which is what Canonical is suggesting.
Why would a filesystem need to know? On FreeBSD, the filesystem just spits a BIO_DELETE command into the GEOM layer, and it is up to GEOM to schedule when to dispatch it - it's free to reorder it, as long as it doesn't move it after a BIO_WRITE with an overlapping range. If the filesystem needs to know about the status of other filesystems then that's a serious layering problem. The FS should not be making the decision about whether to send the BIO_DELETE, because it's the responsibility of something lower down the stack to decide what to do with it. For example, a RAM disk can use it to free the underlying memory. You don't want every filesystem to have to know about every possible kind of device.
And TRIM is enabled by default on OS X if you use the stock drives. If you use an after-market replacement then you do need to explicitly enable it (which sucks). With FreeBSD, it's enabled for UFS by default since 9.0 and ZFS by default since 9.2. It is also enabled in software raid configurations by default in 10.0. I'm very surprised Linux doesn't enable it by default.
Because that would require the flash to do deduplication and know that the blocks were full of FF and so could be copy-on-write (and, in your scheme, block-level compression). You're thinking of an SSD as if it were a big RAM chip, full of blocks of flash with a simple addressing scheme. It isn't. It's a load of flash cells, which wear out over time, and a very complicated controller that maps blocks to cells. The point of TRIM is not to erase the block, it is to remove the block from the remapping tables so that that the wear levelling knows it has an unused block that can be erased whenever it makes sense to do so. The erasure happens on a cell granularity, and cells are some multiple of the block size (not sure what they are these days, probably 64-128KB). Knowing that all blocks in a cell are free is great, because the controller can then erase the entire cell. Knowing that only one block is in use and it hasn't been modified for a while means that it can defragment by erasing one cell, moving the individual infrequently modified blocks to that cell, and then add their old cells to the free list for erasure.
It's also worth noting that there are two modes for TRIM. One enforces the invariant that two reads of the same block will give the same value if there are no writes between them, the other only requires this invariant for blocks that have not been marked as erased. There's often a performance difference between them, because the latter lets the drive just leave the block as spare and overwrite it during a GC and then reallocate it on write (a good implementation would mark it as zero'd and always return zeros until there is a write, but this requires slightly more space in the remapping tables and so isn't always done). It sounds like Linux is still using the former version, which can be very slow on some drives.
Bitcoins have experienced drops in value over the course of a single day that are greater than the drop in value of the US dollar over the entire great depression, or its total deflation over the last 100 years. It's not cratering because it's value is effectively a random number and it will keep going up for as long as people are making money from the wild fluctuations in value of an unregulated instrument. When the big speculators cash out and the rest realise that they just own a magic number that no one with significant assets has ever promised to accept in payment, you'll see what cratering really means.
So you're saying that being a politician is just considered a misdemeanour?
And yet SELinux went in. And if you look at the last decade of CVEs for the Linux kernel, see how many come with the note 'Does not affect users not using SELinux'. A great many of them were in the null pointer dereference checker, and were an entire category of exploit that was unknown until the NSA contributed SELinux. But, sure, go on believing that Linus keeps you safe from the NSA if that makes you happy.
If I make a web page that crashes IE6, am I at fault?
If you make a web site and it happens to crash IE6, then you're not at fault. If you make a web site that intentionally crashes IE6 and encourage IE6 users to visit it, then I don't see why it would be treated any differently from any other DoS attack. If I find a bug that crashes Apache from a malformed URL and then stick a link to someone's Apache server with such a URL on my web page, I don't think there's any doubt that it's malicious.
In the case of Google, they intentionally exploited a security hole in Safari to collect information about the user. This seems like something that is a pretty clear cut case of violating whatever the US equivalent of the Computer Misuse Act is. $17m seems like a very low fine considering the number of people who were affected. It's under $1 per incident, which doesn't seem enough to discourage a company like Google.
Can I now sue Verizon for crapwares that make my phone vulernable?
If they install them for the purpose of making your phone vulnerable, yes. If they exploit the holes introduced by the crapware for profit (or for other purposes), then yes.
I guess I am asking others: What line the sand did Google step across?
They identified a vulnerability in a piece of software, and instead of reporting it they decided to exploit it.
Apple is stripping out GPL3 based components
More specifically, Apple does not and never has allowed GPLv3 code into the building. They're not stripping out GPLv3 code, they're staying with old versions of projects that switched to GPLv3 until a permissively licensed replacement is finished. This is not a strategy exclusive to Apple - a lot of companies were unhappy with GPLv2 and now find GPLv3 quite scary. We've had quite a few companies start to contribute to FreeBSD and related projects as a result of GPLv3.