Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:Cloud Based Backup (Score 1) 338

Say this with me folks: CLOUD STORAGE IS NOT RELIABLE NOR IS IT SECURE IN ANY WAY!!!!!

Bullshit.

Good providers are at least as reliable as your local drives. They could fail, but so could your local backups... and when your house burns down, the odds that your backup service provider dies at the same time is miniscule (barring some planet-scale catastrophe, in which case you probably won't care anyway).

As for security, encrypt if you're worried about it. Personally, there's nothing in my backup data that's particularly sensitive, so I don't bother. Most of the backup services automatically encrypt everything anyway.

Comment Re:RAID is not backup (Score 1) 338

The problem with cloud-based solutions is that the cost for backing up several terabytes of data is typically several orders of magnitude higher than building your own RAID array

Nonsense. One order of magnitude more, at most. On-line storage costs are on the order of $100 per TB per year. There's no way you can build and maintain your own solution for $1 per TB per year, which would be two orders of magnitude less. "Several" orders of magnitude would be at least four, putting you in the range of a $0.01 per TB per year. Even $10 per TB per year would be tough to reach, if you want any redundancy, and if you value your time at all -- and while you're amortizing the cost of your up-front hardware investment over several years in order to get close to that level, on-line storage costs will continue dropping, so at the end of those years the savings would be even smaller than they appear now.

Plus, backup storage which is located on-premises is inherently inferior to off-site storage, because a whole range of disasters that take out your primary storage whack your backup, too. Fireproof safes are a partial solution, but not a complete one... and not a cheap one.

No,the best approach is to use a cheap, unreliable, local backup, not bothering with bunkers or safes or even much redundancy, plus use an online service. The local copy is your normal recovery source, the online service is your final fallback.

Personally, I just replicate my data to a couple of local machines (the machines are there anyway, so throwing a little more storage in them doesn't cost much) and keep another copy on Google Drive, which is $120 per TB per year, but I managed to get 1 TB free (in perpetuity) as part of some promotion, and I currently have just under 2 TB of data that I care about (mostly photos), so my net cost is about $60 per TB per year for the online component, plus another $25 per year for an extra 4 TB drive that cost $100 and I expect to get four years out of (will probably go longer, but could die sooner).

Upload time sucks, but only for the initial upload, which I did two years ago. After that, incremental additions are pretty negligible. A full restore from the remote copy would take a long time, but I can easily get individual files on an as-needed basis. Actually, I find I use the remote copy quite frequently to grab particular photos or files on various devices, so it provides some functional value as well as disaster protection.

Comment Re:Patent indemnity (Score 1) 236

How can a license grant a patent indemnity on a patent you do not own?

You obviously can't grant licenses on patents you don't own. As a downstream recipient, you get protection from patents owned by the upstream contributors. It can't do anything to protect you from third party patents.

Also, GPL3 is somewhat nebulous on the question of whether if you write any GPLed software, everybody downstream gets indemnity for all your patents, regardless of whether you interacted w/ them or not.

I think it's quite clear. Everybody downstream gets a license for all of the patents which you use in the licensed work, regardless of whether you interacted with those parties or not. It doesn't affect any other patents you happen to own.

The only real subtlety, I think is, for downstream re-distributors, who have to grant patent licenses for code they didn't write, and those grants effectively flow upstream as well as down. Of course, the license doesn't *force* them to grant those licenses, any more than linking proprietary code to GPL'd code forces you to GPL your proprietary code. It's just that choosing not to license the patents (or GPL the relevant code) means that you have no right to distribute, so any distribution you did constituted copyright infringement. Well... in the case of patents it may also mean that you implied a license which probably means that you can ask users to either pay or stop using, but can't go after them for any past infringement. And, of course, it also means that you lose the right to use and open yourself to infringement suits for your past, present and future use.

Of course, all of that only comes into play if you intend to enforce patents against others. The clear goal of GPLv3 is to discourage software patents, which I wholeheartedly support (even though my name is on a few).

Comment Re:We love you, mr. Torvalds (Score 1) 236

Um yeah a competitor won't use it? bahaha. They rip off Linux code all the time which is why the point of lawyers are brought up.

Actually, given the vast usage of Linux worldwide, it's astonishing how rare such abuses are.

Shoot some companies like banks have ANTI GNU policies to protect themselves.

Some companies are still clueless enough to do that, yes.

Linux can not be used as a simple link to GPL infects the whole program making it viral.

Poppycock. Programs running on Linux do not link to Linux. It's well-accepted that the GPL does not affect programs that merely make syscalls.

I am not a troll here.

Interesting that you feel the need to make that statement.

GNU geeks do not know the difference between GPL and LGPL and assume anyone can use their API. It is not true and it pisses me off.

Also nonsense. Most F/LOSS software developers understand perfectly the distinction between GPL and LGPL, and choose appropriately based on whether they want to allow their code to be linked to non-GPL code. Personally, I've used both licenses for libraries I wrote. Though for programs I tend to choose GPL and for libraries I tend to choose Apache2 or BSD. I think the use case for LGPL is pretty narrow.

Investors agree and so the lawyers that [BSD] is the best option

Only if your lawyers haven't bothered to think about patents. The BSD license has a severe flaw in that it doesn't include a patent grant. If you're incorporating someone else's code into your product and you aren't absolutely certain they don't hold any patents on it, you may be setting yourself up for a patent lawsuit. Apache2 is often a better choice for that reason.

Comment Re:BSDL vs GPL (Score 1) 236

I don't see how the GPL forces you to push your contributions upstream.

"Forces" is too strong, but there's a powerful incentive to upstream changes. Not upstreaming them means that you end up maintaining a library of patches that you have to port to each new version that's released. Over time this gets to be really difficult and expensive.

Note that this is also true for BSD code... except that in the BSD world there are some legal counter-incentives that discourage you from upstreaming. Too many people will argue that because the license allows you to keep your code to yourself, you should, which leads you into a patch-maintenance hell that the business and legal types don't appreciate or understand. So, the GPL helps the technical staff by eliminating the secrecy argument and encouraging upstreaming, which eliminates patch-maintenance hell.

Also, the upstream argument is something that's been compellingly disproven in the case of BSD.

No, it hasn't. You're right that smart BSD projects do upstream changes to avoid patch maintenance hell, but it takes a particularly enlightened organization to do it. The GPL helps be eliminating the option of keeping your changes secret. In a very few cases, this is a problem because the code in question has crucial competitive value *and* can't be run effectively in userspace. But those cases are rare, and the tendency is for organizations to vastly overestimate the value of their proprietary code.

Comment Re:Too secure for insecure? (Score 1) 559

If you're a Ron Paul supporter voting for Trump, I fear that "confused" is rather an understatement of your mental state.

I think not so much "confused" as "shallow". I can see a very surface correspondence between Paul and Trump: They both like to buck the establishment. The fact that the do so in very different ways and for very different reasons requires looking past the top millimeter of each. I suppose a vote for Obama (in his first presidential campaign) could fit as well if the same incredibly shallow analysis just focused on the "Hope and Change" slogan.

Comment Google does something like this (Score 1) 180

Google does something like this, on a selective basis.

I think it started as something done only for special cases, but I know a few people who arranged it. One woman I know works three days per week instead of five, for 60% of her normal salary. She has also taken a large chunk of her 18-week maternity leave and uses it one day per week, so she actually works two days per week but gets paid for three, until the maternity leave runs out. Her husband has arranged a similar structure with his employer (not Google), working three days per week so one of them is always home with the kids. She's a fairly special case, though, because she's a freakishly brilliant software engineer who any smart company would bend over backwards to accommodate.

However, it's now been expanded to be made generally available to full-time employees. It requires management approval, but the descriptions I've seen make it clear that management is expected to agree unless there are specific reasons why it can't work. Salary, bonuses and stock are pro-rated based on the percentage of a normal schedule that is worked. Most commonly, people work 60% or 80% schedules (i.e. three or four days per week instead of five). Other benefits, such as health care, etc., are not pro-rated, but either provided or not, depending on the percentage of normal hours worked.

I could see myself going to a 60% work week in a few years, having a four-day weekend every week in exchange for a 40% pay cut.

Comment Re:Yep. (Score 1) 174

One part of your experience that rings false to me is the level of support required for Windows machines vs Macs. My experience is narrower than yours, because I'm a programmer not an IT support guy, but I do get used as an IT support guy by friends and family because, you know, I "do computers". With that caveat, my experience is that the single biggest thing I can do to reduce my support burden is to get them to trade in their Windows laptop for something else. The very best alternative is a Chromebook, then a Macbook. Installing Ubuntu instead of Windows is also a good support-reducer, but not as many have gone that route.

As far as mobile devices go, I do more Android support than iOS support, but I think that's mostly because all of my immediate family, and most of my extended family, uses Android. Plus the Apple users are a little less likely to come to me for help because they know I'm an Android guy (because I work on Android system development).

Comment Re:Insufficiently Realistic (Score 1) 317

Until the dolls literally spray genuine, authentic baby shit and vomit on you in the middle of the night, they are going to be inadequate to the task of dissuading girls from wanting to make babies.

If you can't actually fill them with a truly realistic substitute for unwanted infant fluids, they're worthless.

I don't think that has anything to do with it.

I've raised four kids (youngest is now 15, oldest is 23), and the bad parts of having children, and babies, really have nothing to do with the icky body fluids. I've changed more than a few "blowout" diapers, and even had a couple of kids puke into my mouth and that's really not the bad/difficult part of having and raising children. The bad/difficult part is the commitment required. Kids require very close to 24/7 effort for years, and a lower level of focus and attention for decades. They're financially expensive, emotionally and physically demanding and they require you to be able to deal with your life so you can also deal with theirs.

On the surface, caring for a robo-baby for a few months should be a reasonable approximation of that. Where it falls down is not the lack of body fluids, I think, but the knowledge that (a) it's only a grade, not a life and (b) it is only a few months. (a) means that if you screw it up, it's not so terrible, and (b) means that you know there's an end in sight. Both of those probably significantly reduce the impact.

The schools in my area do something similar, but they don't use a robot, they use a bag of flour. That's not as good in that it won't rat them out for failing to care for it, but it may have another advantage (besides the low cost): It's not cute. I wonder if the robo-babies don't backfire because they get girls thinking about how cool it would be to have a cute little baby all their own.

Comment Re:AI needs some improvement (Score 1) 54

I just won a game of Tic-Tac-Toe for the first time ever.

Since it's trivial to write an algorithm that plays optimally and since a player using an optimal strategy will never lose, Google clearly did not try to create an "AI" whose focus is winning. Instead, they appear to have created an algorithm that is a fairly decent novice player. Which, actually is a good deal harder than optimal play.

Well, maybe not. It wouldn't be too difficult to take an optimal play implementation and randomly cause it to choose a bad move. For example, if it's playing X you could have it select a move at random, rather than always taking a corner. And at each subsequent move you could give it a smallish chance of making a bad move. That approach might simulate a decent novice well enough.

Perhaps a better approach would be to use machine learning and have it learn from novice games, or even from well-played games, but leave it incompletely trained. That might make it more "human-like".

Comment Re: Stop it with the SJW crap!!! (Score 1) 687

My belief is that there's an overwhelming consensus amongst scientists who are experts in this field that man-made climate change is real and worth taking action to mitigate.

My belief is that whether or not the warming is man-made is almost completely irrelevant. It's clear that the planet is warming, and it's clear that this is going to make our lives more difficult, meaning it's going to consume huge amounts of labor and resources to adapt. Therefore, we should absolutely be taking action to mitigate the change, as long that action consumes less labor and resources than would be required to adapt to the change (which argues for pretty aggressive action, since adaptation is going to really costly, e.g. relocating a large portion of the human population).

The source of the warming is only relevant because it may point us towards some possible mitigation strategies. We should not, however, focus only on ameliorating the causes. Other, more direct, climate manipulation strategies should be seriously investigated.

Comment Re:Good at desensitizing too! (Score 2) 82

Very effective at making operators forget that they are training to kill other human beings, make it easier to unthinkingly shoot when told regardless of right/wrong.

I don't think video games are particularly effective at changing the way people think about real combat, when there are real people downrange.

What does work well is what has always worked well... tribalism and intentional dehumanization, which includes calling the enemy "hun", "jerry", "jap", "slope", "slant", "gook", "raghead", "tango", "target", etc., and attributing subhuman and evil characteristics to them.

Slashdot Top Deals

If you can't understand it, it is intuitively obvious.

Working...