Technically, it's a combination of hardware IDs on your computer. ID of the install HD, ID of the CPU, ID of the motherboard chips, ID of the video card, ID of the NIC... The strictness of the check depends on the type of license, but replacing things one at a time is generally safe. If you have an OEM license, you generally have to replace things with very similar parts; e.g. if your MB dies, you need to replace it with the same style MB.
You really think the MS security techs (or their registry system) is that lame? MS would almost certainly store the public IP which originated the registration request. It's not magic - it's part of the network connection.
If someone stole a manuscript from Disney and got away in a blue Ford with a license plate of XXX-123 and then pirated the manuscript, it certainly would be within the court's power to allow Disney to subpoena the owner of that particular Ford to ask who was in control of the car at the moment of the theft. It might have been the owner's son, or neighbor, or it might have been stolen. But it's a legitimate request to ask the question.
Ding! We have a winner several zillion posts down the page and buried.
If a software/firmware update can disable the key wipe, then the FBI should be able to bypass it through direct hardware access and copying. The new phones do this all within a secured chip, making it much harder, but the 5c doesn't have that extra hardware protection.
To prove that anarchist pajamas-in-Mom's-basement types can be more antisocial than Scrooge and the Grinch, perhaps. Otherwise, I can't even begin to guess at what bright flame of sub-genius decided this would be a good idea.
If the photograph was originally taken in a private location, then the person retains more rights to their likeness than they would if it were taken in a public place. In a public place, the person can only restrict sale of an image for commercial (i.e. advertising and advocacy) purposes. In a private place, however, a person must generally give consent to publish regardless of the purpose of publication. Again - in the US.
In the US, there is essentially no right to personality except in defamation suits. Copyright law would govern, and since there's a person's likeness involved and no formal consent form signed, a lawsuit *could* prevent the photographer from publishing or selling the photos, subject to normal copyright fines. Since some of the images have been found on the Internet, she could also go after him in a private civil lawsuit. But AFAIK there's nothing in US law that says that one person has a right to destroy another person's possessions just because their relationship has ended.
Now if only Adobe would figure this out, I'd pay them for a CC subscription. As it is, I refuse to trust my business to Adobe's online model - I want a piece of software that works after I stop paying, not hundreds of useless files that are the life of my business.
Current rights holder to Superman, but not to the Fleischer cartoons. If a work falls to the public domain, some company can't just come in and suck of the rights to the work - it remains in the PD.
We effectively do without a scrum master. It can be done with an open and communicative team, so long as everyone recognizes the rules of the game and is willing to speak up to guide the process. Product owner buy-in is essential (and a scrum master IMHO an essential backup if the PM is fighting the system); they don't make the system work, but without good backlog management they can make the system break.
Our team succeeds at Agile more than anything else because our developers are respected by management. Our product owners and management have both wanted longer term planning and a more waterfall process because it's easier for them, but we have the ability to push back, and they have the respect to listen.
Management push-back is a tough one and understandable. They want to know where the company is going in a quarter, two quarters, next year. That means big plans, and it means estimating the size of things way in advance. That's something that Agile is specifically designed to avoid - unnecessary advance planning. I think this conflict exists (or should exist) even in the best Agile development shops. The alternative is the ultimate in management short-sightedness - no plan for the future, just get through the quarter. On our team the compromise is doing some one quarter rough-grooming and having our engineering team manager (who was a team member before being promoted) flesh out the more distant epic level grooming with our PM.
Like so many other things, it's very difficult to take an ideal theory and put it into practice in the real world. If your team really understands the ideas behind Agile and you have a good process in place to make it happen, you can have a great deal of success.
Unfortunately, like so many other things in life, most teams don't get it right and they end up failing to some degree or another.
Cannot be restated often enough.
I've worked in a shop that started doing "Agile" development after years of more waterfallish practices. This essentially meant that we started to get customer requests organized in an Agile toolset and then had a sprint planning meeting to negotiate the value of the various requests so that we could start work on them. Standups often took a half an hour for 6 people, including the PM, who unfortunately doubled as the scrum master. It wasn't terribly agile, and it didn't buy us much other than better tracking of issues.
And I work now at a medium sized company that does everything with some variation on Agile methodology (with some Kanban thrown in). We use Agile as the base framework for our development, but we adopt other practices that make sense, and we've agreed as developers (with the PM) on how it works best for us. Standup was 15 minutes this morning for a (largish) team of 9 developers - and that included some non-standup topics that snuck in. Retrospective for a two-week iteration is an hour to 1.5 hours. Planning is also about that long, including tasking - but we have one or more one hour grooming sessions during the iteration to keep our work backlog properly sized and ready to go. We code review each other's work, we communicate openly, and we know what's going on and how our work fits in with the overall product line because of that. It just works, and from a psychological standpoint it's good for morale to see the progress being made.
The difference is in committing to the actual goal of Agile - producing working code in manageable bits while minimizing unnecessary overhead. It's easy to go off the rails by misunderstanding Agile or half-assing it - you just have to get it right.
I've found that pretty much anything can be broken down into Agile stories if you do the planning and grooming well, though the definition of "potentially shippable product" might have to slip - or you might have to add in a number of non-shippable "spike" stories in order to get to something useful.
It's a tool, not a religion. Or at least it shouldn't be a religion.
If by saying QA/QC isn't completed you mean that unit and functional testing is missing, then the developer is not done. If you have problems with the developer not writing these tests, then be sure that "Definition of Done" includes some acceptable target level of unit/functional testing.
If on the other hand you get to the end of a story and accept it only to find out that it doesn't meet your QA standards, then you as a product manager haven't done your job in properly validating the story prior to acceptance; add to your own procedures the time required to properly validate the story for acceptance. Maybe you need a testing resource to do this if you are overworked as a product manager - an assistant product manager, even.
On the conversion side... If you're taking in PDFs created by a layout/page design program, then you're not likely to get good satisfaction converting them and storing them as something other than PDFs. OTOH, if you're taking in a lot of documents created in an office suite, and they have collaborative notes, and you need to retain the documents for legal purposes, then converting them to PDF is going to lose data.
On the future use side: PDFs are slower to render and search than most formats; they're harder to alter, but they're more reliably rendered than any other format. Office documents offer richer content and easy editing; their layout may vary depending on the output device (good and bad), and office document formats seem to change a bit more than other document types. HTML with CSS is good, and probably now stable enough that future clients will render something similar - but it's not PDF for reliable formatting, nor office docs for feature richness; editing tools for HTML aren't all that intent on preserving what came before. LaTeX is a reliable formatter wrapped around text-centric documents, but it's not something most people will be able to use and edit.
Each document type has its reasons for being - you'll need to decide why you need to store your documents and what you need them for in the future. Retaining the original document along with a text conversion stored and indexed in a search engine may be your best bet - or not.
DKIM validates off of the 'd=' in the DKIM signature. If the mailing list software alters the message (by adding an unsubscribe notice or other list decoration, e.g.), then the original DKIM signature is invalid regardless of any header address.
SPF validates the sending IP to the SMTP mFROM claim. Most list software changes the mFROM to a list bounce address, and therefore SPF at least passes.
DMARC does a couple of things to validate messages... First, it compares DKIM and SPF domains to the header From domain - if they "align", then it checks to see if each passes. If either DKIM or SPF passes and is aligned, then DMARC rules aren't triggered.
So, for list software to work with DMARC, they either have to keep the original message content (and some headers) - i.e. act as a (reasonably) strict forwarding system - or they have to claim ownership of the email message and resign it.
Going down the route of From vs. Sender (i.e. purported responsible address) is a rehash of the attempted Microsoft SenderID "improvement" on SPF.
Emails that wind up in "Promotions" are verified valid marketing material. I.e. it passes DKIM and SPF, comes from a known good behavior IP, isn't spammy...
For now, at least, Google seems to be (mostly) playing along with the marketing folks while still trying to (a) enhance their user experience and (b) give themselves a leg up. The image pre-load is definitely going to alter things like newsletter and ad read rates that marketers depend on to tell how well they're targeting their subscribers; I imagine the marketers will work their way around it in short order if they feel they're losing too much information.
Um, no. There is no other corporate or government entity in this country that is required to meet the standards applied to the USPS under that law, and the 75 years is indeed a hard funding benefit - they've got a $5b/year over 10 years requirement.
I believe if you look at the accounting, absent the pre-payment plan the USPS actually made money last year.
I agree that Nintendo's suit based on copyright is counterproductive - that, in fact, anything that's been on the market for 30 years has outlived any need for protection under Copyright law. Limit it to the same duration enforced for patents - 14 + 14 - and I think we come closer to the intent of the founding fathers (who probably would argue that even 7 years was an incredible head start...).
But Nintendo could still have shut this project down through trademark protection. Indeed, they are obligated under trademark law to shut the site down or at least force a formal licensing agreement out of the author (and a corresponding change in the open source license terms...). SMB and its characters remain prominent symbols not only of the Mario franchise but also Nintendo as a company - there's no way they could let this go.
Slashdot Mirror
Some people don't know exactly what the complaint was about, either. Specifically, most of /. users I'm reading here.
Technically, it's a combination of hardware IDs on your computer. ID of the install HD, ID of the CPU, ID of the motherboard chips, ID of the video card, ID of the NIC... The strictness of the check depends on the type of license, but replacing things one at a time is generally safe. If you have an OEM license, you generally have to replace things with very similar parts; e.g. if your MB dies, you need to replace it with the same style MB.
You really think the MS security techs (or their registry system) is that lame? MS would almost certainly store the public IP which originated the registration request. It's not magic - it's part of the network connection.
If someone stole a manuscript from Disney and got away in a blue Ford with a license plate of XXX-123 and then pirated the manuscript, it certainly would be within the court's power to allow Disney to subpoena the owner of that particular Ford to ask who was in control of the car at the moment of the theft. It might have been the owner's son, or neighbor, or it might have been stolen. But it's a legitimate request to ask the question.
Ding! We have a winner several zillion posts down the page and buried.
If a software/firmware update can disable the key wipe, then the FBI should be able to bypass it through direct hardware access and copying. The new phones do this all within a secured chip, making it much harder, but the 5c doesn't have that extra hardware protection.
To prove that anarchist pajamas-in-Mom's-basement types can be more antisocial than Scrooge and the Grinch, perhaps. Otherwise, I can't even begin to guess at what bright flame of sub-genius decided this would be a good idea.
If the photograph was originally taken in a private location, then the person retains more rights to their likeness than they would if it were taken in a public place. In a public place, the person can only restrict sale of an image for commercial (i.e. advertising and advocacy) purposes. In a private place, however, a person must generally give consent to publish regardless of the purpose of publication. Again - in the US.
Wouldn't this be settled as part of a divorce decree in the US?
Or did the problem arise after the divorce, when pictures started appearing on the Web?
In the US, there is essentially no right to personality except in defamation suits. Copyright law would govern, and since there's a person's likeness involved and no formal consent form signed, a lawsuit *could* prevent the photographer from publishing or selling the photos, subject to normal copyright fines. Since some of the images have been found on the Internet, she could also go after him in a private civil lawsuit. But AFAIK there's nothing in US law that says that one person has a right to destroy another person's possessions just because their relationship has ended.
I have a Dell Latitude E7240 that works fine with Ubuntu 14.04 LTS - use it for work, even.
Now if only Adobe would figure this out, I'd pay them for a CC subscription. As it is, I refuse to trust my business to Adobe's online model - I want a piece of software that works after I stop paying, not hundreds of useless files that are the life of my business.
This. I get Netflix so I can "rent" movies. While I've liked some of the Netflix original content, what I really want is a super video rental store.
Current rights holder to Superman, but not to the Fleischer cartoons. If a work falls to the public domain, some company can't just come in and suck of the rights to the work - it remains in the PD.
We effectively do without a scrum master. It can be done with an open and communicative team, so long as everyone recognizes the rules of the game and is willing to speak up to guide the process. Product owner buy-in is essential (and a scrum master IMHO an essential backup if the PM is fighting the system); they don't make the system work, but without good backlog management they can make the system break.
Our team succeeds at Agile more than anything else because our developers are respected by management. Our product owners and management have both wanted longer term planning and a more waterfall process because it's easier for them, but we have the ability to push back, and they have the respect to listen.
Management push-back is a tough one and understandable. They want to know where the company is going in a quarter, two quarters, next year. That means big plans, and it means estimating the size of things way in advance. That's something that Agile is specifically designed to avoid - unnecessary advance planning. I think this conflict exists (or should exist) even in the best Agile development shops. The alternative is the ultimate in management short-sightedness - no plan for the future, just get through the quarter. On our team the compromise is doing some one quarter rough-grooming and having our engineering team manager (who was a team member before being promoted) flesh out the more distant epic level grooming with our PM.
Like so many other things, it's very difficult to take an ideal theory and put it into practice in the real world. If your team really understands the ideas behind Agile and you have a good process in place to make it happen, you can have a great deal of success.
Unfortunately, like so many other things in life, most teams don't get it right and they end up failing to some degree or another.
Cannot be restated often enough.
I've worked in a shop that started doing "Agile" development after years of more waterfallish practices. This essentially meant that we started to get customer requests organized in an Agile toolset and then had a sprint planning meeting to negotiate the value of the various requests so that we could start work on them. Standups often took a half an hour for 6 people, including the PM, who unfortunately doubled as the scrum master. It wasn't terribly agile, and it didn't buy us much other than better tracking of issues.
And I work now at a medium sized company that does everything with some variation on Agile methodology (with some Kanban thrown in). We use Agile as the base framework for our development, but we adopt other practices that make sense, and we've agreed as developers (with the PM) on how it works best for us. Standup was 15 minutes this morning for a (largish) team of 9 developers - and that included some non-standup topics that snuck in. Retrospective for a two-week iteration is an hour to 1.5 hours. Planning is also about that long, including tasking - but we have one or more one hour grooming sessions during the iteration to keep our work backlog properly sized and ready to go. We code review each other's work, we communicate openly, and we know what's going on and how our work fits in with the overall product line because of that. It just works, and from a psychological standpoint it's good for morale to see the progress being made.
The difference is in committing to the actual goal of Agile - producing working code in manageable bits while minimizing unnecessary overhead. It's easy to go off the rails by misunderstanding Agile or half-assing it - you just have to get it right.
I've found that pretty much anything can be broken down into Agile stories if you do the planning and grooming well, though the definition of "potentially shippable product" might have to slip - or you might have to add in a number of non-shippable "spike" stories in order to get to something useful.
It's a tool, not a religion. Or at least it shouldn't be a religion.
DING!
If by saying QA/QC isn't completed you mean that unit and functional testing is missing, then the developer is not done. If you have problems with the developer not writing these tests, then be sure that "Definition of Done" includes some acceptable target level of unit/functional testing.
If on the other hand you get to the end of a story and accept it only to find out that it doesn't meet your QA standards, then you as a product manager haven't done your job in properly validating the story prior to acceptance; add to your own procedures the time required to properly validate the story for acceptance. Maybe you need a testing resource to do this if you are overworked as a product manager - an assistant product manager, even.
Agile is as good as you make it.
On the conversion side... If you're taking in PDFs created by a layout/page design program, then you're not likely to get good satisfaction converting them and storing them as something other than PDFs. OTOH, if you're taking in a lot of documents created in an office suite, and they have collaborative notes, and you need to retain the documents for legal purposes, then converting them to PDF is going to lose data.
On the future use side: PDFs are slower to render and search than most formats; they're harder to alter, but they're more reliably rendered than any other format. Office documents offer richer content and easy editing; their layout may vary depending on the output device (good and bad), and office document formats seem to change a bit more than other document types. HTML with CSS is good, and probably now stable enough that future clients will render something similar - but it's not PDF for reliable formatting, nor office docs for feature richness; editing tools for HTML aren't all that intent on preserving what came before. LaTeX is a reliable formatter wrapped around text-centric documents, but it's not something most people will be able to use and edit.
Each document type has its reasons for being - you'll need to decide why you need to store your documents and what you need them for in the future. Retaining the original document along with a text conversion stored and indexed in a search engine may be your best bet - or not.
No. Exactly the opposite. The definition the USFS defines for Still Photography does not include landscape photographers.
Great tool for HTML conversion. Doesn't meet the OP's criteria, but it's the best open source HTML to PDF converter I've found.
DKIM validates off of the 'd=' in the DKIM signature. If the mailing list software alters the message (by adding an unsubscribe notice or other list decoration, e.g.), then the original DKIM signature is invalid regardless of any header address.
SPF validates the sending IP to the SMTP mFROM claim. Most list software changes the mFROM to a list bounce address, and therefore SPF at least passes.
DMARC does a couple of things to validate messages... First, it compares DKIM and SPF domains to the header From domain - if they "align", then it checks to see if each passes. If either DKIM or SPF passes and is aligned, then DMARC rules aren't triggered.
So, for list software to work with DMARC, they either have to keep the original message content (and some headers) - i.e. act as a (reasonably) strict forwarding system - or they have to claim ownership of the email message and resign it.
Going down the route of From vs. Sender (i.e. purported responsible address) is a rehash of the attempted Microsoft SenderID "improvement" on SPF.
Emails that wind up in "Promotions" are verified valid marketing material. I.e. it passes DKIM and SPF, comes from a known good behavior IP, isn't spammy...
For now, at least, Google seems to be (mostly) playing along with the marketing folks while still trying to (a) enhance their user experience and (b) give themselves a leg up. The image pre-load is definitely going to alter things like newsletter and ad read rates that marketers depend on to tell how well they're targeting their subscribers; I imagine the marketers will work their way around it in short order if they feel they're losing too much information.
Um, no. There is no other corporate or government entity in this country that is required to meet the standards applied to the USPS under that law, and the 75 years is indeed a hard funding benefit - they've got a $5b/year over 10 years requirement.
I believe if you look at the accounting, absent the pre-payment plan the USPS actually made money last year.
I agree that Nintendo's suit based on copyright is counterproductive - that, in fact, anything that's been on the market for 30 years has outlived any need for protection under Copyright law. Limit it to the same duration enforced for patents - 14 + 14 - and I think we come closer to the intent of the founding fathers (who probably would argue that even 7 years was an incredible head start...).
But Nintendo could still have shut this project down through trademark protection. Indeed, they are obligated under trademark law to shut the site down or at least force a formal licensing agreement out of the author (and a corresponding change in the open source license terms...). SMB and its characters remain prominent symbols not only of the Mario franchise but also Nintendo as a company - there's no way they could let this go.