Per subject -- we were given a ticket to admit two to an advance screening last weekend. I didn't go because I had work to do; turns out it was for the better.
The Wife (very much a geek -- she planned our first Valentine's Day to see Lord Of The Rings, and I'm right now wearing her Say No To Dubs shirt from a long-ago anime con) said it was awful -- "I might have enjoyed if I'd been a 7-year-old boy", IIRC...so yar, bad reviews aren't surprising me one bit.
Part of the point of having persistent identity (even persistent pseudonymous identity) is assigning trust values -- if I hadn't seen you around in the past and decided that you seemed to be a reasonable person, you almost certainly wouldn't have been able to insult me (and I most likely wouldn't be responding to you now).
Likewise, I'd hope that you'd have seen me around over the years we've been mutually frequenting this site enough to believe that I don't assert things simply because they're "easy to say".
The article specifies that the chemicals found did not, in fact, pose any abnormal hazard; why would you expect that reading TFA would lead one to believe that confiscating them was justified?
No, it was not license management code, it was a product time-limitation (such as used to expire Beta products) that was accidently left on during a release-build.
Controlling whether users are is permitted to use software past a certain date (whether on account of payment/nonpayment status or due to a wish to force beta users to upgrade) is certainly license management -- look up the word "license" in any dictionary.
From 10km up, some people come up with a goal, a number of salaried grunts work on it using the known best practices of their trade, the results are tested and reworked, and then (maybe) the product is brought to market, in hopes that the massive investment in development can be paid off by selling large volumes with a high gross profit to potentially underinformed buyers. The main difference is that "small pharma" is bigger than a lot of software concerns, not least because experimenting with drugs in your garage is frowned upon by the Religious Reich.
Let's go from 10km up to only, say, 5km or so. The difference here is that in the case of pharma, you have a massive number of salaried grunts producing a work for which a single patent (or otherwise a very small number of patents) applies; the value of the individual patent (and the cost associated with developing the associated process) is tremendous.
In software, you have a massive number of salaried grunts, each of whom in their day-to-day work creates subcomponents which may be patentable over the course of implementing the larger product on which they work. Most of the patents require relatively little development to create, but an injunction against using a patentable process can have a huge negative financial impact. The value of the individual patents is much lower, but the potential for an injunction to stop the product from being releasable is much higher.
That the impact of patents on these fields are different is highly visible in practice: If you look at where the patent trolls are, they aren't using pharmaceutical patents to extort undeserved gains; it's almost exclusively software and business method patents misused in this way. Moreover, economic studies looking to find evidence of the benefits of software patents have failed to do so -- the page I just linked to is a highly opinionated source (as am I myself), but the links in its bibliography are to respectable, peer-reviewed papers, and should merit review if you're interested in this subject.
Drugs are a special case; much of why the patent system is such a mess is that the same rules are applied to drugs and software, while the economics behind the two fields are so different.
Getting back to making an effort at explaining the parent's (grandparent's?) comments -- without indicating any agreement with the same:
Sure, the GPL depends on copyright... so what? Folks can't make derivative works combining GPLed works with proprietary software (or software under permissive but incompatible licenses, which there are a lot of) -- and such proposed derivative works really are "software not written". (What do I mean by "proprietary" in a proposed world without copyright? Source code is a trade secret, object code is obscured). There've been plenty of fan-based projects trying to resurrect classic games by writing modern engines for them shut down because the original copyright holder -- while not selling the original game -- refuses to allow creation of the involved derivative work... and there are plenty of cases where Free Software avoids implementing functionality which is known to be patented; look at how the development of Tux3 was held up.
The argument that there are works not created due to restrictions via intellectual property laws is quite sound. That said, I tend to give credence to the position that intellectual property protection is necessary for much (not all) commercial development to take place as well... but that level of protection doesn't need to be anything like what it is today. Personally, I'd like to see copyright durations rolled back to their original values, and patents only available in fields where they make sense (not business models, not software)... but the latter seems unlikely, and the former flat-out impossible.
First "real" tech job I interviewed for had a job description focused around porting and packaging software -- two things I'd already been doing for fun (building RPMs for whatever the current Red Hat was at the time, and porting software to my university's Solaris and IRIX boxes); the CTO (well, it was less than a 20-person shop at the time) was floored by my level of relevant experience.
I landed the interview in the first place through some folks I met helping out at the university LUG. So yes -- of course -- open source experience helps. That employer was an embedded Linux shop, and learning from some of the other folks they had on staff (a bunch of kernel developers, including two of Linus's lieutenants, a gdb maintainer, and a bunch of other really bright folks) is what I credit for getting my career off in the right direction; every job I've held since then has included some level of interaction with the open source community, and I've had a great deal of fun.
The article increases awareness of a security vulnerability.
Awareness means people can reprioritize how important it is to fix something: ie. if phishers handle private data so carelessly that it can be stolen by more parties than just that initially gathering it (and the party they sell it to), that provides a justification for even more vigilance than would otherwise be used, and a talking point to use when telling people how important it is to be cautious about potential phishing sites.
There's no reason to believe the laptop was there at all within the nine-day period, rather than off having its drives imaged so the data could be sold.
Heh; I consider myself a systems-type guy, and most of what I do is debugging or extending other peoples' code in C, writing my own tools in Python or shell, and helping more specialized folks (Java developers, pure sysadmins) debug cross-functional problems.
Counterargument: Less readable code, as it's split into two places.
2. easier to maintain - change in the database and the change happens realtime, no need to a new release (if your doing binaries)
Counterargument: Harder to maintain - more upgrades will require the database to be revved as opposed to only the application, and synchronization between the two becomes more of an issue.
(Granted, IRL there needs to be robust infrastructure for database upgrades and downgrades no matter what -- but making previously code-only minor patches impact both components doesn't necessarily make things easier).
3. better access control in many situations. sometimes you want to get at data but don't want the users to have that kind of access. you can run a function as a higher level user but allow lower level users select access to the function.
Yup; that is indeed a good reason to use stored procedures or views.
4. faster/more accurate. in general, your DBA will write a better/faster query than your programmers.
Of course the DBA will write better queries; that's why I advocate making DBA review mandatory for code changes impacting the data access layer. In shops with a good DBA, the programmers will come to the DBA first when they have a complex query to write anyhow; that's what happens where I'm at presently. (Our DBA is a rockstar, incidentally poached from my last employer, and very well-respected; at that last job, however, we had a CEO's-college-buddy incompetent before we had the rockstar, and I'd have hated to see him hold the power your workflow would grant).
5. One less thing for your programmers to worry about. it means they can focus on writing the application (which is their job remember).
From the perspective of the programmers writing the data access layer (you're doing a proper tiered application with business logic and data access broken off from each other, right?), they need to worry about interfacing with the DB no matter what; your proposal reduces their scope considerably (by making the code they maintain effectively into a collection of nearly-opaque stubs referencing logic stored elsewhere), but certainly doesn't eliminate the relevant work from development's domain.
I'm largely playing Devil's Advocate here: What you're advocating is a good workflow, but I think that calling it the only good workflow is a serious misrepresentation -- the problems it addresses can be resolved through other means, and at least some of the benefits are two-sided.
You can tout that as "the right way", but there's still no reason this has to be a technical-design issue rather than a process-design issue -- and while my background is as an OSS groupie, I've been the OSS groupie at enough proprietary shops (ie. the party responsible for dealing with upstream on projects used as underlying infrastructure for actually running the proprietary software we built) that I can say with a fair bit of confidence that the approach you're espousing just isn't all that popular in The Real World.
Isolate your queries into a specific set of packages and require DBA review before changes to those packages can be promoted to the production branch; there are plenty of ways to keep developers from messing up production by writing bad queries less heavy-handed than the strict access-control approach given, and you should have a revision control infrastructure enforcing code review anyhow.
Only because of the callous, judgmental, ignorant people who populate it. The only person anone can ever hope to change is one's self. If I'm callous or judgemental (and we all are at times) I hope someone calls me on it. If I'm ignorant I hope someone educates me.
Fair enough. For my part, I'll try to control myself a little better next time I have an attack of Libertarianism.
How about when "some jackass" like me CAN afford a house, but his wife and her job leaves him and his teenaged daughters for another man, and he is left raising and supporting those daughters without her income or help, and loses the house that he no longer can afford on his single salary?
(1) Buying a house in your name without being able to pay for it with only the income that's in your name is a pretty damned bad idea.
(2) If your ex-wife has the income and you have the kids, shouldn't you be getting child support?
Or some "jackass" not like me gets his job outsourced? Or gets crippled and can't do that job any more?
And didn't have the foresight to (1) keep on top of the job market w/ current contacts or (2) pay for long-term disability insurance? Also your own damned fault.
I didn't have long-term disability insurance until recently. I also bought a dirt-cheap house and avoided having kids (which was a tough sell to the wife) because we couldn't afford them (for a value of "afford" that makes the always-safe assumption that there are hard times ahead). Some of us are responsible for our own actions; what good is that personal responsibility if one can't collect the false impression of moral superiority and +3 bonus to smugness and know-it-all?
You might try being a little less judgemental there, sparky. BTW calling someone "jackass" just might get you modded "flamebait". Try to be a bit more civil; I was insulted by your callous, judgemental, ignorant comment.
No 64-bit support in released versions. No libvirt driver (yes, there's a fancy C++ API; libvirt is simpler and easier and has bindings for everything).
It's fantastic for running a Windows desktop VM -- particularly with the seamless-mode support -- but has no place anywhere near my QA lab.
I think it's pretty obvious that this is about piracy and not killing homebrew or modding. How are game developers supposed to make money if all their games can be dumped onto a cartridge for free, easily.
Right. It's unfortunate that it's necessary, though -- if they got their protection right (as they did for the Wii, excepting Virtual Console titles), these devices would be useful only for homebrew.
That said, contrary to the conclusion you implied (to the question you beggered), publishers certainly do make money off the DS, despite the very longstanding availability of hardware to circumvent its protection mechanisms.
VMW and VB can use the same vHDs, so unless you're talking about the snotty little text file that you can manipulate in nano faster than through the interface, that's just rather gauche to say that they don't use the same containers
The native formats were all I was aware of; my bad. (I'm mostly working with libvirt+kvm right now, with vbox for my desktop, and vbox's lack of support for raw disk images in favor of its VDIs is something I found thoroughly annoying).
As for the switching virtualization back ends, that's the whole point to VMWare's VI, duh. If they were to find a way to let you use someone else's backend and still make $10k/pop, sure, why not, but currently it's their backend that makes them money.
Portability between members of a single vendor's product line are assumed; if they didn't do that their offering would be broken. (Centralized control is of course more interesting than just portability... but an initiative like libvirt promising to allow multiple frontend vendors to offer products that can control any compliant backend has the potential to trump any single-vendor solution, particularly once the VMware driver is out).
Slashdot Mirror
Not if they're in bankruptcy.
I'd forgotten about that -- but yup, it surely will do the trick.
Per subject -- we were given a ticket to admit two to an advance screening last weekend. I didn't go because I had work to do; turns out it was for the better.
The Wife (very much a geek -- she planned our first Valentine's Day to see Lord Of The Rings, and I'm right now wearing her Say No To Dubs shirt from a long-ago anime con) said it was awful -- "I might have enjoyed if I'd been a 7-year-old boy", IIRC ...so yar, bad reviews aren't surprising me one bit.
Part of the point of having persistent identity (even persistent pseudonymous identity) is assigning trust values -- if I hadn't seen you around in the past and decided that you seemed to be a reasonable person, you almost certainly wouldn't have been able to insult me (and I most likely wouldn't be responding to you now).
Likewise, I'd hope that you'd have seen me around over the years we've been mutually frequenting this site enough to believe that I don't assert things simply because they're "easy to say".
The article specifies that the chemicals found did not, in fact, pose any abnormal hazard; why would you expect that reading TFA would lead one to believe that confiscating them was justified?
Three things:
That latter bit is actually somewhat of a surprise; generally speaking, it Just Doesn't Happen on slashdot.
Controlling whether users are is permitted to use software past a certain date (whether on account of payment/nonpayment status or due to a wish to force beta users to upgrade) is certainly license management -- look up the word "license" in any dictionary.
Hullo? Separate it out into hydrogen and oxygen.
Yes, but the fact that licenses expire explains why the code checks dates, which is what the parent was doubting.
If you read the article, you'd know it's the license-management code. Licenses expire.
Let's go from 10km up to only, say, 5km or so. The difference here is that in the case of pharma, you have a massive number of salaried grunts producing a work for which a single patent (or otherwise a very small number of patents) applies; the value of the individual patent (and the cost associated with developing the associated process) is tremendous.
In software, you have a massive number of salaried grunts, each of whom in their day-to-day work creates subcomponents which may be patentable over the course of implementing the larger product on which they work. Most of the patents require relatively little development to create, but an injunction against using a patentable process can have a huge negative financial impact. The value of the individual patents is much lower, but the potential for an injunction to stop the product from being releasable is much higher.
That the impact of patents on these fields are different is highly visible in practice: If you look at where the patent trolls are, they aren't using pharmaceutical patents to extort undeserved gains; it's almost exclusively software and business method patents misused in this way. Moreover, economic studies looking to find evidence of the benefits of software patents have failed to do so -- the page I just linked to is a highly opinionated source (as am I myself), but the links in its bibliography are to respectable, peer-reviewed papers, and should merit review if you're interested in this subject.
Drugs are a special case; much of why the patent system is such a mess is that the same rules are applied to drugs and software, while the economics behind the two fields are so different.
Getting back to making an effort at explaining the parent's (grandparent's?) comments -- without indicating any agreement with the same:
Sure, the GPL depends on copyright... so what? Folks can't make derivative works combining GPLed works with proprietary software (or software under permissive but incompatible licenses, which there are a lot of) -- and such proposed derivative works really are "software not written". (What do I mean by "proprietary" in a proposed world without copyright? Source code is a trade secret, object code is obscured). There've been plenty of fan-based projects trying to resurrect classic games by writing modern engines for them shut down because the original copyright holder -- while not selling the original game -- refuses to allow creation of the involved derivative work... and there are plenty of cases where Free Software avoids implementing functionality which is known to be patented; look at how the development of Tux3 was held up.
The argument that there are works not created due to restrictions via intellectual property laws is quite sound. That said, I tend to give credence to the position that intellectual property protection is necessary for much (not all) commercial development to take place as well... but that level of protection doesn't need to be anything like what it is today. Personally, I'd like to see copyright durations rolled back to their original values, and patents only available in fields where they make sense (not business models, not software)... but the latter seems unlikely, and the former flat-out impossible.
First "real" tech job I interviewed for had a job description focused around porting and packaging software -- two things I'd already been doing for fun (building RPMs for whatever the current Red Hat was at the time, and porting software to my university's Solaris and IRIX boxes); the CTO (well, it was less than a 20-person shop at the time) was floored by my level of relevant experience.
I landed the interview in the first place through some folks I met helping out at the university LUG. So yes -- of course -- open source experience helps. That employer was an embedded Linux shop, and learning from some of the other folks they had on staff (a bunch of kernel developers, including two of Linus's lieutenants, a gdb maintainer, and a bunch of other really bright folks) is what I credit for getting my career off in the right direction; every job I've held since then has included some level of interaction with the open source community, and I've had a great deal of fun.
Computer misuse is illegal, yes, but not under the DMCA.
The article increases awareness of a security vulnerability.
Awareness means people can reprioritize how important it is to fix something: ie. if phishers handle private data so carelessly that it can be stolen by more parties than just that initially gathering it (and the party they sell it to), that provides a justification for even more vigilance than would otherwise be used, and a talking point to use when telling people how important it is to be cautious about potential phishing sites.
There's no reason to believe the laptop was there at all within the nine-day period, rather than off having its drives imaged so the data could be sold.
Heh; I consider myself a systems-type guy, and most of what I do is debugging or extending other peoples' code in C, writing my own tools in Python or shell, and helping more specialized folks (Java developers, pure sysadmins) debug cross-functional problems.
Counterargument: Less readable code, as it's split into two places.
Counterargument: Harder to maintain - more upgrades will require the database to be revved as opposed to only the application, and synchronization between the two becomes more of an issue.
(Granted, IRL there needs to be robust infrastructure for database upgrades and downgrades no matter what -- but making previously code-only minor patches impact both components doesn't necessarily make things easier).
Yup; that is indeed a good reason to use stored procedures or views.
Of course the DBA will write better queries; that's why I advocate making DBA review mandatory for code changes impacting the data access layer. In shops with a good DBA, the programmers will come to the DBA first when they have a complex query to write anyhow; that's what happens where I'm at presently. (Our DBA is a rockstar, incidentally poached from my last employer, and very well-respected; at that last job, however, we had a CEO's-college-buddy incompetent before we had the rockstar, and I'd have hated to see him hold the power your workflow would grant).
From the perspective of the programmers writing the data access layer (you're doing a proper tiered application with business logic and data access broken off from each other, right?), they need to worry about interfacing with the DB no matter what; your proposal reduces their scope considerably (by making the code they maintain effectively into a collection of nearly-opaque stubs referencing logic stored elsewhere), but certainly doesn't eliminate the relevant work from development's domain.
I'm largely playing Devil's Advocate here: What you're advocating is a good workflow, but I think that calling it the only good workflow is a serious misrepresentation -- the problems it addresses can be resolved through other means, and at least some of the benefits are two-sided.
You can tout that as "the right way", but there's still no reason this has to be a technical-design issue rather than a process-design issue -- and while my background is as an OSS groupie, I've been the OSS groupie at enough proprietary shops (ie. the party responsible for dealing with upstream on projects used as underlying infrastructure for actually running the proprietary software we built) that I can say with a fair bit of confidence that the approach you're espousing just isn't all that popular in The Real World.
Isolate your queries into a specific set of packages and require DBA review before changes to those packages can be promoted to the production branch; there are plenty of ways to keep developers from messing up production by writing bad queries less heavy-handed than the strict access-control approach given, and you should have a revision control infrastructure enforcing code review anyhow.
Re "lack of a real report developing environment" -- DataVision? Agata Report?
"When in college"? Why not now?
Python jobs aren't hard to find.
Fair enough. For my part, I'll try to control myself a little better next time I have an attack of Libertarianism.
(1) Buying a house in your name without being able to pay for it with only the income that's in your name is a pretty damned bad idea.
(2) If your ex-wife has the income and you have the kids, shouldn't you be getting child support?
And didn't have the foresight to (1) keep on top of the job market w/ current contacts or (2) pay for long-term disability insurance? Also your own damned fault.
I didn't have long-term disability insurance until recently. I also bought a dirt-cheap house and avoided having kids (which was a tough sell to the wife) because we couldn't afford them (for a value of "afford" that makes the always-safe assumption that there are hard times ahead). Some of us are responsible for our own actions; what good is that personal responsibility if one can't collect the false impression of moral superiority and +3 bonus to smugness and know-it-all?
It's a callous, judgmental, ignorant world.
No 64-bit support in released versions. No libvirt driver (yes, there's a fancy C++ API; libvirt is simpler and easier and has bindings for everything).
It's fantastic for running a Windows desktop VM -- particularly with the seamless-mode support -- but has no place anywhere near my QA lab.
Right. It's unfortunate that it's necessary, though -- if they got their protection right (as they did for the Wii, excepting Virtual Console titles), these devices would be useful only for homebrew.
That said, contrary to the conclusion you implied (to the question you beggered), publishers certainly do make money off the DS, despite the very longstanding availability of hardware to circumvent its protection mechanisms.
The native formats were all I was aware of; my bad. (I'm mostly working with libvirt+kvm right now, with vbox for my desktop, and vbox's lack of support for raw disk images in favor of its VDIs is something I found thoroughly annoying).
Portability between members of a single vendor's product line are assumed; if they didn't do that their offering would be broken. (Centralized control is of course more interesting than just portability... but an initiative like libvirt promising to allow multiple frontend vendors to offer products that can control any compliant backend has the potential to trump any single-vendor solution, particularly once the VMware driver is out).