Simpler receiver is definitely true, though that starts to fall down with FM radio. FM radios are now typically ICs and so being simpler doesn't really buy you much when the cost of the FM demodulator chip is no cheaper than the cost of a digital radio decoder chip. As for installed base, I'm not sure I agree. I would be very surprised if, at any given time, more people are within hearing distance of an FM receiver than a mobile phone.
No, I said it's not useful and then pointed out that they only have enough data to tell you anything reliable about one company and have data about two other drives from other companies that tell you very little about whether it's representative.
As they note, one of their drives has an 8% annual failure rate because they have 45 and one happened to fail this quarter. A lot of the others are similar numbers, with the difference between 0 and 1 failures being 4-8%. The only ones where they have enough data to be useful are HGS, one WD, and two Seagate models. One Seagate is a lot less reliable than most HGST drives (and less reliable than the worst HGST model), the other is the most reliable disk in the set. The WD drive is the least reliable.
Interestingly, these companies aren't required to drug test contractors. If you have skills that they need, then it's possible for them to avoid this requirement.
I don't take any illegal drugs, but if a company asked me to take a drug test then that would be my cue to leave. That level of trust implies that it's not a place that I'd want to work, or be able to work efficiently.
Safety is a red herring. I have two objections to GM crops: biodiversity and lock-in (though they don't both apply to the same crops).
A lot of GM crops are significantly more hardy than the original variants. This means that, if they breed true, then they are going to displace all of the originals and you will end up with a homogeneous group, which is then vulnerable to a single parasite/bacterium. Humans already have a dangerous lack of diversity in our food crops (go and look up the WHO's projections on how many millions would starve to death if wheat production were threatened globally) and GM crops are likely to decrease diversity even more.
The second problem is that many of them don't breed true or, indeed, at all. You must keep buying new seeds from the same company, you can't collect your own seed stock. This means that your food supply becomes entirely dependent on a small number of companies. This is less of a problem for the USA, but the EU spends a lot of money subsidising farmers to ensure that we have an independent food supply and making it dependent on seeds bought from the US seems to counter this quite effectively.
We used to use Yarrow for this purpose, but it suffered from the problem that you needed to estimate the entropy of your sources. Fortuna was introduced to address this, and allows you to combine entropy sources without estimating the amount of entropy that they contain. What does this add beyond that?
Or maybe a lot of people find a fuzzy picture from a weak analog broadcast a lot easier to watch than the blocky picture with dropped frames you get from a weak digital broadcast.
It's a false dichotomy. Take the two signals, side by side, broadcast quality. Introduce the same amount of noise into them. For a long time, the analogue signal will become increasingly fuzzy while the digital signal will remain entirely clear. For digital radio, if you allocated the same amount of spectrum (bandwidth) as an FM channel, then you could perfectly reconstruct an error-free channel with a signal to noise ratio of 1:100 or worse. With analogue FM, you would just hear white noise.
Typically, when systems switch from analogue to digital broadcast, they significantly reduce both transmission power and bandwidth for the digital, while aiming to get approximately the same coverage as the analogue equivalent. Often they will reduce one or both a bit too far, but not always. My stepfather, for example, was a relatively early adopter of DAB because, although the DAB signal was lower power, used less bandwidth, and came from the same places as the FM signal, the DAB signal was clear in his rural house (surrounded by hills), whereas the FM signal was very noisy and dropped out a lot.
You are correct, FM does use a lot of bandwidth which could be used far more efficiently.
FM is analogue, which means it degrades far more gracefully than digital
Sure, if you're comparing it to a digital signal with no error correction. If you use vaguely modern error correcting codes (as in, developed in the last 50 years), then digital signals can correct all errors long after analogue signals are indistinguishable from white noise to a human. The reason that this idiotic myth persists is that the switch to digital radio and TV broadcasts came with a slight decrease in range as a result of a huge decrease in transmitter power.
There was a study a while ago (more than 10 years) which pointed at a self-perpetuating circle in the USA:
People expect the government to be incompetent. This makes it hard to hire competent people for government jobs, because no one competent wants to work somewhere that is organisationally incompetent (if nothing else, it will make it hard for them to get the next job). This means that, in the absence of competent people, even the competent government agencies trend towards incompetence. This then leads to people expecting the government to be incompetent, and so on.
Building a detailed marketing profile for people who are just about to enter the job market and will be buying stuff for decades to come is valuable. Tastes change over time, but they generally change slowly, so a detailed profile now that can be refined over time is hugely valuable. If anything, $10K is too low unless it also comes with a requirement that Google delete all data about these students (including data on aggregate models).
Next time you talk to an elected representative, point out that Apple had a DVD ripping feature in iTunes ready to go a decade ago, but never shipped it because the CSS license didn't allow ripping and the DMCA prevented them from doing it anyway. Point out that we'd have had the ability to rip DVDs to play on mobile devices just as easily as we do for CDs for years if not for legislation that exists solely to harm the economy as a whole to protect a fairly small segment of it.
It sounds like you've hit the stuff that they put in to plug the analogue hole. If you don't have DRM-compatible everything on the display path (drivers, graphics card, cable, monitor) then it downgrade the quality to SD. This also applies for VGA and composite output. Lots of early adopters were pissed off by this after buying expensive HD TVs with composite input and then discovering that they couldn't see HD content from BluRay without buying a new TV (or a dubiously legal convertor box).
Given that it's AACS, I imagine that it's because they're also backing up BluRay. I have a BD burner in a FreeBSD box that I bought for backups (and never actually used, but that's a different story - it was only marginally more expensive than a DVD drive), so when I received a BluRay disk for Christmas I thought that I'd be able to play it. Apparently not - it used to be possible with VLC but they changed something in the encryption and now it isn't. There is no open source software that can play BDs reliably (there's a Linux thing that sends some SCSI commands directly to the drive from userspace and might work, or might brick your drive) and only a couple of commercial programs that can copy them.
It's even better when those are on DVDs, telling you about the crystal clear picture and sound quality that you get on BluRay, while showing you the picture and sound from a DVD. I always get to the end of those thinking 'DVD quality is pretty good. What was that other thing you were talking about and why should I care?'
The astonishing thing is that after 3 decades of stack-crashing causing more security bugs than any other type - there still isn't a native array/hash/list type added to C.
There is, but the resulting language is called C++. The type system of C doesn't allow you to have container-of-X, where X is some other type, constructs without resorting to macros. A lot of systems (including Windows NT and Linux) use derivatives of the 4BSD headers for this, but they use a container-of pattern that involves casting from a pointer to member to a pointer to the outer structure in a way that depends on explicit casts and makes it easy to accidentally violate type safety.
I'm on the Core Team for the FreeBSD project and, among other open source activities, wrote and maintain the open source Objective-C implementation (as well as a lot of other parts of the GNUstep implementation of the Foundation and AppKit frameworks), the C++ runtime library that ships in FreeBSD, on the PS4 and with a number of Android apps and have been contributing to LLVM and Clang since 2008. I can point at several tens[1] of thousands of lines of open source code that I've released. What have you done, AC troll?
[1] Possibly hundreds by now. OpenHub has become a lot worse at tracking duplicates and so thinks that I'm responsible for about 2,000,000, which is definitely not right.
The amusing thing about this post is that it claims that git is simple, demonstrates this by describing four simple commands and manages to get them completely wrong.
First, you suggest git pull. After that you're doing a git add, so you have unstaged changes at this point. If any of them conflict, git pull will not allow you to merge them, it will simply fail. If you wish to pull onto a tree with unstaged changes then you must do a stash first and a stash pop after, so now the first command becomes:
$ git stash $ git pull $ git stash pop
If that conflicts, then you have some fun merging them (resolving conflicts resulting from a stash pop is one of the most confusing bits of the git experience). Okay, so now you've updated your tree. And that's fine as long as you've not done any local commits (and, if you haven't, then why are you using a DVCS at all?), because if you have then yo've now done a merge and when you push you'll end up with confused history for everyone else. Instead, you want to rebase (apply your local commits on top of the upstream). So your first command now becomes:
$ git stash $ git pull --rebase $ git stash pop
You may get merge conflicts during the rebase too, but hopefully they're easy to fix because now you're fixing changes between small commits.
The rest of your commands are bad practice, but not actively dangerous.
No, he means the command line. It's improved a lot (now it sucks, but is just about tolerable) in the last decade, but the original git UI was a horrible mishmash of non-orthogonal commands and different command-line flags for doing the same thing different subcommands. The good thing to come out of this was a number of people deciding that the CLI was so horrible that they'd write decent GUIs so that they never needed to touch the CLI.
'Designing' the core architecture could have been done by anyone who'd read a paper on Merkel trees. The core of git is the application of a few well-known data structures.
I'm not so sure. I'd like a decent distributed VCS that:
Is permissively licensed (git is GPL'd, though amusingly there's a permissively licensed C# reimplementation)
Has few dependencies (git, impressively, manages to depend on Perl and Python)
Scales well to large repositories
Handles clones of subsets of a large aggregate repo well
Has a UI that's designed by someone who has, at the very least, actually seen a human in the distance
It looks as if BitKeeper meets all of these requirements. Fossil meets the first two, but doesn't scale particularly well and doesn't have any notion of a sparse clone. BitKeeper's nested repos look like the feature that I've never managed to get to work nicely in git. There are still a few key advantages that git has:
The command line UI sucks so badly that it's motivated people to write decent GUIs for it. In contrast, the svn UI is only moderately bad and so there's a relative lack of decent GUIs.
GitHub. Being able to create and share public repos easily is a killer feature (though the GitHub back end also supports svn, so it's conceivable that they'd be able to provide BK support too).
Git-svn make it easy to use git locally even when upstream uses svn.
That graph is the averaged over a long period. One of the issues with solar and wind power is that they tend to be very bursty, wind in particular. The power output from a wind turbine is proportional to the third power of the wind speed. If you have an hour of wind that's double the normal speed, then you're generating eight times as much power from the wind generators as normal for that hour. Most other power plants can't reduce capacity instantly to compensate so for short bursts there is a lot more power being generated than is being consumed. In some cases, it's cheaper to produce the waste power than to start decoupling things from the grid and spilling the power somewhere (ideally into storage, sometimes just as waste heat), so you end up paying people to consume the power, because it costs more to stop producing it.
Most consumers don't see this, because we buy power indirectly but some big industrial consumers have contracts that allow them to get direct access to the spot price and consume power when it's very cheap. The idea behind a smart grid is to allow everyone to benefit from this kind of thing. For example, having your fridge run its compressor when the cost of power drops very close to zero.
Slashdot Mirror
Simpler receiver is definitely true, though that starts to fall down with FM radio. FM radios are now typically ICs and so being simpler doesn't really buy you much when the cost of the FM demodulator chip is no cheaper than the cost of a digital radio decoder chip. As for installed base, I'm not sure I agree. I would be very surprised if, at any given time, more people are within hearing distance of an FM receiver than a mobile phone.
No, I said it's not useful and then pointed out that they only have enough data to tell you anything reliable about one company and have data about two other drives from other companies that tell you very little about whether it's representative.
As they note, one of their drives has an 8% annual failure rate because they have 45 and one happened to fail this quarter. A lot of the others are similar numbers, with the difference between 0 and 1 failures being 4-8%. The only ones where they have enough data to be useful are HGS, one WD, and two Seagate models. One Seagate is a lot less reliable than most HGST drives (and less reliable than the worst HGST model), the other is the most reliable disk in the set. The WD drive is the least reliable.
Interestingly, these companies aren't required to drug test contractors. If you have skills that they need, then it's possible for them to avoid this requirement.
I don't take any illegal drugs, but if a company asked me to take a drug test then that would be my cue to leave. That level of trust implies that it's not a place that I'd want to work, or be able to work efficiently.
A lot of GM crops are significantly more hardy than the original variants. This means that, if they breed true, then they are going to displace all of the originals and you will end up with a homogeneous group, which is then vulnerable to a single parasite/bacterium. Humans already have a dangerous lack of diversity in our food crops (go and look up the WHO's projections on how many millions would starve to death if wheat production were threatened globally) and GM crops are likely to decrease diversity even more.
The second problem is that many of them don't breed true or, indeed, at all. You must keep buying new seeds from the same company, you can't collect your own seed stock. This means that your food supply becomes entirely dependent on a small number of companies. This is less of a problem for the USA, but the EU spends a lot of money subsidising farmers to ensure that we have an independent food supply and making it dependent on seeds bought from the US seems to counter this quite effectively.
We used to use Yarrow for this purpose, but it suffered from the problem that you needed to estimate the entropy of your sources. Fortuna was introduced to address this, and allows you to combine entropy sources without estimating the amount of entropy that they contain. What does this add beyond that?
Or maybe a lot of people find a fuzzy picture from a weak analog broadcast a lot easier to watch than the blocky picture with dropped frames you get from a weak digital broadcast.
It's a false dichotomy. Take the two signals, side by side, broadcast quality. Introduce the same amount of noise into them. For a long time, the analogue signal will become increasingly fuzzy while the digital signal will remain entirely clear. For digital radio, if you allocated the same amount of spectrum (bandwidth) as an FM channel, then you could perfectly reconstruct an error-free channel with a signal to noise ratio of 1:100 or worse. With analogue FM, you would just hear white noise.
Typically, when systems switch from analogue to digital broadcast, they significantly reduce both transmission power and bandwidth for the digital, while aiming to get approximately the same coverage as the analogue equivalent. Often they will reduce one or both a bit too far, but not always. My stepfather, for example, was a relatively early adopter of DAB because, although the DAB signal was lower power, used less bandwidth, and came from the same places as the FM signal, the DAB signal was clear in his rural house (surrounded by hills), whereas the FM signal was very noisy and dropped out a lot.
FM is decent bandwidth.
You are correct, FM does use a lot of bandwidth which could be used far more efficiently.
FM is analogue, which means it degrades far more gracefully than digital
Sure, if you're comparing it to a digital signal with no error correction. If you use vaguely modern error correcting codes (as in, developed in the last 50 years), then digital signals can correct all errors long after analogue signals are indistinguishable from white noise to a human. The reason that this idiotic myth persists is that the switch to digital radio and TV broadcasts came with a slight decrease in range as a result of a huge decrease in transmitter power.
iPad is obviously a typo for iPod in the GP's post. Apple stock has gone up quite a lot since then.
People expect the government to be incompetent. This makes it hard to hire competent people for government jobs, because no one competent wants to work somewhere that is organisationally incompetent (if nothing else, it will make it hard for them to get the next job). This means that, in the absence of competent people, even the competent government agencies trend towards incompetence. This then leads to people expecting the government to be incompetent, and so on.
Obama and cronies are "Progressives".
Only from the perspective of the USA, which leans so far to the right that it's surprising that it hasn't fallen over.
Building a detailed marketing profile for people who are just about to enter the job market and will be buying stuff for decades to come is valuable. Tastes change over time, but they generally change slowly, so a detailed profile now that can be refined over time is hugely valuable. If anything, $10K is too low unless it also comes with a requirement that Google delete all data about these students (including data on aggregate models).
Next time you talk to an elected representative, point out that Apple had a DVD ripping feature in iTunes ready to go a decade ago, but never shipped it because the CSS license didn't allow ripping and the DMCA prevented them from doing it anyway. Point out that we'd have had the ability to rip DVDs to play on mobile devices just as easily as we do for CDs for years if not for legislation that exists solely to harm the economy as a whole to protect a fairly small segment of it.
It sounds like you've hit the stuff that they put in to plug the analogue hole. If you don't have DRM-compatible everything on the display path (drivers, graphics card, cable, monitor) then it downgrade the quality to SD. This also applies for VGA and composite output. Lots of early adopters were pissed off by this after buying expensive HD TVs with composite input and then discovering that they couldn't see HD content from BluRay without buying a new TV (or a dubiously legal convertor box).
Given that it's AACS, I imagine that it's because they're also backing up BluRay. I have a BD burner in a FreeBSD box that I bought for backups (and never actually used, but that's a different story - it was only marginally more expensive than a DVD drive), so when I received a BluRay disk for Christmas I thought that I'd be able to play it. Apparently not - it used to be possible with VLC but they changed something in the encryption and now it isn't. There is no open source software that can play BDs reliably (there's a Linux thing that sends some SCSI commands directly to the drive from userspace and might work, or might brick your drive) and only a couple of commercial programs that can copy them.
It's even better when those are on DVDs, telling you about the crystal clear picture and sound quality that you get on BluRay, while showing you the picture and sound from a DVD. I always get to the end of those thinking 'DVD quality is pretty good. What was that other thing you were talking about and why should I care?'
The astonishing thing is that after 3 decades of stack-crashing causing more security bugs than any other type - there still isn't a native array/hash/list type added to C.
There is, but the resulting language is called C++. The type system of C doesn't allow you to have container-of-X, where X is some other type, constructs without resorting to macros. A lot of systems (including Windows NT and Linux) use derivatives of the 4BSD headers for this, but they use a container-of pattern that involves casting from a pointer to member to a pointer to the outer structure in a way that depends on explicit casts and makes it easy to accidentally violate type safety.
He talked about array, not vector.
I was wondering how much of this is simply pulling the relevant WebKit changes into their copy of the Blink tree.
I'm on the Core Team for the FreeBSD project and, among other open source activities, wrote and maintain the open source Objective-C implementation (as well as a lot of other parts of the GNUstep implementation of the Foundation and AppKit frameworks), the C++ runtime library that ships in FreeBSD, on the PS4 and with a number of Android apps and have been contributing to LLVM and Clang since 2008. I can point at several tens[1] of thousands of lines of open source code that I've released. What have you done, AC troll?
[1] Possibly hundreds by now. OpenHub has become a lot worse at tracking duplicates and so thinks that I'm responsible for about 2,000,000, which is definitely not right.
First, you suggest git pull. After that you're doing a git add, so you have unstaged changes at this point. If any of them conflict, git pull will not allow you to merge them, it will simply fail. If you wish to pull onto a tree with unstaged changes then you must do a stash first and a stash pop after, so now the first command becomes:
If that conflicts, then you have some fun merging them (resolving conflicts resulting from a stash pop is one of the most confusing bits of the git experience). Okay, so now you've updated your tree. And that's fine as long as you've not done any local commits (and, if you haven't, then why are you using a DVCS at all?), because if you have then yo've now done a merge and when you push you'll end up with confused history for everyone else. Instead, you want to rebase (apply your local commits on top of the upstream). So your first command now becomes:
You may get merge conflicts during the rebase too, but hopefully they're easy to fix because now you're fixing changes between small commits.
The rest of your commands are bad practice, but not actively dangerous.
No, he means the command line. It's improved a lot (now it sucks, but is just about tolerable) in the last decade, but the original git UI was a horrible mishmash of non-orthogonal commands and different command-line flags for doing the same thing different subcommands. The good thing to come out of this was a number of people deciding that the CLI was so horrible that they'd write decent GUIs so that they never needed to touch the CLI.
'Designing' the core architecture could have been done by anyone who'd read a paper on Merkel trees. The core of git is the application of a few well-known data structures.
It looks as if BitKeeper meets all of these requirements. Fossil meets the first two, but doesn't scale particularly well and doesn't have any notion of a sparse clone. BitKeeper's nested repos look like the feature that I've never managed to get to work nicely in git. There are still a few key advantages that git has:
It's not clear that BitKeeper can overcome these.
That graph is the averaged over a long period. One of the issues with solar and wind power is that they tend to be very bursty, wind in particular. The power output from a wind turbine is proportional to the third power of the wind speed. If you have an hour of wind that's double the normal speed, then you're generating eight times as much power from the wind generators as normal for that hour. Most other power plants can't reduce capacity instantly to compensate so for short bursts there is a lot more power being generated than is being consumed. In some cases, it's cheaper to produce the waste power than to start decoupling things from the grid and spilling the power somewhere (ideally into storage, sometimes just as waste heat), so you end up paying people to consume the power, because it costs more to stop producing it.
Most consumers don't see this, because we buy power indirectly but some big industrial consumers have contracts that allow them to get direct access to the spot price and consume power when it's very cheap. The idea behind a smart grid is to allow everyone to benefit from this kind of thing. For example, having your fridge run its compressor when the cost of power drops very close to zero.