Forgot your password?
typodupeerror

Comment: I just read his lesson plan (Score 1) 179

Lesson 1: Make sure your college roommate is Bill Gates.
Lesson 2: Drop out. You don't need this stuff, go make money.
Lesson 3: Developers, Developers, Developers, Developers.
Lesson 4: When a monopoly is handed to you, ride it into the ground.
Lesson 5: When no one likes you, it's proper to own the L. A. Clippers.

Comment: Re:Real life is complicated (Score 1) 511

If you take drugs and get addicted, that's your responsibility. Not anyone else's.

Think so? I can introduce you to some former surgery patients and war veterans among others who were introduced to opiates to control pain by their physicians for very real pain problems and as a result were unable to avoid addiction. I can point you to some suffering from PTSD (not their fault) who are trying to find some way to cope who sometimes turn to chemicals because they don't understand what has happened and it is the only relief they can find before they understand what has happened. Some addictions are not the solely the fault of the person taking the drugs.

It's easy and wrong to paint every drug addict with the same broad brush. Some, like the sort you are thinking of, are simply idiots seeking pleasure or escape. If you are snorting cocaine on your yacht for fun, yeah that's on you and if you die I'm not going to cry a river for you. Others are decent people trying to cope with a real problem not of their own making. You really think that a wounded veteran who gets unintentionally addicted to opiates while trying to control pain is solely responsible for his situation? If so you are a very cold hearted person.

I think you're conflating "responsibility" with "fault". The addict has the responsibility to deal with the addiction and manage their life, regardless of whether they are morally culpable for becoming an addict. Just as they are responsible for their actions if, for example, their addiction drives them to crime in order to support their habit, or they cause harm while under the influence of the substance that they are addicted to.

Comment: Re:Not Odd (Score 4, Informative) 544

It's a nice solution idea, but leaving Bluetooth on all the time must eat quite a lot into your battery runtime. I have a hard time using a phone when the battery is drained. I can run for maybe an 3-4 hours on a charge if I'm actively using my phone, and that's with all manner of power saving options turned on, doing their best to maximize my *useful* runtime. The industry insists on super thin, but large surface area smartphones, but I'd give just about anything for something pocket size, 90% battery by mass, and with a slide-out physical keyboard. If it were an inch and a half thick, but could provide a solid 14 hour active use time on a single charge, I'd be in love with it.

Comment: Re:As a former government IT contractor... (Score 1) 682

