Moths work for natural fibres, but they're far less keen to eat synthetic ones (which is part of the attraction of synthetics). They also find don't often do much damage to tight weaves (apparently it's not actually the moths that eat the clothes. They lay eggs in them and the larvae eat them immediately after hatching). I have had a few cashmere jumpers eaten by moths after less than a year, but shirts in the same wardrobe have survived for 20 years (well, survived might be a strong claim given the state of the cuffs and collars, but certainly not been eaten by moths).
Unlike the ecologically friendly hunting that the natives did, where they would stampede an entire herd off a cliff. Or their green slash-and-burn agriculture.
I was a bit surprised by that claim as well. I remember watching a black-and-white history film that talked about the smalltalk blankets thing, back when I was at school, at around the time that Churchill apparently first published his stuff. He may have been one of the leading proponents of the theory, but I don't think he can be blamed for originating it.
This post is at -1. I only see it because I have a low threshold explicitly configured, most people won't. That said, your post is at 0, so by replying to it you've increased the number of people who see it.
It's easy to be in favour of censoring people that you disagree with, the problem is that the censor is going to be a human making judgement calls. Most of us agree that censoring child pornography is fine, but the group charged with doing that in the UK managed to block Wikipedia because it contains a picture of an album cover that contains a naked child. So, if you want to censor racist posts, who do you want to give the authority to decide what is racist and what isn't to? If you can't name an individual, then there's a simple solution: log in and use your mod points.
It was one of the contributors to universal suffrage in the UK. When we sent all of our young men off to fight, women were required to do traditionally male jobs. There was a lot of attrition in the First World War, but then even more in the 1918 pandemic. The combination of these two meant that there weren't enough able-bodied men after the war to send the women back home, which led to the Representation of the People Act 1918, which allowed women to vote in Parliamentary elections for the first time.
Amusingly, lots of people are making a big deal about this being the 100th anniversary of women being able to vote, when it was not the first time that women could vote (some were able to vote - and even be elected - in local elections before then) and most still could not, yet it was the first time that practically all men could vote. Women didn't get equal voting power to men until 1928. The 1928 act was made possible by the social changes that followed the end of WWI and the 1918 flu epidemic, when women became a significant proportion of the workforce.
Not all of them. Some will have natural immunity and the rest will have easier access to treatment than elsewhere. In some cases, it's feasible to vaccinate everyone in a quarantine area, but not everyone in a country, so the survival rate for uninfected people in the quarantine area may be higher than if the disease escaped into the general population.
To put it in perspective: DDR4L uses about 10% more power than LPDDR4. Even if DRAM were the primary consumer of DRAM, this would translate to only a 10% drop in battery life. In comparison, DDR4 uses around five to ten times as much, and so would drop the battery life considerably. Only a few other vendors are using DDR4L, but the ones that are seem to get the kind of battery life that would make me happy. In addition, Apple added a bunch of support for hot-swap RAM to XNU back in the XCode days and so could probably support using 16GB on battery and 32GB on mains power. A lot of the RAM contents is read-only disk caching, so you don't even end up flushing much out to disk / swap / compressed memory when you de-power half the RAM in a typical machine.
Apple isn't, but most non-Apple phones have USB-C at the high end and it's gradually propagating to the low end. Apple is in a bit of a difficult position, because Lightning is very similar to USB-C (similar size, reversible, carries USB 3 signal). It's not a huge improvement for consumers (there aren't many peripherals that you plug into both a phone and a computer, so you need a USB to Lightning cable anyway, and there's little difference between carrying a USB-A to Lightning or a USB-C to Lightning one) and there are now a bunch of phone / tablet peripherals that use it. In contrast, for most other manufacturers, USB-C is a better connector than microUSB (it's more resilient and it's reversible), so there's a bigger incentive for them to upgrade. I imagine that Lightning will go away at some point though.
The last step is easy. Just call it the Make American Internet Great Again Act and he'll sign it. You don't think he actually reads the bills that he's asked to sign do you?
New music has always sounded crap. It's a case of Sturgeon's Law (90% of everything is crap) combined with survivor bias (the 10% that isn't crap is more likely to be remembered and still played much later). For every great song you can remember from a prior decade, there are nine more that were such complete crap that you don't even remember that they were briefly popular.
I've seen a few, though to be fair most of them were on Apple employees. The one use I've seen for them that I actually like is two-factor auth. I saw a colleague use this and it seems pretty convenient. The watch connects to the computer via Bluetooth and when you need to do 2FA the watch beeps and prompts for a fingerprint and then signs the request. It's more convenient than carrying a U2F token around with you, but not quite so convenient that I would actually want one.
The biggest complain is that the MBP hasn't seen a bump beyond 16GB of RAM. I have a 4-year-old MBP that has 16GB of RAM and, for my use, RAM is the single largest bottleneck. I'm sitting on equipment budget to replace it with one with 32GB (or even more, if available) as soon as it's available.
Part of the blame for this is Intel, who doesn't provide any chips that have memory controllers supporting LPDDR4 out (in spite of the fact the LPDDR4 spec is from 2014 and most phones have used it for the past few years), and support either 16GB of LPDDR3 or 32GB of DDR4. That's slightly misleading when you realise that they do support DDR4L, which isn't quite as low power as LPDDR4, but is a lot lower power than DDR4, and other manufacturers have made machines with 32GB of DDR4L and reasonable battery life.
The only extra cost is maintaining OSX, but I have heard there are only a few dozen employees working on it full time, and there is a lot of source duplication with iOS.
That's quite misleading. Apple's CoreOS team, which is responsible for the XNU kernel, libc, and a few other bits is very small (and 95% of what they do is applicable to both macOS and iOS). On top of that, there are a lot of frameworks that are shared between iOS and macOS, and a quite large compiler / tools team that develops XCode, contributes a lot to LLVM/Clang/LLDB, maintains Swift, and so on, which is also shared between all operating systems (XCode is Mac only, but it is primarily used for iOS development these days). I think AppKit is about the only framework that is macOS only. There are also a lot of Mac-only Apple apps, and that's where the real costs come from.
The problem is the transition era. We saw the same thing when computers started coming out with only USB for peripherals (original iMac and then a load of PCs). First you need USB to PS/2 adaptors and so on, then all of your new peripherals start using USB and you wonder why you ever needed PS/2, serial and parallel ports. In a few years, everything will be using USB-C (already almost everything is USB and USB 3 is fast enough for pretty much everything else, and the few other things can still use a USB-C port) and you'll wonder why everyone was complaining. Until then, there's going to be an annoying transition period when the computers use USB-C but no one yet has the newer peripherals.
That said, I yesterday stopped by a colleague's desk and saw that he has about 1cm of USB flash drive connected to his computer via a 10cm USB-A to USB-C dongle and couldn't help laughing.
The max thickness is somewhat misleading, because the MBP is a regular cuboid, whereas the air tapers towards the keyboard and so ends up being quite a bit thinner at the front and on average. I wasn't particularly tempted by one, but I have some colleagues who really like theirs.
In total, yes. Per app? Not sure. On my computer, I have half a dozen applications running that I switch between frequently (including the terminal app that has a lot of fairly large child processes). On my phone, I run one thing at a time and don't care if the OS kills background processes. I also rarely get about 3-4 tabs open on my phone, whereas my laptop will easily grow to over 20 until I get around to culling them all.
The odd thing for me in this announcement is that it implies that they're not destroying the contents of the tab when you switch away. A 1200x1600 browser window is 5MB of rendered texture, which will usually compress with standard on-GPU texture compression down to 1MB or less. 1MB of texture memory per tab is a tiny amount, when a very cheap GPU has 256MB and even my 4-year-old laptop has 1GB. You're almost certainly keeping over 1MB of state around per tab.
This kind of optimisation implies that they're still doing on-demand rendering, which is the kind of optimisation that made a lot of sense until the middle of the last decade. GPU RAM is a lot cheaper than CPU cycles.
If it's the GPL working as intended, then why did the authors of the GPL explicitly change this in version 3?
"Fine" in the sense of "can you get away with it legally"? Hard to say. I would, however, point out that the GPL FAQ is not a legal document.
Not a legal document, but it clarifies the intent of the GPL, which is likely to have some weight in court when attempting to interpret the terms. Again, if the authors of the GPL believe that this is fine, then why is it not?
Until the first instance of a friend snitching to an author AND the author caring and suing the gifter the answer is a solid yes. Technically the terms require it, technically you probably broke 15 laws before breakfast especially if you assume officers won't give the benefit of the doubt in cases where they have discretion. Either way, given that you have access to the source how difficult is it to toss it in?
The real case for this was a bit more complex. It wasn't a friend compiling it, it was a Linux distribution. Compile the code and ship packages. Definitely useful, yes? Except that according to the GPL, the recipient of the code is allowed to demand the source code and the distribution in question hadn't kept a copy and upstream had gone away. They had to scrabble to find a copy from a mirror, or face legal action. As a result, distributions that provide binary packages now also mirror the source code and keep it around for a long time. That adds cost to everyone that ships binary packages of GPL'd code. GPLv3 explicitly addressed this because it was a real concern that was costing money.
Your other cases are all about trying to find loophole conditions under which you can steal the code without sharing code back under the same terms. Yes, if you start trying to find ways to dodge sharing back code you'll start running into the legal clauses designed to make this difficult since it is the entire point of the license.
Why is it fine for me to ship a binary-only program that's tightly coupled to a GPL'd library via a pipe, but not when it's via linkage? The GNU GPL FAQ specifically makes this distinction, but it's an entirely arbitrary one based on a specific execution model.
Not sure about v8, but it's worth noting that JavaScriptCore's intermediate representation for paths that make it to the second-tier JIT is a CPS representation, so I'd argue that JavaScript probably isn't an unsuitable language for writing CPS code: at least then there's less impedance mismatch between the programmer and the optimiser...
Code reuse. If you're validating form input, for example, it would be nice if you can use the same code for client-side and server-side validation. The server-side version protects you against invalid date, the client-side gives more immediate feedback to the user, but both will give the same result. There are basically two solutions to this problem. The simplest is to use JavaScript on the back end, the other is to use something like GWT or similar that lets you write the back end in one language and then synthesises the front end by transforming some of that code into JavaScript.
The other big reason is that companies have invested a huge amount of developer time in optimising JITs for JavaScript. You're typically not just choosing a language, you're also choosing an implementation of a language. JavaScript may be a pretty bad language in a number of ways, but v8 is a very fast implementation of a language (to the extent that C code compiled to JavaScript and run with v8 is often close in performance to natively compiled code, and sometimes faster).
Really? Which of these business models makes more sense to you:
Option 1: Create a complex piece of software for free. End up with something that is trivially copied by unskilled labour. Charge people for copies.
Option 2: Charge people to for writing the software (which requires skilled labour). Give away copies for free.
The first one is the proprietary off-the-shelf model, the second is the open source model. And you think that the second one hasn't solved the 'how to make money' aspect?
Most people who work on successful open source projects are paid to do so, because people need the software to do things that it doesn't already.
Or are you really saying that open source software doesn't make it easy for middlemen to make money? In which case, I'd argue that that's a feature and not a bug.
I'd even dispute the assertion that most open source development goes unpaid. It might be true if you look at total lines of code written, but I'd be very surprised if it's true if you weight it towards the projects that people actually use. Most companies get very nervous depending on volunteers for anything business critical and would much rather have someone paid to be responsible for it. I contribute to several open source projects (and I'm paid for quite a lot of that) and the most successful ones all have most code written by paid individuals. A lot of the unpaid work is effectively advertising for the developers in question: 'hey, you need an expert in this? I wrote a load of it, you should hire me!'
Slashdot Mirror
Moths work for natural fibres, but they're far less keen to eat synthetic ones (which is part of the attraction of synthetics). They also find don't often do much damage to tight weaves (apparently it's not actually the moths that eat the clothes. They lay eggs in them and the larvae eat them immediately after hatching). I have had a few cashmere jumpers eaten by moths after less than a year, but shirts in the same wardrobe have survived for 20 years (well, survived might be a strong claim given the state of the cuffs and collars, but certainly not been eaten by moths).
Unlike the ecologically friendly hunting that the natives did, where they would stampede an entire herd off a cliff. Or their green slash-and-burn agriculture.
I was a bit surprised by that claim as well. I remember watching a black-and-white history film that talked about the smalltalk blankets thing, back when I was at school, at around the time that Churchill apparently first published his stuff. He may have been one of the leading proponents of the theory, but I don't think he can be blamed for originating it.
To bring this back on topic for a geek site: can you tell the difference between real fish names and ones that come from a neural network?
This post is at -1. I only see it because I have a low threshold explicitly configured, most people won't. That said, your post is at 0, so by replying to it you've increased the number of people who see it.
It's easy to be in favour of censoring people that you disagree with, the problem is that the censor is going to be a human making judgement calls. Most of us agree that censoring child pornography is fine, but the group charged with doing that in the UK managed to block Wikipedia because it contains a picture of an album cover that contains a naked child. So, if you want to censor racist posts, who do you want to give the authority to decide what is racist and what isn't to? If you can't name an individual, then there's a simple solution: log in and use your mod points.
It was one of the contributors to universal suffrage in the UK. When we sent all of our young men off to fight, women were required to do traditionally male jobs. There was a lot of attrition in the First World War, but then even more in the 1918 pandemic. The combination of these two meant that there weren't enough able-bodied men after the war to send the women back home, which led to the Representation of the People Act 1918, which allowed women to vote in Parliamentary elections for the first time.
Amusingly, lots of people are making a big deal about this being the 100th anniversary of women being able to vote, when it was not the first time that women could vote (some were able to vote - and even be elected - in local elections before then) and most still could not, yet it was the first time that practically all men could vote. Women didn't get equal voting power to men until 1928. The 1928 act was made possible by the social changes that followed the end of WWI and the 1918 flu epidemic, when women became a significant proportion of the workforce.
Not all of them. Some will have natural immunity and the rest will have easier access to treatment than elsewhere. In some cases, it's feasible to vaccinate everyone in a quarantine area, but not everyone in a country, so the survival rate for uninfected people in the quarantine area may be higher than if the disease escaped into the general population.
I wonder if they're planning on switching the phones to USB-C and had a bunch of Lightning sockets that they needed to get rid of...
To put it in perspective: DDR4L uses about 10% more power than LPDDR4. Even if DRAM were the primary consumer of DRAM, this would translate to only a 10% drop in battery life. In comparison, DDR4 uses around five to ten times as much, and so would drop the battery life considerably. Only a few other vendors are using DDR4L, but the ones that are seem to get the kind of battery life that would make me happy. In addition, Apple added a bunch of support for hot-swap RAM to XNU back in the XCode days and so could probably support using 16GB on battery and 32GB on mains power. A lot of the RAM contents is read-only disk caching, so you don't even end up flushing much out to disk / swap / compressed memory when you de-power half the RAM in a typical machine.
Apple isn't, but most non-Apple phones have USB-C at the high end and it's gradually propagating to the low end. Apple is in a bit of a difficult position, because Lightning is very similar to USB-C (similar size, reversible, carries USB 3 signal). It's not a huge improvement for consumers (there aren't many peripherals that you plug into both a phone and a computer, so you need a USB to Lightning cable anyway, and there's little difference between carrying a USB-A to Lightning or a USB-C to Lightning one) and there are now a bunch of phone / tablet peripherals that use it. In contrast, for most other manufacturers, USB-C is a better connector than microUSB (it's more resilient and it's reversible), so there's a bigger incentive for them to upgrade. I imagine that Lightning will go away at some point though.
The last step is easy. Just call it the Make American Internet Great Again Act and he'll sign it. You don't think he actually reads the bills that he's asked to sign do you?
New music has always sounded crap. It's a case of Sturgeon's Law (90% of everything is crap) combined with survivor bias (the 10% that isn't crap is more likely to be remembered and still played much later). For every great song you can remember from a prior decade, there are nine more that were such complete crap that you don't even remember that they were briefly popular.
I've seen a few, though to be fair most of them were on Apple employees. The one use I've seen for them that I actually like is two-factor auth. I saw a colleague use this and it seems pretty convenient. The watch connects to the computer via Bluetooth and when you need to do 2FA the watch beeps and prompts for a fingerprint and then signs the request. It's more convenient than carrying a U2F token around with you, but not quite so convenient that I would actually want one.
The biggest complain is that the MBP hasn't seen a bump beyond 16GB of RAM. I have a 4-year-old MBP that has 16GB of RAM and, for my use, RAM is the single largest bottleneck. I'm sitting on equipment budget to replace it with one with 32GB (or even more, if available) as soon as it's available.
Part of the blame for this is Intel, who doesn't provide any chips that have memory controllers supporting LPDDR4 out (in spite of the fact the LPDDR4 spec is from 2014 and most phones have used it for the past few years), and support either 16GB of LPDDR3 or 32GB of DDR4. That's slightly misleading when you realise that they do support DDR4L, which isn't quite as low power as LPDDR4, but is a lot lower power than DDR4, and other manufacturers have made machines with 32GB of DDR4L and reasonable battery life.
The only extra cost is maintaining OSX, but I have heard there are only a few dozen employees working on it full time, and there is a lot of source duplication with iOS.
That's quite misleading. Apple's CoreOS team, which is responsible for the XNU kernel, libc, and a few other bits is very small (and 95% of what they do is applicable to both macOS and iOS). On top of that, there are a lot of frameworks that are shared between iOS and macOS, and a quite large compiler / tools team that develops XCode, contributes a lot to LLVM/Clang/LLDB, maintains Swift, and so on, which is also shared between all operating systems (XCode is Mac only, but it is primarily used for iOS development these days). I think AppKit is about the only framework that is macOS only. There are also a lot of Mac-only Apple apps, and that's where the real costs come from.
The problem is the transition era. We saw the same thing when computers started coming out with only USB for peripherals (original iMac and then a load of PCs). First you need USB to PS/2 adaptors and so on, then all of your new peripherals start using USB and you wonder why you ever needed PS/2, serial and parallel ports. In a few years, everything will be using USB-C (already almost everything is USB and USB 3 is fast enough for pretty much everything else, and the few other things can still use a USB-C port) and you'll wonder why everyone was complaining. Until then, there's going to be an annoying transition period when the computers use USB-C but no one yet has the newer peripherals.
That said, I yesterday stopped by a colleague's desk and saw that he has about 1cm of USB flash drive connected to his computer via a 10cm USB-A to USB-C dongle and couldn't help laughing.
The max thickness is somewhat misleading, because the MBP is a regular cuboid, whereas the air tapers towards the keyboard and so ends up being quite a bit thinner at the front and on average. I wasn't particularly tempted by one, but I have some colleagues who really like theirs.
In total, yes. Per app? Not sure. On my computer, I have half a dozen applications running that I switch between frequently (including the terminal app that has a lot of fairly large child processes). On my phone, I run one thing at a time and don't care if the OS kills background processes. I also rarely get about 3-4 tabs open on my phone, whereas my laptop will easily grow to over 20 until I get around to culling them all.
The odd thing for me in this announcement is that it implies that they're not destroying the contents of the tab when you switch away. A 1200x1600 browser window is 5MB of rendered texture, which will usually compress with standard on-GPU texture compression down to 1MB or less. 1MB of texture memory per tab is a tiny amount, when a very cheap GPU has 256MB and even my 4-year-old laptop has 1GB. You're almost certainly keeping over 1MB of state around per tab.
This kind of optimisation implies that they're still doing on-demand rendering, which is the kind of optimisation that made a lot of sense until the middle of the last decade. GPU RAM is a lot cheaper than CPU cycles.
That's the GPL working as designed
If it's the GPL working as intended, then why did the authors of the GPL explicitly change this in version 3?
"Fine" in the sense of "can you get away with it legally"? Hard to say. I would, however, point out that the GPL FAQ is not a legal document.
Not a legal document, but it clarifies the intent of the GPL, which is likely to have some weight in court when attempting to interpret the terms. Again, if the authors of the GPL believe that this is fine, then why is it not?
Until the first instance of a friend snitching to an author AND the author caring and suing the gifter the answer is a solid yes. Technically the terms require it, technically you probably broke 15 laws before breakfast especially if you assume officers won't give the benefit of the doubt in cases where they have discretion. Either way, given that you have access to the source how difficult is it to toss it in?
The real case for this was a bit more complex. It wasn't a friend compiling it, it was a Linux distribution. Compile the code and ship packages. Definitely useful, yes? Except that according to the GPL, the recipient of the code is allowed to demand the source code and the distribution in question hadn't kept a copy and upstream had gone away. They had to scrabble to find a copy from a mirror, or face legal action. As a result, distributions that provide binary packages now also mirror the source code and keep it around for a long time. That adds cost to everyone that ships binary packages of GPL'd code. GPLv3 explicitly addressed this because it was a real concern that was costing money.
Your other cases are all about trying to find loophole conditions under which you can steal the code without sharing code back under the same terms. Yes, if you start trying to find ways to dodge sharing back code you'll start running into the legal clauses designed to make this difficult since it is the entire point of the license.
Why is it fine for me to ship a binary-only program that's tightly coupled to a GPL'd library via a pipe, but not when it's via linkage? The GNU GPL FAQ specifically makes this distinction, but it's an entirely arbitrary one based on a specific execution model.
Not sure about v8, but it's worth noting that JavaScriptCore's intermediate representation for paths that make it to the second-tier JIT is a CPS representation, so I'd argue that JavaScript probably isn't an unsuitable language for writing CPS code: at least then there's less impedance mismatch between the programmer and the optimiser...
Code reuse. If you're validating form input, for example, it would be nice if you can use the same code for client-side and server-side validation. The server-side version protects you against invalid date, the client-side gives more immediate feedback to the user, but both will give the same result. There are basically two solutions to this problem. The simplest is to use JavaScript on the back end, the other is to use something like GWT or similar that lets you write the back end in one language and then synthesises the front end by transforming some of that code into JavaScript.
The other big reason is that companies have invested a huge amount of developer time in optimising JITs for JavaScript. You're typically not just choosing a language, you're also choosing an implementation of a language. JavaScript may be a pretty bad language in a number of ways, but v8 is a very fast implementation of a language (to the extent that C code compiled to JavaScript and run with v8 is often close in performance to natively compiled code, and sometimes faster).
Really? Which of these business models makes more sense to you:
Option 1: Create a complex piece of software for free. End up with something that is trivially copied by unskilled labour. Charge people for copies.
Option 2: Charge people to for writing the software (which requires skilled labour). Give away copies for free.
The first one is the proprietary off-the-shelf model, the second is the open source model. And you think that the second one hasn't solved the 'how to make money' aspect?
Most people who work on successful open source projects are paid to do so, because people need the software to do things that it doesn't already.
Or are you really saying that open source software doesn't make it easy for middlemen to make money? In which case, I'd argue that that's a feature and not a bug.
I'd even dispute the assertion that most open source development goes unpaid. It might be true if you look at total lines of code written, but I'd be very surprised if it's true if you weight it towards the projects that people actually use. Most companies get very nervous depending on volunteers for anything business critical and would much rather have someone paid to be responsible for it. I contribute to several open source projects (and I'm paid for quite a lot of that) and the most successful ones all have most code written by paid individuals. A lot of the unpaid work is effectively advertising for the developers in question: 'hey, you need an expert in this? I wrote a load of it, you should hire me!'