1a) Using the "move" RPC command, bitcoin makes an instant transfer between two accounts that you control.
1b) All transactions are published instantly, and available instantly, via the bitcoin P2P network. There are also several websites like http://mtgox.com/ which facilitate instant transfers. After that, you wait on average 10 minutes per confirmation, each of which makes your transaction exponentially more secure. While not recommended, yes you can spend zero-confirmation transactions.
2) Did you bother to look at Android Market before posting? Only full nodes require the full block chain database (2+ GB now). Lightweight software exists for phones, or you can use a web wallet from places like http://blockchain.info/ or http://instawallet.org/
Incorrect. Even if you have 100% of the network computing power, you still cannot force core rule changes upon users.
Each P2P node validates transactions and blocks on their own, and refuses to relay invalid ones. Deviating from these rules simply segments yourself away from the rest of the network.
With sufficient network power, you may DoS the network, but not force unwanted rule changes.
It is easy to look at an individual, and say that costs are lower, especially if you doctor the numbers to assume everyone lives in New York City with high parking rates.
But that is only looking at part of the picture.
A fair comparison would included taxes paid to the city and state, and would include an assessment of what would happen if a majority of individuals started using public transportation for their given locale.
One must include car parking costs for park-and-ride lots, because not everyone can walk to a train station or bus stop.
One must include additional travel time costs, because public transportation is often slower than direct travel via car.
I'm not arguing for, or against, public transportation.
Speaking as a Principal Engineer at a Fortune 500 company... geo-engineering is not engineering.
Where is the rigor? Where is the testing? What are the consequences of failure? Might we make things worse?
The honest truth is that any geo-engineering is a global-scale gamble whose short and long term effects are completely unknown.
It is easy to see how geo-engineering could inflict more damage that it purports to solve — the climate is one of the most complex, chaotic systems known.
And we claim to have mastered our climate system enough to fix it??
Finally, fighting pollution with more pollution is counter-intuitive, to say the least.
This crap does not happen on Linux, on the same hardware. Most likely *BSD is not affected either, though I have not tested such.
It's almost a certainty that this is a software problem of some sort. Driver bugs are the most common source of "hardware" instability, particularly on Windows. Drivers are often written by clueless intern-level engineers, and quickly forgotten once the drivers initially pass based Windows hardware quality tests.
As I noted in a blog post, Serenity works much better as a TV format than a movie format. A TV series gives the creator much more time to build the characters and tell stories. Compared to 10+ hours of programming, a movie's 2 hours are barely enough to establish the characters, and tell a short story.
The comments attached to the linked blog post also offer some good insights and thoughts.
As I noted in this blog post, Firefly works better on TV than movie. A few of the reviews noted this, as well. A TV season, 12 hours or so of content, allows for much more character development and plot movement.
I wonder what the specifics of Joss's Fox agreement are? One commenter in my blog noted that Joss may be contractually barred from making further TV shows, but surely there is a way.
All it would have taken is ten minutes of searching on Google to discover what is going on.
You need a vaguely recent 2.6.x kernel to support fsync(2) and fdatasync(2) flushing your disk's write cache. Previous 2.4.x and 2.6.x kernels would only flush the write cache upon reboot, or if you used a custom app to issue the 'flush cache' command directly to your disk.
Very recent 2.6.x kernels include write barrier support, which flushes the write cache when the ext3 journal gets flushed to disk.
If your kernel doesn't flush the write cache, then obviously there is a window where you can lose data. Welcome to the world of write-back caching, circa 1990.
If you are stuck without a kernel that issues the FLUSH CACHE (IDE) or SYNCHRONIZE CACHE (SCSI) command, it is trivial to write a userspace utility that issues the command.
Most onboard audio chipsets don't even support multiple audio streams in hardware.
Completely false.
Pretty much all of the new on-board audio supports multiple channels (OS drivers may be another story!). The bleeding edge on-board audio even supports High Definition Audio.
Most of the high-volume motherboard chipset vendors -- Intel (the big fish), AMD, NVIDIA, SiS, ULi, VIA,... -- all implement the same advanced features in their chipsets: SATA2 NCQ, USB 2, HD audio, gigabit ethernet, and more. Just wait 3-6 months, and a new-and-spiffy ethernet/SATA/USB/audio feature will appear for free on a modern motherboard. If its a mass-market feature, of course.
Blindly choosing "no on-board devices" is rather silly. Today's mass market motherboard contains on-board devices, which means the cheapest motherboards give you that stuff for free. If the on-board device meets your feature requirements, use it. Sealed silicon interconnects are far more reliable than PCI slots anyway.
...speaking as the author of the [old OSS] VIA audio driver for Linux, and the sometimes-maintainer of the [old OSS] Intel/SiS/Nvidia/AMD audio driver for Linux, as well as other Linux drivers for on-board (and off-board) devices.
I have been waiting for ages to be able to build OpenOffice.org on 64-bit. When I'm unwinding from a long day of kernel work, I do silly things like porting Fedora Core to Alpha AXP or PA-RISC 64. OpenOffice.org and Mozilla are the two big packages that are a pain to port to new platforms.
It would really be nice if 0.000% of the openoffice.org effort devoted to press releases and promotion went instead to increasing the portability of the code:)
This lack of portability is really a pet peeve of mine. With Linux or NetBSD, you can run the same application on practically any hardware platform, just by recompiling... presuming the software was written without 32-bit assumptions. Linux (and NetBSD) becomes your portability layer, presuming your application meets some minimum standards.
Another pet peeve is that every big application re-invents cross-OS portability, which actually exacerbates the portability problem.
In my position, when you have 1000 packages to get running on Alpha AXP, each application's portability glue becomes a portability hindrance. As an example, Mozilla's portability layer is the reason why Mozilla does not build on alpha today.
Note that several of the cards reviewed in this review are not hardware RAID. SATA RAID is famous for being non-RAID controller + RAID software driver.
See my SATA RAID FAQ for a listing of the most common SATA chipsets which are sold as RAID, but are really software RAID (a.k.a. "fake RAID").
I'm also rather amazed that this wasn't mentioned in the review, but I admit I did not read all the of the 32 pages.
Claiming "no more late fees", especially in a big splashy ad campaign, and then charging you a fee 7 days later, is false advertising. Plain and simple. I'm with the state A.G. on that one. They deserve this lawsuit.
BlockBuster makes serious revenue on late fees (or whatever name you wish to call them). Someone on another claimed that 40% of their revenue is late fees, though I did not check this. Anyway, BlockBuster is not going to just give up that huge stream of revenue.
Claiming "no more late fees" was just a bone-headed idea. Hopefully B.B. will see that before too many Attorneys General look their way.
Wrong on every detail.
1a) Using the "move" RPC command, bitcoin makes an instant transfer between two accounts that you control.
1b) All transactions are published instantly, and available instantly, via the bitcoin P2P network. There are also several websites like http://mtgox.com/ which facilitate instant transfers. After that, you wait on average 10 minutes per confirmation, each of which makes your transaction exponentially more secure. While not recommended, yes you can spend zero-confirmation transactions.
2) Did you bother to look at Android Market before posting? Only full nodes require the full block chain database (2+ GB now). Lightweight software exists for phones, or you can use a web wallet from places like http://blockchain.info/ or http://instawallet.org/
- jgarzik, bitcoin core dev
Incorrect. Even if you have 100% of the network computing power, you still cannot force core rule changes upon users.
Each P2P node validates transactions and blocks on their own, and refuses to relay invalid ones. Deviating from these rules simply segments yourself away from the rest of the network.
With sufficient network power, you may DoS the network, but not force unwanted rule changes.
- jgarzik, bitcoin core dev
Note that most SATA controllers sold as RAID are really non-RAID hardware + software RAID in the BIOS and Windows driver.
Jeff, the Linux SATA maintainer, and author of several SATA drivers
You don't have a hardware or integrated RAID controller.
What you have is a non-RAID SATA controller, plus software RAID support in BIOS + Windows driver.
This is easiest to see when booting Linux, whose policy it is to only export your hardware, without any fakery.
See Linux SATA RAID FAQ for a clue...
The article refers to IANA, but I think it means ICANN.
The article's author apparently did not read IANA's About page, which states what every Internet geek already knows:
IANA executes policy; it does not create policy. Policy-making is left to working groups within ICANN and elsewhere.
It is easy to look at an individual, and say that costs are lower, especially if you doctor the numbers to assume everyone lives in New York City with high parking rates.
But that is only looking at part of the picture.
A fair comparison would included taxes paid to the city and state, and would include an assessment of what would happen if a majority of individuals started using public transportation for their given locale.
One must include car parking costs for park-and-ride lots, because not everyone can walk to a train station or bus stop.
One must include additional travel time costs, because public transportation is often slower than direct travel via car.
I'm not arguing for, or against, public transportation.
I only ask for a fair comparison.
"when the weather is completely out of control will people start demanding action"
This implies that the weather was... under control at some point in our history?
Our climate models are consistently wrong — either massively under-estimating or massively over-estimating climate change effects.
If we cannot even get the guesswork right, how can we ever hope to "engineer" the most complex, chaotic system in our world?
Speaking as a Principal Engineer at a Fortune 500 company... geo-engineering is not engineering.
Where is the rigor?
Where is the testing?
What are the consequences of failure?
Might we make things worse?
The honest truth is that any geo-engineering is a global-scale gamble whose short and long term effects are completely unknown.
It is easy to see how geo-engineering could inflict more damage that it purports to solve — the climate is one of the most complex, chaotic systems known.
And we claim to have mastered our climate system enough to fix it??
Finally, fighting pollution with more pollution is counter-intuitive, to say the least.
Quote: "Critics say the carriers will simply pass these fees through to consumers."
Critics, you say?
Customers pay all fees, expenses, taxes, and other costs related to wireless services. That is fundamentally how all businesses work.
Pointing out the basics of business is hardly being a critic.
This idea has been around since 2005 at least...
As has been noted, geo-engineering requires massive amounts of hubris and luck.
Geo-engineering is the act of fighting pollution... with yet more pollution!
And when you intentionally try to change a planet-wide system, all manner of unintended consequences will occur.
Now consider a proprietary company taking that code, and using it in a closed source product.
Quite legal, and it would be silly to assume that that code is in any GPL'd. The company chose the 'BSD' part of the 'BSD or GPL' dual license scheme.
The dual license is spelled out in quite plain English.
It's almost a certainty that this is a software problem of some sort. Driver bugs are the most common source of "hardware" instability, particularly on Windows. Drivers are often written by clueless intern-level engineers, and quickly forgotten once the drivers initially pass based Windows hardware quality tests.
The comments attached to the linked blog post also offer some good insights and thoughts.
I wonder what the specifics of Joss's Fox agreement are? One commenter in my blog noted that Joss may be contractually barred from making further TV shows, but surely there is a way.
Answer #1: it is softraid.
Answer #2: more and more mobos have SATA softRAID controllers built-in.
The way its being marketed and sold, it sounds like RAID capability is provided in hardware.
The hardware is not RAID hardware.
Any two or more drives can be RAID'd using software... And laptops have shipped in the past with more than one drive. None of this is news.
Read my SATA RAID FAQ.
It's all software RAID, provided by the BIOS and OS drivers.
Or in other words, its Softare RAID, provided by the marketing department.
Why start from scratch? It this simply because the Apache folks don't like the GPL?
You need a vaguely recent 2.6.x kernel to support fsync(2) and fdatasync(2) flushing your disk's write cache. Previous 2.4.x and 2.6.x kernels would only flush the write cache upon reboot, or if you used a custom app to issue the 'flush cache' command directly to your disk.
Very recent 2.6.x kernels include write barrier support, which flushes the write cache when the ext3 journal gets flushed to disk.
If your kernel doesn't flush the write cache, then obviously there is a window where you can lose data. Welcome to the world of write-back caching, circa 1990.
If you are stuck without a kernel that issues the FLUSH CACHE (IDE) or SYNCHRONIZE CACHE (SCSI) command, it is trivial to write a userspace utility that issues the command.
Completely false.
Pretty much all of the new on-board audio supports multiple channels (OS drivers may be another story!). The bleeding edge on-board audio even supports High Definition Audio.
Most of the high-volume motherboard chipset vendors -- Intel (the big fish), AMD, NVIDIA, SiS, ULi, VIA, ... -- all implement the same advanced features in their chipsets: SATA2 NCQ, USB 2, HD audio, gigabit ethernet, and more. Just wait 3-6 months, and a new-and-spiffy ethernet/SATA/USB/audio feature will appear for free on a modern motherboard. If its a mass-market feature, of course.
Blindly choosing "no on-board devices" is rather silly. Today's mass market motherboard contains on-board devices, which means the cheapest motherboards give you that stuff for free. If the on-board device meets your feature requirements, use it. Sealed silicon interconnects are far more reliable than PCI slots anyway.
Don't take my word for it, read the official statement from the subversion developers, "Please Stop Bugging Linus Torvalds About Subversion".
The kernel development model, as molded by BitKeeper, needs a highly decentalized model which encourages forks as a way of staging kernel changes.
It would really be nice if 0.000% of the openoffice.org effort devoted to press releases and promotion went instead to increasing the portability of the code :)
This lack of portability is really a pet peeve of mine. With Linux or NetBSD, you can run the same application on practically any hardware platform, just by recompiling... presuming the software was written without 32-bit assumptions. Linux (and NetBSD) becomes your portability layer, presuming your application meets some minimum standards.
Another pet peeve is that every big application re-invents cross-OS portability, which actually exacerbates the portability problem.
In my position, when you have 1000 packages to get running on Alpha AXP, each application's portability glue becomes a portability hindrance. As an example, Mozilla's portability layer is the reason why Mozilla does not build on alpha today.
See my SATA RAID FAQ for a listing of the most common SATA chipsets which are sold as RAID, but are really software RAID (a.k.a. "fake RAID").
I'm also rather amazed that this wasn't mentioned in the review, but I admit I did not read all the of the 32 pages.
- Claiming "no more late fees", especially in a big splashy ad campaign, and then charging you a fee 7 days later, is false advertising. Plain and simple. I'm with the state A.G. on that one. They deserve this lawsuit.
- BlockBuster makes serious revenue on late fees (or whatever name you wish to call them). Someone on another claimed that 40% of their revenue is late fees, though I did not check this. Anyway, BlockBuster is not going to just give up that huge stream of revenue.
Claiming "no more late fees" was just a bone-headed idea. Hopefully B.B. will see that before too many Attorneys General look their way.