by Junior J. Junior III (#47279297) Attached to: IRS Recycled Lerner Hard Drive

I have no idea of the particulars in the IRS case, so it's useless for me to speculate on that. I haven't heard that internal mails were retrievable while external mails were not. The loss of a single user's hard drive does not explain that very well. It might be possible that the internal messages could have been retrieved from other users systems within the IRS. Perhaps the user could have filtered external emails to a local .pst file that was lost when the hard drive died, while internal emails were contained in numerous other mailboxes within the agency? I have no idea, but it's an explanation that could be plausible.

Comment: As a former government IT contractor... (Score 3, Insightful) 682

by Junior J. Junior III (#47275269) Attached to: IRS Recycled Lerner Hard Drive

From 2001-2011, I worked for a series of contractors under NASA.

Most users who I supported were administrators and managers of various stripes, and a few users who were skilled with desktop publishing, web development, imagery, video, or 3d modeling/CAD. Most of them didn't understand how computers worked, and didn't care how they worked. They were just magic boxes that they used to do work with.

The idea of deleting email was frightening to most users. Email was a record that proved that you did work, and could be used for Cover Your Ass in the event of an inquiry. It could also prove a conversation happened, that an agreement was made, and so settle many disputes arising out of miscommunication. Most people whom I worked with hardly ever deleted messages, and because their local hard drive had plenty of capacity, they didn't have a real need to.

Until 2007, we used POP3 clients running on the local machine to download mail from a server. Messages were deleted from the server once downloaded, so only existed on the client machine at that point. Some users had decades of email stored in their client on their local hard drive, which typically was not backed up. I'm sure the servers had some redundancy and short backup, but to my knowledge we did not have a system that archived email. The closest thing resembling an archive was the aggregate collection of all mailboxes on the the client machines' hard drives.

Occasionally we did have users lose data due to a failed hard drive. Users who got bit by data loss tended to learn from this and implement safeguard such as backup to server, or to removable media. But incredibly, these lessons, once learned, were not applied at more than the individual level. People might talk to each other and departments might share knowledge for how to back up data, but it was never something that was codified in policy. People were on their own to implement their own backup and to make sure it worked. It was something that if anything, was encouraged, but not required or enforced. But very often it was not thought about until after the fact of a data loss incident.

In 2007, we moved to Outlook/Exchange for email. Many long time users were very put off by the change, and did not want to give up their Eudora, and could not deal with the fact that we were not going to migrate their old email into Exchange. Enough resistance was put up that IT ended up continuing to support the client side of the old email system indefinitely, so that users could still access their local archive of old email, and possibly also use automation features in their old client to continue to run processes that generated automated mail messages.

Exchange uses MAPI, so in the new system our messages were now always left on the server, until deleted. We had 1GB server quotas (around this time I believe Gmail was giving the world ~6GB for free). In theory, the 1GB server quota gave us security from data loss because the Exchange server's storage was backed up. In fact, the low quota size forced much more mail deletion than had ever happened in the old POP3 days of decentralized, distributed ad-hoc archive. But this was by design rather than by defect. And it was a lot easier to restore any retained data if it was lost.

All the same, users did not want to delete email, ever. Once they hit their quota on the server, they'd submit requests asking for an increase to their quota, which only would be granted if the volume of incoming mail that they had to deal with made a larger quota necessary in order to allow them to have a reasonable backlog of mail going back 6 months to a year, or they had a senior enough position that they could get whatever they demanded. Even then, when people hit their new quota, they still didn't want to delete old messages. The IT team supporting the new email refused to support this in any way, but didn't prevent users from creating local .pst files which they could use to store mail, once again on the local hard drive. Once again, this data was typically not in any way backed up. By this point, we had roaming profiles managed by active directory, so had we been able to use the user's My Documents folder to store the .pst, it would have been backed up over the network. But the roaming profile directories also had a minuscule disk quota of 1GB. Users still had access to C:\ so most of them used that as their .pst archive location, and enjoyed effectively unlimited archive space on their local hard drive, that was not backed up.

Users understood and accepted the risk, until they had a loss incident, at which point they no longer accepted or understood the consequences of their decisions. Then it became our (IT's) problem, and we had to do whatever ridiculous magic thing we could figure out, usually with no budget, but expending huge amounts of hours trying various things that we knew were unlikely to work, but would be compelled by management to try anyway, for "good customer service", to try to rescue the data.

I have no idea whether the IRS deliberately destroyed evidence, but it's entirely plausible to me that they simply lost the data due to a lack of competence and insufficient disaster recovery.

Comment: Re:Lol, yeah, that's real tough... (Score 1) 305

by Junior J. Junior III (#46822431) Attached to: 'The Door Problem' of Game Design
It's not really a strenuous activity. But it is a mental activity which most people don't normally do, because most people take real-life doors for granted. Of course programmer geeks talking on slashdot are used to thinking this way about the problem spaces that they deal with when they are programming something, so to us it's nothing new. But for someone who hasn't programmed before, or designed a rules system for how virtual stuff should work in the context of a game before, it is.

Comment: WRONG! (Score 1) 235

by Junior J. Junior III (#46788671) Attached to: Bug Bounties Don't Help If Bugs Never Run Out
Security is not binary. Security is not absolute. There is ALWAYS residual risk. There is no such thing as invulnerability or immortality. Everything can be taken down. Security is not an end state. It is an ongoing process. If you do not continually improve the security of software, by addressing known vulnerabilities, performing a sane risk assessment, identifying threats, and doing what you can to mitigate them, you will regret it. The notion that implementing fixes is pointless because there will always be more vulnerabilities is wrong. Yes, there will always be vulnerabilities. Yes, security is a job that never ends. No, you can't ignore vulnerabilities once you know of them.

Comment: 100% paper (Score 0) 167

by Junior J. Junior III (#46670475) Attached to: A Rock Paper Scissors Brainteaser
100% paper strategy will win 50% of the time. Of the remaining 50% of games played, (assuming even distribution of the remaining picks) 25% will be losses and 25% will be tied. Thus, you'd be assured a win-loss-tie ratio of 2-1-1, which is quite good. If their remaining options are not distributed evenly, this changes things. You'd want to look at their play to see whether there are any discernable patterns, such that you know that Rock will be played for certain every other move, for example. Then you just sync Paper moves to their Rock moves, and play Scissors or Rock randomly for the other half.

Comment: Unequal, but also unquantifiable (Score 2) 156

Rather than asking whether they are equal, we should instead think in terms of how can we verify what they're worth? Is a source quantifiable? If not, it makes little sense to consider whether one type of source is equal to another. Just being able to identify what type of source a source is may be difficult or impossible.

He: Let's end it all, bequeathin' our brains to science. She: What?!? Science got enough trouble with their OWN brains. -- Walt Kelly

Working...