Sure, but when we have an article about the actions BP is taking to avoid future spills, it's also topical to talk about what Exxon is doing likewise. Further, taking a comment that applies industrywide and adding a great deal of verbiage with no effect other than narrowing its scope to only apply to BP without despite the arguments applying to other companies makes it seem like the poster has an agenda, or a chip on their shoulder, or a belief that some oil company other than BP can do no wrong, even if it's just a news item about BP that started the conversation as a whole.
I agree -- there are areas where the patent system works; software just isn't one of them.
I've built a few software products I would describe as innovative over the course of my career. In each case, the "inventive step" involved taking a good idea originally conceived for one application and applying it to a completely different purpose. In each case, this was a 5-minute "a-ha" moment, followed by weeks to years of development effort to build an embodiment.
I don't feel any entitlement to a 20-year monopoly for that "a-ha" -- for had the original idea I cribbed from in any of these cases been strongly protected, my own new application might have been foreclosed; shoulders of giants and all that. The real money in each case went not into funding my 5-minute "a-ha", but rather the follow-on development, and that's what copyright is there to protect.
The thing that really chaps my hide about software patents, though, is this: In each of these cases, this software may have had one "innovative" algorithm at its core. Presume that using this algorithm for this purpose had never before been done and was innovative and patentable -- fine and well. However, the larger embodiment of this software, like any other program, is composed of code -- code that by its very definition does nothing but describe and embody algorithms! Software developers are paid to invent and build embodiments of algorithms (and to reuse and adapt well-known published algorithms); it's the very definition of what we do day-to-day, and the number of algorithms involved in the embodiment of any software project of real-world size is necessarily huge -- with many of these algorithms created on-the-fly. I can't imagine the number of potential infringements involved in any and every complex piece of software; if such algorithm patents were both widely granted and automatically enforced in every case in which they were infringed, the number of patent infringements involved in building any piece of real-world software would be so unworkably huge as to bring any kind of effort at development activity to a complete and total standstill.
And that's really my core problem with software patents. I can't sanction or participate in a system with potential to destroy my ability to create; with a system that makes "cheap" actions -- the very essence of the creative work that I and millions of others do day-to-day -- into an activity strewn with legal landmines and thus accessible only to those with deep pockets or extensive cross-licensing portfolios.
If drug patents are not awarded for "cheap" actions, but rather for something which requires extensive investment and risk, my concerns don't apply there, and I don't wish to tear down something that works for others; I simply cannot abide the idea of a world where I did not have the freedom to create the things I envision.
seriously, how many system administrators even take their time to compile custom kernels nowadays for maximum performance?
That's a bug, not a feature.
"Maximum performance"? If it's storing customer data, I want a kernel that's had heavy automated testing, a full round of manual QA, and validation by my hardware vendor, thank you very much.
A small medical software startup I once worked at had some extra office space we weren't using, which we donated to a local non-profit doing research to help support policy making on health-related issues.
We were working on folding tables with the cheapest office equipment we could get; they had beautiful wood desks, a huge high-speed copier/fax/scanner, bought (excellent) SNOM VoIP phones compared to the cheapo Grandstreams we were using, and otherwise clearly paid far, far less attention to minimizing their expenses.
By taking the position that "this problem is only ever caused by folks of $THIS political persuasion", you indicate that you intend to ignore (or not look for, or not accept if found) instances where the contrary is true.
Take a sibling post's point -- that this is happening in a small town in Texas, a state which recently made news for actions taken by a right-leaning board of education -- and consider that perhaps inflexible and overreaching policy should be recognized and opposed regardless of who introduces it.
I'm actually aware of the distinction (though admittedly, my prior post didn't state as much) -- but honestly, I don't find it reasonable to expect that state police will treat citizens they incorrectly suspect of being illegal any better than ICE does already. Demonstrating that the agencies already charged with this task mess it up in such a way as to unreasonably interfere in citizens' lives is, in my view, quite sufficient to bring to light concerns with overzealous enforcement attempts in general.
In this case, the ICE officer decided they could detain this citizen because, while being interviewed, he stated that his mother was in Mexico; his office stood behind him on that decision. This is, likewise, more than "a hunch"... but lead to an utterly unacceptable result. Why would we promulgate a system which leads to this kind of situation further?
Actually the Arizona law allows the Drivers License as a presumption of legal residency. So for the purposes of this law, if you can show them a valid driver's license, then you are presumed to be here legally and have no more documentation to worry about.
I'm in Austin. It's expected that employers (at least, employers anyone actually wants to work for) will provide shower facilities here, or at a bare minimum sponsor membership at a nearby gym. My current employer actually goes as far as to make their company gym's shower facilities open to cycle commuters free, complete with shampoo/conditioner/body wash/spray deodorant/mouthwash/etc included, though that's a bit further than anywhere else I've been goes. It's a great program -- saves the company money on health insurance premiums, saves me money in hot water and shampoo and such I don't need to buy myself.
If employers in Florida don't feel that same obligation... well, time to start working on the local culture until they do.:)
This is a very restricted problem domain, though -- we're evaluating a function with no state between invocations, we know the range of most of the inputs (and which of the inputs are controlled by market forces and which of them can be more directly manipulated by the "attacker"). We don't need a fully automated analysis tool -- if we determine which code paths aren't invoked during common-case analysis and point them out for human intervention, that's enough to do quite a bit of good right there.
In any event, you don't have the fuzzy variables of "what can the judge be convinced of" in play. Put in the same inputs, you get the same outputs; that's a vast improvement over the disclosure statements of today.
Sure, but it's better to have that hack disclosed in such a way that machine analysis can find it than disclosed in such a way that it only becomes evident after a corporate lawyer brings up an obscure precedent to a judge.
Meh. If I were going to work on a microkernel-based OS, I'd rather it be something like QNX or FMI/OS (formerly VSTa); something small and focused on embedded space rather than trying to be a general-purpose OS, with all the work and headaches that implies. HURD's system requirements (32MB RAM?!) and the project's general lack of direction makes it poison to anyone who wants to go out there and use what they've learned to build an embedded product.
There's lots of hobbyist-targeted embedded hardware around, and qemu's gdb support provides development capabilities that previously would have meant shelling out thousands for an Abatron; embedded space is a good place for a budding hobbyist to be, and also provides ample opportunities to use less-mainline operating systems (after all, unless your hardware is network-attached, the set of external interactions is finite and straightforward to test; also, advantages of microkernel operating systems -- being able to restart subsystems whose failures would be kernel panics in a monolithic kernel -- can be argued as a substantial advantage in end-to-end system robustness).
It IS luggage on the train as opposed to carrying luggage.
A conventional bicycle, yes. A folding bicycle, no.
It is totally impractical for use in any kind of adverse weather, either hot or cold.
Speaking as a year-round cycle commuter in Texas, I believe my contrary experience a bit more authoritative.
It's range is limited.
Its range has to be good enough for the "last mile" from the train station to your destination. If a conventional bicycle isn't adequate for the distance being covered, an electric bicycle will get 15-30mph; that's entirely comparable to in-town rush hour traffic speeds for motorized vehicles.
It also doesn't come anywhere near solving the problem of having to sit next to someone who just pissed themselves on the train.
Can't say I've experienced that; seems rather on the made-up side, as problems go.
(Please pardon the snark; it's late and I'm tired).
To be fair, even in countries with very well off public transportation, the majority of people live in the same city as they work, and a train will not run door to door or even close.
Try living in a major city. They tend to have this thing called "light rail" or "commuter rail", or "subways" -- a system of trains intended for use by (guess who) commuters! They don't run door-to-door, granted, but they do connect to the bus systems and welcome folding bicycles (and be at least moderately welcoming to conventional non-folding bicycles), both of which are better suited to addressing to the last-mile problem. (The light rail system in the South Bay area is great, by the way -- I used that to get to work in Sunnyvale from Mountain View and San Jose while working in that area around the tail end of the tech boom. I don't claim that every major US city has a competent commuter rail system -- but certainly many of the larger ones do, particularly when subways are taken into account).
Granted, these systems don't exist everywhere -- but arguably, that's a reason to put them in where they aren't. A good transit system is subsidized around the same level as highways tend to be in the US (while it used to be more, highways are not much over 50% funded by user fees anymore), can get ~40% usage for trips in which it is competitive, and thus does a great deal of use in terms of reducing traffic congestion and enabling higher population densities for the same road infrastructure.
As a car replacement option, walking would be a better replacement, as with all the suck that comes with walking, at least it will eventually do the same thing as driving (IE get you to and from the places you want to get at 99% of the time)
Eh? Pretty lousy mass transit system where train+walk (or better, train+bike) is worse than walking alone (for a long enough trip to justify the system's use). Sure, a train isn't door-to-door... but if the system is effective, then what you have is the last mile problem, as opposed to what might be a 15 mile trip.
A folding bike is a great solution to the last-mile problem; it fits on a bus or train easily (even if the racks for conventional bikes are full), or in airline-standard luggage -- and you can fold it up and take it inside when you reach where you're going.
Make the trains flatbeds with stations that have ramps on both sides so that the commuters can drive their flexible cars up one side and park on the train.
You want to carry around at least 1000 pounds of metal for each set of passengers, plus all the extra mass involved in adding the space in the trains themselves (to be able to house the cars)? The number of passengers to a train (for a given level of purchase and operational costs) just went down substantially.
I'm a big fan of folding bicycles -- waiting anxiously for a custom Bike Friday Tikit to be delivered. The Tikit folds for getting on or off of transit in <5 seconds, or can be packed into an airline-standard suitcase, with enough room to also hold a disassembled trailer in that suitcase -- a trailer capable of pulling the suitcase itself behind the bike! This makes it possible to travel by air and not need to rent a car on arrival -- your vehicle is there in your luggage, and capable of *pulling* the rest of your luggage (in the now-empty suitcase) as well. For those that need to travel further on either end than can be done without sweating in one's business attire (and for whom sweating is not an option -- I personally prefer to get my exercise done on my commute and shower on arrival at the office), several 3rd-party electric-assist conversion options are available, and one officially supported e-Tikit is in the works.
Yes, for a folding bike cargo capacity is a concern relative to a passenger car -- but so is space on trains. (The Tikit can be equipped to mount 4-5 luggage bags, but only one while folded). Outside of folding bikes, there are numerous cargo-carrying options available; it's quite possible to mount an Xtracycle on a standard bus/train rack (with a little preparation), and those can carry an astonishing amount of cargo.
I don't argue that use of cars is evil. I do take the position that pairing cars with trains is impractical. A folding bicycle, electric or otherwise, is a far more practical vehicle for that kind of use; it's hand-carryable, requires no more luggage space than a suitcase or folding stroller, can be taken inside at your destination (rather than need to lock it up, as is the case for a full-size bicycle), and requires no redesign of existing infrastructure.
Dunno -- the cutting-edge people I know are digging on Clojure pretty hard.
Yes, Java-the-language sucks hard. Yes, it took them waaay too long to get better bytecode-level support for languages that don't conform to their typing model (see JSR 292). Even with these things being true, there are some cutting-edge languages that target the Java platform, so I'm not about to call it dead to me yet.
(Other cutting-edge people I interact with are targeting things like OCaml -- but I'm maybe a little too pragmatic to go there just yet myself).
I wear SAS (San Antonio Shoes, made here in Texas). Their style is undoubtedly old-school (I'd guesstimate that 1/3 of the fellow customers I see in there are near- or post-retirement-age, though they're trying to remedy that somewhat with new products), but they're extremely comfy and the sales staff (they have outlets here in Austin) knows their stuff.
Slashdot Mirror
Sure, but when we have an article about the actions BP is taking to avoid future spills, it's also topical to talk about what Exxon is doing likewise. Further, taking a comment that applies industrywide and adding a great deal of verbiage with no effect other than narrowing its scope to only apply to BP without despite the arguments applying to other companies makes it seem like the poster has an agenda, or a chip on their shoulder, or a belief that some oil company other than BP can do no wrong, even if it's just a news item about BP that started the conversation as a whole.
sed -i \
-e s/Islamic// \
-e 's/[.] Muslims/. Fundamentalists/' \
-e s/Muslims/fundamentalists/
With those replacements made, is the position espoused something you would support? Why or why not?
I agree -- there are areas where the patent system works; software just isn't one of them.
I've built a few software products I would describe as innovative over the course of my career. In each case, the "inventive step" involved taking a good idea originally conceived for one application and applying it to a completely different purpose. In each case, this was a 5-minute "a-ha" moment, followed by weeks to years of development effort to build an embodiment.
I don't feel any entitlement to a 20-year monopoly for that "a-ha" -- for had the original idea I cribbed from in any of these cases been strongly protected, my own new application might have been foreclosed; shoulders of giants and all that. The real money in each case went not into funding my 5-minute "a-ha", but rather the follow-on development, and that's what copyright is there to protect.
The thing that really chaps my hide about software patents, though, is this: In each of these cases, this software may have had one "innovative" algorithm at its core. Presume that using this algorithm for this purpose had never before been done and was innovative and patentable -- fine and well. However, the larger embodiment of this software, like any other program, is composed of code -- code that by its very definition does nothing but describe and embody algorithms! Software developers are paid to invent and build embodiments of algorithms (and to reuse and adapt well-known published algorithms); it's the very definition of what we do day-to-day, and the number of algorithms involved in the embodiment of any software project of real-world size is necessarily huge -- with many of these algorithms created on-the-fly. I can't imagine the number of potential infringements involved in any and every complex piece of software; if such algorithm patents were both widely granted and automatically enforced in every case in which they were infringed, the number of patent infringements involved in building any piece of real-world software would be so unworkably huge as to bring any kind of effort at development activity to a complete and total standstill.
And that's really my core problem with software patents. I can't sanction or participate in a system with potential to destroy my ability to create; with a system that makes "cheap" actions -- the very essence of the creative work that I and millions of others do day-to-day -- into an activity strewn with legal landmines and thus accessible only to those with deep pockets or extensive cross-licensing portfolios.
If drug patents are not awarded for "cheap" actions, but rather for something which requires extensive investment and risk, my concerns don't apply there, and I don't wish to tear down something that works for others; I simply cannot abide the idea of a world where I did not have the freedom to create the things I envision.
That's a bug, not a feature.
"Maximum performance"? If it's storing customer data, I want a kernel that's had heavy automated testing, a full round of manual QA, and validation by my hardware vendor, thank you very much.
Of course money has a price; it's called "interest".
A small medical software startup I once worked at had some extra office space we weren't using, which we donated to a local non-profit doing research to help support policy making on health-related issues.
We were working on folding tables with the cheapest office equipment we could get; they had beautiful wood desks, a huge high-speed copier/fax/scanner, bought (excellent) SNOM VoIP phones compared to the cheapo Grandstreams we were using, and otherwise clearly paid far, far less attention to minimizing their expenses.
By taking the position that "this problem is only ever caused by folks of $THIS political persuasion", you indicate that you intend to ignore (or not look for, or not accept if found) instances where the contrary is true.
Take a sibling post's point -- that this is happening in a small town in Texas, a state which recently made news for actions taken by a right-leaning board of education -- and consider that perhaps inflexible and overreaching policy should be recognized and opposed regardless of who introduces it.
Being read to the person being arrested, not to the witnesses. Read the parent's assertion more closely.
Fully agreed. That said, there's an alternate xlive.dll you can download which gets rid of all that crap.
I'm actually aware of the distinction (though admittedly, my prior post didn't state as much) -- but honestly, I don't find it reasonable to expect that state police will treat citizens they incorrectly suspect of being illegal any better than ICE does already. Demonstrating that the agencies already charged with this task mess it up in such a way as to unreasonably interfere in citizens' lives is, in my view, quite sufficient to bring to light concerns with overzealous enforcement attempts in general.
In this case, the ICE officer decided they could detain this citizen because, while being interviewed, he stated that his mother was in Mexico; his office stood behind him on that decision. This is, likewise, more than "a hunch"... but lead to an utterly unacceptable result. Why would we promulgate a system which leads to this kind of situation further?
Hmm. That doesn't really explain the case of the truck driver who was taken into the station until his wife could arrive with his birth certificate (despite having his commercial driver's license with him).
And you learned all you needed to know about white guys who hate big government on 4/19/1995?
Re smell after riding --
I'm in Austin. It's expected that employers (at least, employers anyone actually wants to work for) will provide shower facilities here, or at a bare minimum sponsor membership at a nearby gym. My current employer actually goes as far as to make their company gym's shower facilities open to cycle commuters free, complete with shampoo/conditioner/body wash/spray deodorant/mouthwash/etc included, though that's a bit further than anywhere else I've been goes. It's a great program -- saves the company money on health insurance premiums, saves me money in hot water and shampoo and such I don't need to buy myself.
If employers in Florida don't feel that same obligation... well, time to start working on the local culture until they do. :)
This is a very restricted problem domain, though -- we're evaluating a function with no state between invocations, we know the range of most of the inputs (and which of the inputs are controlled by market forces and which of them can be more directly manipulated by the "attacker"). We don't need a fully automated analysis tool -- if we determine which code paths aren't invoked during common-case analysis and point them out for human intervention, that's enough to do quite a bit of good right there.
In any event, you don't have the fuzzy variables of "what can the judge be convinced of" in play. Put in the same inputs, you get the same outputs; that's a vast improvement over the disclosure statements of today.
Sure, but it's better to have that hack disclosed in such a way that machine analysis can find it than disclosed in such a way that it only becomes evident after a corporate lawyer brings up an obscure precedent to a judge.
Meh. If I were going to work on a microkernel-based OS, I'd rather it be something like QNX or FMI/OS (formerly VSTa); something small and focused on embedded space rather than trying to be a general-purpose OS, with all the work and headaches that implies. HURD's system requirements (32MB RAM?!) and the project's general lack of direction makes it poison to anyone who wants to go out there and use what they've learned to build an embedded product.
There's lots of hobbyist-targeted embedded hardware around, and qemu's gdb support provides development capabilities that previously would have meant shelling out thousands for an Abatron; embedded space is a good place for a budding hobbyist to be, and also provides ample opportunities to use less-mainline operating systems (after all, unless your hardware is network-attached, the set of external interactions is finite and straightforward to test; also, advantages of microkernel operating systems -- being able to restart subsystems whose failures would be kernel panics in a monolithic kernel -- can be argued as a substantial advantage in end-to-end system robustness).
So -- microkernels good, HURD meh.
A conventional bicycle, yes. A folding bicycle, no.
Speaking as a year-round cycle commuter in Texas, I believe my contrary experience a bit more authoritative.
Its range has to be good enough for the "last mile" from the train station to your destination. If a conventional bicycle isn't adequate for the distance being covered, an electric bicycle will get 15-30mph; that's entirely comparable to in-town rush hour traffic speeds for motorized vehicles.
Can't say I've experienced that; seems rather on the made-up side, as problems go.
(Please pardon the snark; it's late and I'm tired).
Try living in a major city. They tend to have this thing called "light rail" or "commuter rail", or "subways" -- a system of trains intended for use by (guess who) commuters! They don't run door-to-door, granted, but they do connect to the bus systems and welcome folding bicycles (and be at least moderately welcoming to conventional non-folding bicycles), both of which are better suited to addressing to the last-mile problem. (The light rail system in the South Bay area is great, by the way -- I used that to get to work in Sunnyvale from Mountain View and San Jose while working in that area around the tail end of the tech boom. I don't claim that every major US city has a competent commuter rail system -- but certainly many of the larger ones do, particularly when subways are taken into account).
Granted, these systems don't exist everywhere -- but arguably, that's a reason to put them in where they aren't. A good transit system is subsidized around the same level as highways tend to be in the US (while it used to be more, highways are not much over 50% funded by user fees anymore), can get ~40% usage for trips in which it is competitive, and thus does a great deal of use in terms of reducing traffic congestion and enabling higher population densities for the same road infrastructure.
Eh? Pretty lousy mass transit system where train+walk (or better, train+bike) is worse than walking alone (for a long enough trip to justify the system's use). Sure, a train isn't door-to-door... but if the system is effective, then what you have is the last mile problem, as opposed to what might be a 15 mile trip.
A folding bike is a great solution to the last-mile problem; it fits on a bus or train easily (even if the racks for conventional bikes are full), or in airline-standard luggage -- and you can fold it up and take it inside when you reach where you're going.
You want to carry around at least 1000 pounds of metal for each set of passengers, plus all the extra mass involved in adding the space in the trains themselves (to be able to house the cars)? The number of passengers to a train (for a given level of purchase and operational costs) just went down substantially.
I'm a big fan of folding bicycles -- waiting anxiously for a custom Bike Friday Tikit to be delivered. The Tikit folds for getting on or off of transit in <5 seconds, or can be packed into an airline-standard suitcase, with enough room to also hold a disassembled trailer in that suitcase -- a trailer capable of pulling the suitcase itself behind the bike! This makes it possible to travel by air and not need to rent a car on arrival -- your vehicle is there in your luggage, and capable of *pulling* the rest of your luggage (in the now-empty suitcase) as well. For those that need to travel further on either end than can be done without sweating in one's business attire (and for whom sweating is not an option -- I personally prefer to get my exercise done on my commute and shower on arrival at the office), several 3rd-party electric-assist conversion options are available, and one officially supported e-Tikit is in the works.
Yes, for a folding bike cargo capacity is a concern relative to a passenger car -- but so is space on trains. (The Tikit can be equipped to mount 4-5 luggage bags, but only one while folded). Outside of folding bikes, there are numerous cargo-carrying options available; it's quite possible to mount an Xtracycle on a standard bus/train rack (with a little preparation), and those can carry an astonishing amount of cargo.
I don't argue that use of cars is evil. I do take the position that pairing cars with trains is impractical. A folding bicycle, electric or otherwise, is a far more practical vehicle for that kind of use; it's hand-carryable, requires no more luggage space than a suitcase or folding stroller, can be taken inside at your destination (rather than need to lock it up, as is the case for a full-size bicycle), and requires no redesign of existing infrastructure.
Transactional memory; lockless concurrency.
Haven't known any of those for a decade at least.
No -- of the people I referred to as "cutting-edge" here, every last one is at least mid-career.
Dunno -- the cutting-edge people I know are digging on Clojure pretty hard.
Yes, Java-the-language sucks hard. Yes, it took them waaay too long to get better bytecode-level support for languages that don't conform to their typing model (see JSR 292). Even with these things being true, there are some cutting-edge languages that target the Java platform, so I'm not about to call it dead to me yet.
(Other cutting-edge people I interact with are targeting things like OCaml -- but I'm maybe a little too pragmatic to go there just yet myself).
Also, it presently needs a dev version of chrome started with a command line parameter that disables some sandboxing features.
Not (fully) true; it's only for children that coverage can't be denied for pre-existing conditions.
Speaking of US-made shoes...
I wear SAS (San Antonio Shoes, made here in Texas). Their style is undoubtedly old-school (I'd guesstimate that 1/3 of the fellow customers I see in there are near- or post-retirement-age, though they're trying to remedy that somewhat with new products), but they're extremely comfy and the sales staff (they have outlets here in Austin) knows their stuff.