I own a 2009 Optibike 850 -- an expensive toy, sure, but my pride and joy. It gets me to work and back in less time than driving followed by a gym session would require (and much less time than taking an unassisted bike both ways, which I've started doing on occasion as well), while being great exercise -- the way the Opti is geared encourages the rider to pedal along with a cadence in the 85-90 area, and my cholesterol and waistline are both way down since I dropped the car from commute duty.
I also like being able to take my ride inside the office with me rather than needing to fight for parking. (Motorcycle parking is close to the building too, so not a big deal when I ride my scooter... but getting a chance to work out on my way to and from work makes all the difference in the world in terms of stress, and having the workout be part of my commute means I stay with it).
[To readers not following this thread -- please see context before taking this literally; thanks].
If you can't trust/prove that who you are talking to on *this* Internet is an adult or a kid, how are you ever going to create another parallel system that somehow magically sorts out who the participants are based on some abstract idea such as age.
Legal consequences, of course! If letting a child use the "real" internet unsupervised is a crime, any adult on there can assume (for legal purposes) than anyone they're interacting with has reached the age of majority.
This would make for a great market in 3rd-party supervision -- your kid needs to use the "real" Internet for research or their work, but you're too busy? For just $2/hr, someone in India will watch over their shoulder (while multitasking N other childrens' shoulders as well) to see that they're safe and legal!
Which unfortunately will be a magnet for people who do want to have inappropriate conversations with kids.
I think that's part of the proposal's point: Better that the kids are off somewhere else, and any adults there are criminals, than that all adults anywhere be considered criminals just for innocently socializing with other parties online who happen to be underage.
Of course, the Right Thing is for this ingrained paranoia to be gotten rid of regardless.
Some of my best friends play FF11 with a social group which includes a child about their daughter's age; for the law to presume that they're doing so with evil intent is ridiculous, and cutting minors off from interaction with the rest of their communities in the name of "protection" is insane. I'm reminded of a study discussing the diminishing amount of freedom children have been given over the last several generations.
You could actually read the rest of the article, in which it indicates that this is not merely a CSRF-equivalent attack (as it was originally taken to be), as opposed to just reposting an out-of-context snippet chosen to make the editors look bad.
I was a Verizon customer almost a decade ago. When I tried to buy my first house, I had very little credit history -- to find something where I had a record of paying a monthly bill on time, every time, I called Verizon up and asked them to fax my mortgage agent my payment history. Their response? By policy, they could only do that if my payment history had at least one late or missed payment; as mine was perfect, they couldn't. I spent two days going up and down their management chain (or, at least, the portions accessible via escalating within customer support) trying to find someone who could make an exception to that stupid rule (and I never did find anyone who could explain why it was put in place).
The point? I promptly changed wireless providers in protest of this unreasonably poor customer service, an action which an ETF would have penalized. While I'm not necessarily arguing in favor of limiting freedom of contract at this time (though I do support some limitations -- see some of the abuses associated with mandatory binding arbitration in consumer contracts for a clear example), having consumers able to take their business elsewhere in response to poor service is, generally speaking, good policy.
Yes, I need to have some kind of insurance even when in a rented vehicle. However, my insurance provides liability-only coverage for the rental car without extra charge as long as I'm purchasing at least 1000 miles per 6 months for my primary vehicle; coverage beyond that (ie. for damage to the rental itself) can be purchased from the company I'm renting it through.
As I'm only doing this a few times a year, it makes sense.
Highway miles are easy on your auto; it's city driving the ruins your car. That extra 1000 km from your trip isn't going to make your car's resale value any lower, and renting a car isn't going to make your car last any longer.
Yes, but I buy my auto insurance by the mile (full coverage for under $40/month with my current driving level), so long-distance driving costs more than a rental regardless.
But people only get the liability shield when they're getting income from a corporation, not (for instance) a sole proprietorship. How do you propose to put this burden where due? Bump the capital gains tax up 10% (or whatever) only for income from stock held in liability-shielded businesses? Seems ridiculous on its face.
Not everyone does long-distance highway travel more than once or twice a year -- I don't, anyhow, and when I do, I rent a car rather than putting the miles on mine anyhow.
Range may legitimately keep electric cars out of some markets, but certainly not all of them.
Corporations have substantial benefits that other forms of businesses don't -- the shareholders are protected from liability for the corporation's debts, and the board members are protected from personal liability for the corporation's actions (within limits).
Is it reasonable that those benefits come without cost? I'm not saying that the current cost structure is commensurate or fair -- perhaps corporate taxes as they now exist could be replaced with compulsory participation in a risk pool -- but providing them free of charge doesn't strike me as right.
It was missing in 1.0, but A2DP works just fine in 1.5. (I'm still waiting for RFCOMM to be exposed to the application layer, but that's a different story).
While I don't actually do the conflating in the quote you mention, it is a natural consequence of public spending. One-time consumption (which rarely actually gets all spent at one time) of OPM routinely becomes indefinite consumption of OPM.
It's undoubtedly true that programs intended to be self-funding are not always so -- but to read that this is always true (or near enough to the same as to be usable as a premise in a debate with a third party who doesn't accept your assumptions) strikes me as akin to resorting to "but the Bible says so" in a discussion with an atheist. If there's no commonality of premises, how can one have reasonable and rational discussion of conclusions?
Sure, it's a pilot program. But my beef has been that it is so heavily subsidized (and you and I both know what subsidies mean) that we can't conclude how successful the program really is. With enough other peoples' money, you can do anything. As I see it, it's also a boondoggle, a tremendous waste of public funds to little consequence.
You're conflating Other Peoples' Money used for one-time costs with Other Peoples' Money used for ongoing operation.
The capital required to set the system up in the first place is completely irrelevant to whether the infrastructure is self-sufficient on an ongoing operation basis, which is how any claim of "self sufficiency" is generally understood.
No. That's not how self-sufficient is generally understood. But you make my point in the next paragraph.
Quoting from the Wikipedia article: Self-sufficiency refers to the state of not requiring any outside aid, support, or interaction, for survival; it is therefore a type of personal or collective autonomy.
This refers to an immediate state, independent of how that state was achieved.
I never saw any indication that this actually saved money. If it actually does, then we can consider whether it saves more than the interest cost of the capital outlay.
If the energy needs of the island are able to be met without sending the island's funds outside on an ongoing basis, there is no question that money is saved from the perspective of the economy of the island as a whole; the only question, then, is whether the interest and maintenance costs of the infrastructure exceed the funds which would otherwise be spent on ongoing energy imports.
1) they took a lot of somebody else's money to build this infrastructure. That's one strike against the claim of self-sufficiency.
Let me distill what others in this thread have been trying to make clear:
The capital required to set the system up in the first place is completely irrelevant to whether the infrastructure is self-sufficient on an ongoing operation basis, which is how any claim of "self sufficiency" is generally understood.
The reasonable counterargument would be that any interest paid on the initial outlay should be counted against "self-sufficient" status, and such a counterargument is one I'm willing to accept -- if you have the numbers to sustain the argument that the cost of funds outweighs the ongoing expenses avoided. Are you prepared to make that argument?
Why would you not let folks own outright disks containing copyrighted software as well?
Just because I own a disk doesn't mean I own the copyright to the software on the disk, and that copyright prevents me from making copies (or public performances, or several other things explicitly listed by copyright law) without paying the copyright owner for permission to do so. While it does permit restrictions on making of copies, public performance, preparation of derivative works and the like, however, copyright law does not allow the copyright owner to determine whether I can resell an embodiment of their work -- this is why Autodesk has resorted to licensing to do so.
The question, though, is this: Why is there a compelling public-interest need to allow copyright owners to extend their control over embodiments of their works beyond that which copyright law already provides?
Answer that question, and we'll have a better understanding of each others' positions.
If you say "cheap console" and mean a PS3 or Xbox 360, and I say "cheap console" and am talking about the vintage VT220 sitting in the garage... let's say we're in different worlds.:)
Until I started following links, I thought we were going for retro I/O -- a game with lots of players, and a grunt/commander split, all rendered to ASCII and running in a terminal.
On finding the truth... okay, it's pretty, but I'm very disappointed.
The win32 virtio-net drivers have been available for ages, albeit closed-source, and the win32 virtio-blk drivers haven't been through performance optimization yet and are slower than qemu's default IDE emulation. So -- *yawn*.
Wake me up when the virtio-blk port is fast; until then, this is interesting to anyone with a copy of the Windows DDK and an interest in helping out, but not necessarily so much for the rest of the world.
You have the option to describe your app's GUI with XML. Nothing forces you to do it that way -- though given the host-side tools you can use to lay out or simulate those GUIs, it can be a handy approach.
Not unprecedented, either -- see libglade, which is one of the easier ways to build (non-mobile) GUIs with GTK.
Earlier versions of the published API are supported in later releases, period. Nobody releases phones based on beta/release-candidate/unpublished APIs -- that's just not done.
On the other hand, documentation for those API releases is floating around the Internet, and if you're googling for the method you want to do and get an unpublished API nobody supported and nobody ever actually shipped on a hardware phone -- well, if you try to follow that documentation instead of the docs installed on your machine when you installed the Android 1.5 SDK you're doing a damned stupid thing.
If you're writing for an Android 1.5 phone, you should follow Android 1.5 docs -- not Android donut snapshot-from-3-weeks-before-release, which is out there and floating around and indexed by Google. The Android 1.1 phones have pretty much all been upgraded over-the-air by their carriers by now, so you could certainly follow the docs for 1.1 and build against that too (and those apps would work on 1.5), but there's not exactly much of a point.
Following whatever docs Google happens to find for you when you look for something without checking whether those docs correspond with an actual released version of the platform that anyone, anywhere ever loaded on non-dev hardware... that's just boneheaded.
The API is unstable only if you count versions which never became supported releases -- to go back to the RFCOMM API, there was an implementation in an RC that was cut from Android 1.0, but since it never made it into a release, the Android team never committed to maintaining support for applications using it.
Those APIs which did make it into Android 1.0 haven't gone anywhere, and won't go anywhere -- that's the whole reason APIs they weren't willing to commit to long-term got cut despite having working implementations in the RC.
If you call variability between RC and release instability, there's instability... but upstream has yet to abandon an API they committed to supporting.
I'm curious -- have you done any development for Android, or are you armchair'ing this one?
They've been _extremely_ careful about what is declared a public API, to the point of holding back features on account thereof. That's one of the major reasons RFCOMM support (to pick something dear to my heart) has been unavailable for developers in every version released so far -- they're unwilling to declare the API stable until they have something they know they'll be able to maintain through newer versions of BlueZ and security audits/updates, and their compiler flags any attempts at using anything which isn't a public API (they've also released updates which break attempts to get around these measures and build software using version-specific, unreleased APIs).
Personally, I expect Android to take off on a larger scale when the fleet of phones expected to release late this year (from numerous manufacturers) make it out their respective doors.
Generally the registrar will set up DNS hosting on their servers by default, with "www" pointing to one of their web servers showing an ad-laden "parking" page, regardless of what you intend to change it to in 15 minutes.
I don't doubt that it's common, but that's a pretty evil practice (abusive, even -- that domain is their customer's property; how is it their business to put anything there?). I use NearlyFreeSpeech, and they don't do anything of that sort.
Slashdot Mirror
For one thing -- exercise!
I own a 2009 Optibike 850 -- an expensive toy, sure, but my pride and joy. It gets me to work and back in less time than driving followed by a gym session would require (and much less time than taking an unassisted bike both ways, which I've started doing on occasion as well), while being great exercise -- the way the Opti is geared encourages the rider to pedal along with a cadence in the 85-90 area, and my cholesterol and waistline are both way down since I dropped the car from commute duty.
I also like being able to take my ride inside the office with me rather than needing to fight for parking. (Motorcycle parking is close to the building too, so not a big deal when I ride my scooter... but getting a chance to work out on my way to and from work makes all the difference in the world in terms of stress, and having the workout be part of my commute means I stay with it).
[To readers not following this thread -- please see context before taking this literally; thanks].
Legal consequences, of course! If letting a child use the "real" internet unsupervised is a crime, any adult on there can assume (for legal purposes) than anyone they're interacting with has reached the age of majority.
This would make for a great market in 3rd-party supervision -- your kid needs to use the "real" Internet for research or their work, but you're too busy? For just $2/hr, someone in India will watch over their shoulder (while multitasking N other childrens' shoulders as well) to see that they're safe and legal!
I think that's part of the proposal's point: Better that the kids are off somewhere else, and any adults there are criminals, than that all adults anywhere be considered criminals just for innocently socializing with other parties online who happen to be underage.
Of course, the Right Thing is for this ingrained paranoia to be gotten rid of regardless.
Some of my best friends play FF11 with a social group which includes a child about their daughter's age; for the law to presume that they're doing so with evil intent is ridiculous, and cutting minors off from interaction with the rest of their communities in the name of "protection" is insane. I'm reminded of a study discussing the diminishing amount of freedom children have been given over the last several generations.
*sigh*.
Get off my lawn!
You could actually read the rest of the article, in which it indicates that this is not merely a CSRF-equivalent attack (as it was originally taken to be), as opposed to just reposting an out-of-context snippet chosen to make the editors look bad.
Clearly, my memory is getting hazy in my old age.
I was a Verizon customer almost a decade ago. When I tried to buy my first house, I had very little credit history -- to find something where I had a record of paying a monthly bill on time, every time, I called Verizon up and asked them to fax my mortgage agent my payment history. Their response? By policy, they could only do that if my payment history had at least one late or missed payment; as mine was perfect, they couldn't. I spent two days going up and down their management chain (or, at least, the portions accessible via escalating within customer support) trying to find someone who could make an exception to that stupid rule (and I never did find anyone who could explain why it was put in place).
The point? I promptly changed wireless providers in protest of this unreasonably poor customer service, an action which an ETF would have penalized. While I'm not necessarily arguing in favor of limiting freedom of contract at this time (though I do support some limitations -- see some of the abuses associated with mandatory binding arbitration in consumer contracts for a clear example), having consumers able to take their business elsewhere in response to poor service is, generally speaking, good policy.
Yes, I need to have some kind of insurance even when in a rented vehicle. However, my insurance provides liability-only coverage for the rental car without extra charge as long as I'm purchasing at least 1000 miles per 6 months for my primary vehicle; coverage beyond that (ie. for damage to the rental itself) can be purchased from the company I'm renting it through.
As I'm only doing this a few times a year, it makes sense.
Yes, but I buy my auto insurance by the mile (full coverage for under $40/month with my current driving level), so long-distance driving costs more than a rental regardless.
But people only get the liability shield when they're getting income from a corporation, not (for instance) a sole proprietorship. How do you propose to put this burden where due? Bump the capital gains tax up 10% (or whatever) only for income from stock held in liability-shielded businesses? Seems ridiculous on its face.
Not everyone does long-distance highway travel more than once or twice a year -- I don't, anyhow, and when I do, I rent a car rather than putting the miles on mine anyhow.
Range may legitimately keep electric cars out of some markets, but certainly not all of them.
Now, waitamoment:
Corporations have substantial benefits that other forms of businesses don't -- the shareholders are protected from liability for the corporation's debts, and the board members are protected from personal liability for the corporation's actions (within limits).
Is it reasonable that those benefits come without cost? I'm not saying that the current cost structure is commensurate or fair -- perhaps corporate taxes as they now exist could be replaced with compulsory participation in a risk pool -- but providing them free of charge doesn't strike me as right.
It was missing in 1.0, but A2DP works just fine in 1.5. (I'm still waiting for RFCOMM to be exposed to the application layer, but that's a different story).
Also, while it may require USB rather than running over Bluetooth, but Android tethers quite well.
It's undoubtedly true that programs intended to be self-funding are not always so -- but to read that this is always true (or near enough to the same as to be usable as a premise in a debate with a third party who doesn't accept your assumptions) strikes me as akin to resorting to "but the Bible says so" in a discussion with an atheist. If there's no commonality of premises, how can one have reasonable and rational discussion of conclusions?
You're conflating Other Peoples' Money used for one-time costs with Other Peoples' Money used for ongoing operation.
Quoting from the Wikipedia article: Self-sufficiency refers to the state of not requiring any outside aid, support, or interaction, for survival; it is therefore a type of personal or collective autonomy.
This refers to an immediate state, independent of how that state was achieved.
If the energy needs of the island are able to be met without sending the island's funds outside on an ongoing basis, there is no question that money is saved from the perspective of the economy of the island as a whole; the only question, then, is whether the interest and maintenance costs of the infrastructure exceed the funds which would otherwise be spent on ongoing energy imports.
Let me distill what others in this thread have been trying to make clear:
The capital required to set the system up in the first place is completely irrelevant to whether the infrastructure is self-sufficient on an ongoing operation basis, which is how any claim of "self sufficiency" is generally understood.
The reasonable counterargument would be that any interest paid on the initial outlay should be counted against "self-sufficient" status, and such a counterargument is one I'm willing to accept -- if you have the numbers to sustain the argument that the cost of funds outweighs the ongoing expenses avoided. Are you prepared to make that argument?
Why would you not let folks own outright disks containing copyrighted software as well?
Just because I own a disk doesn't mean I own the copyright to the software on the disk, and that copyright prevents me from making copies (or public performances, or several other things explicitly listed by copyright law) without paying the copyright owner for permission to do so. While it does permit restrictions on making of copies, public performance, preparation of derivative works and the like, however, copyright law does not allow the copyright owner to determine whether I can resell an embodiment of their work -- this is why Autodesk has resorted to licensing to do so.
The question, though, is this: Why is there a compelling public-interest need to allow copyright owners to extend their control over embodiments of their works beyond that which copyright law already provides?
Answer that question, and we'll have a better understanding of each others' positions.
If you say "cheap console" and mean a PS3 or Xbox 360, and I say "cheap console" and am talking about the vintage VT220 sitting in the garage... let's say we're in different worlds. :)
Until I started following links, I thought we were going for retro I/O -- a game with lots of players, and a grunt/commander split, all rendered to ASCII and running in a terminal.
On finding the truth... okay, it's pretty, but I'm very disappointed.
The win32 virtio-net drivers have been available for ages, albeit closed-source, and the win32 virtio-blk drivers haven't been through performance optimization yet and are slower than qemu's default IDE emulation. So -- *yawn*.
Wake me up when the virtio-blk port is fast; until then, this is interesting to anyone with a copy of the Windows DDK and an interest in helping out, but not necessarily so much for the rest of the world.
You have the option to describe your app's GUI with XML. Nothing forces you to do it that way -- though given the host-side tools you can use to lay out or simulate those GUIs, it can be a handy approach.
Not unprecedented, either -- see libglade, which is one of the easier ways to build (non-mobile) GUIs with GTK.
OK -- I see the statement you're replying to.
Earlier versions of the published API are supported in later releases, period. Nobody releases phones based on beta/release-candidate/unpublished APIs -- that's just not done.
On the other hand, documentation for those API releases is floating around the Internet, and if you're googling for the method you want to do and get an unpublished API nobody supported and nobody ever actually shipped on a hardware phone -- well, if you try to follow that documentation instead of the docs installed on your machine when you installed the Android 1.5 SDK you're doing a damned stupid thing.
If you're writing for an Android 1.5 phone, you should follow Android 1.5 docs -- not Android donut snapshot-from-3-weeks-before-release, which is out there and floating around and indexed by Google. The Android 1.1 phones have pretty much all been upgraded over-the-air by their carriers by now, so you could certainly follow the docs for 1.1 and build against that too (and those apps would work on 1.5), but there's not exactly much of a point.
Following whatever docs Google happens to find for you when you look for something without checking whether those docs correspond with an actual released version of the platform that anyone, anywhere ever loaded on non-dev hardware... that's just boneheaded.
The API is unstable only if you count versions which never became supported releases -- to go back to the RFCOMM API, there was an implementation in an RC that was cut from Android 1.0, but since it never made it into a release, the Android team never committed to maintaining support for applications using it.
Those APIs which did make it into Android 1.0 haven't gone anywhere, and won't go anywhere -- that's the whole reason APIs they weren't willing to commit to long-term got cut despite having working implementations in the RC.
If you call variability between RC and release instability, there's instability... but upstream has yet to abandon an API they committed to supporting.
I'm curious -- have you done any development for Android, or are you armchair'ing this one?
They've been _extremely_ careful about what is declared a public API, to the point of holding back features on account thereof. That's one of the major reasons RFCOMM support (to pick something dear to my heart) has been unavailable for developers in every version released so far -- they're unwilling to declare the API stable until they have something they know they'll be able to maintain through newer versions of BlueZ and security audits/updates, and their compiler flags any attempts at using anything which isn't a public API (they've also released updates which break attempts to get around these measures and build software using version-specific, unreleased APIs).
Personally, I expect Android to take off on a larger scale when the fleet of phones expected to release late this year (from numerous manufacturers) make it out their respective doors.
I don't doubt that it's common, but that's a pretty evil practice (abusive, even -- that domain is their customer's property; how is it their business to put anything there?). I use NearlyFreeSpeech, and they don't do anything of that sort.