Dave Close wrote:
> An employer has a similar system. But the numbers are sequential so,
> were they email addresses, a spammer could hit nearly everyone without
> hardly trying. And they would create the hazard of sending mail to the
> wrong person inadvertently, with no reliable confirmation of j
It was Backblaze.com
Here's a summary of their tech and setup
http://blog.backblaze.com/2009/10/07/backblaze-storage-pod-vendors-tips-and-tricks/
Effects of the story,
http://blog.backblaze.com/2009/09/25/fallout-of-the-backblaze-storage-pod-post/
http://www.protocase.com/ is the manufacturer of
On Sat, 24 Oct 2009, Junhao wrote:
> On 10/22/2009 01:23 AM, da...@lang.hm wrote:
>> On Thu, 22 Oct 2009, Junhao wrote:
>>
>>> Hi!
>>>
>>> At my workplace, I am in charge of data storage for my research group.
>>> These files are placed in a *NIX file server, and users authentication
>>> is throug
On Fri, 23 Oct 2009, Yves Dorfsman wrote:
> That's all fine until:
> -the new CEO wants his email to be john, yeah, john is already taken, and
> yes the policy is first come first server, but... he is the CEO (hahaha, I
> actually typed he/she, and then realise that wasn't working too well).
Tha
On Fri, 23 Oct 2009, Derek J. Balling wrote:
> I know I had "b...@yahoo-inc.com" for the longest time as an alias to
> my "real" address. It even ended up on a batch of business cards at
> one point when I was feeling particularly cynical :-)
i had z3r0c...@amazon.com as an alias...
_
Pam Ochs wrote:
> Junhao,
>
> Why does option 2 cause a loss of institutional knowledge? Is file
> ownership being used to track authorship? Or is there a concern that
> people will delete or overwrite data?
> Maybe a content management solution would meet your requirements more
> effectively?
On 10/22/2009 01:44 AM, David Parter wrote:
>>> My workplace does not have a policy to handle this situation, so I am
>>> wondering how everyone handles this age-old problem. Any advice?
>>>
>>> I can only think of these 2 methods:
>>> 1) create local users to replace the AD user.
>>> There no
On 10/22/2009 01:23 AM, da...@lang.hm wrote:
> On Thu, 22 Oct 2009, Junhao wrote:
>
>> Hi!
>>
>> At my workplace, I am in charge of data storage for my research group.
>> These files are placed in a *NIX file server, and users authentication
>> is through my corporate AD. Files are owned by individ
I wrote:
> We should just accept that a universal identifier is not practical, and
> perhaps not desireable.
Yves Dorfsman responded:
>That's a purist answer, if it can't be perfect, let's forget about it.
I said nothing about forgetting the subject. Just quit searching for a
single universal u
On Oct 23, 2009, at 5:29 PM, Yves Dorfsman wrote:
> -sooner or later, people will be complaining how manager X is not
> fun, and
> how he won't let you pick an email that's fun but appropriate.
> Within a
> months you have to draft an "appropriate and fair email id policy"
> that's
> hell to
Lamont Granquist wrote:
> When I was at Amazon it was decided on by you and your manager.
>
> Some people used their initials which was actually remarkably easy to
> remember because it was different from most of the rest of the people.
> One person used the first initial of their first name (si
When I was at Amazon it was decided on by you and your manager.
Some people used their initials which was actually remarkably easy to
remember because it was different from most of the rest of the people.
One person used the first initial of their first name (single character)
which was also v
Yves Dorfsman wrote:
> When you think about it, the id has to be unique within a specific domain,
> within a specific company. Well, most companies have a unique staff id which
> typically isn't confidential (you can't get access to anything confidential,
> with just that id). Why not use that ?
Dave Close wrote:
> We should just accept that a universal identifier is not practical, and
> perhaps not desireable.
Let's just assign everyone an IPv6 address and be done with it... :P
:::::::
--
END OF LINE
--MCP
On 2009, Oct 23, at 09:48, Jonathan Billings wrote:
> On Fri, Oct 23, 2009 at 09:28:01AM -0400, John Stoffel wrote:
>> Exactly. And it doesn't scale. Even at my small 400-500 person
>> company we have conflicts with names. So, if you have two
>> john.sm...@foo.com, who gets the email? Riddle me
On Oct 23, 2009, at 10:48 AM, Jonathan Billings
wrote:
> If the mail system couldn't figure out who you were
> asking for, it would generate an SMTP failure with a list of possible
> matches in the error, so you'd get a bounce with useful information in
> it.
Sounds like the stuff a spammers
Dave Close wrote:
>
>> Exactly. And it doesn't scale. Even at my small 400-500 person
>> company we have conflicts with names. So, if you have two
>> john.sm...@foo.com, who gets the email? Riddle me that batman...
>
> When snail mail arrives addressed to John Smith, it usually gets to
> the
On Fri, Oct 23, 2009 at 09:28:01AM -0400, John Stoffel wrote:
> Exactly. And it doesn't scale. Even at my small 400-500 person
> company we have conflicts with names. So, if you have two
> john.sm...@foo.com, who gets the email? Riddle me that batman...
Years ago, I worked on a mail system tha
da...@lang.hm wrote:
>username conflicts are a problem anyway. when you look at logs years later
>do you really want to have to remember that user 'joe' means one person
>before July 2009 a different person as of September 2009?
Same problem in spades for a workflow system. It checks that a user
"John Stoffel" wrote:
>Exactly. And it doesn't scale. Even at my small 400-500 person
>company we have conflicts with names. So, if you have two
>john.sm...@foo.com, who gets the email? Riddle me that batman...
When snail mail arrives addressed to John Smith, it usually gets to
the right pers
> "Edward" == Edward Ned Harvey writes:
>> So any stardard is going to break no matter what you do. Which is why
>> I liked the Lucent one. There was no standard name, which meant no
>> standard expecations to break.
Edward> The only thing I didn't like about the lucent one was ... at
Edwa
>> And
>> please, let's get away from those asinine first.last@ email
>> addresses. They just don't scale.
Edward> I don't get what you're talking about. first.l...@domain is
Edward> one of the best things ever. When I meet somebody, I don't
Edward> want to remember that they are jsmith, or
> So any stardard is going to break no matter what you do. Which is why
> I liked the Lucent one. There was no standard name, which meant no
> standard expecations to break.
The only thing I didn't like about the lucent one was ... at first, the name
was chosen by HR.
The naming convention I us
> "David" == David Parter writes:
>> I personally think this scales down to even a small company. And
>> please, let's get away from those asinine first.last@ email
>> addresses. They just don't scale. But god knows why some CEOs
>> continue to insist on them, like my current job. Stupid.
> I personally think this scales down to even a small company. And
> please, let's get away from those asinine first.last@ email
> addresses. They just don't scale. But god knows why some CEOs
> continue to insist on them, like my current job. Stupid.
I love naming conventions that include "ex
> "david" == david writes:
david> On Thu, 22 Oct 2009, John Stoffel wrote:
Edward> Never delete user accounts. Just disable them. For precisely
Edward> the reason mentioned - after a user account is deleted,
Edward> whether Windows or Linux fileshare, the system says "I don't
Edward> know
On Thu, 22 Oct 2009, John Stoffel wrote:
> Edward> Never delete user accounts. Just disable them. For precisely
> Edward> the reason mentioned - after a user account is deleted,
> Edward> whether Windows or Linux fileshare, the system says "I don't
> Edward> know who owns those files..."
>
> We
Edward> Never delete user accounts. Just disable them. For precisely
Edward> the reason mentioned - after a user account is deleted,
Edward> whether Windows or Linux fileshare, the system says "I don't
Edward> know who owns those files..."
We don't delete them right away, but we do ask their ma
Junhao,
Why does option 2 cause a loss of institutional knowledge? Is file
ownership being used to track authorship? Or is there a concern that people
will delete or overwrite data?
Maybe a content management solution would meet your requirements more
effectively?
I supported an R&D environment
--- On Wed, 10/21/09, Junhao wrote:
At my workplace, I am in charge of data storage for my research group.
These files are placed in a *NIX file server, and users authentication
is through my corporate AD. Files are owned by individual users; other
users from the same group can only read the files
Never delete user accounts. Just disable them. For precisely the reason
mentioned - after a user account is deleted, whether Windows or Linux
fileshare, the system says "I don't know who owns those files..."
> -Original Message-
> From: discuss-boun...@lopsa.org [mailto:discuss-boun..
On Wed, Oct 21, 2009 at 3:58 PM, John Jasen wrote:
> David Parter wrote:
>
3) request for the accounts to be locked, not deleted. I think Security
will scream...
>>
> In old UNIX parlance, it was regarded as best practice to lock, disable
> and otherwise completely neuter and lobotomize
David Parter wrote:
>>> 3) request for the accounts to be locked, not deleted. I think Security
>>> will scream...
>
> Security should not scream (but they probably will), as long as you
> develop a specific policy and procedure for this. Security has to secure
> the systems, but they also have t
> > My workplace does not have a policy to handle this situation, so I am
> > wondering how everyone handles this age-old problem. Any advice?
> >
> > I can only think of these 2 methods:
> > 1) create local users to replace the AD user.
> >There no confusion about the person who generated the
Junhao wrote:
[snip]
> My workplace does not have a policy to handle this situation, so I am
> wondering how everyone handles this age-old problem. Any advice?
>
> I can only think of these 2 methods:
> 1) create local users to replace the AD user.
>There no confusion about the person who gen
On Thu, 22 Oct 2009, Junhao wrote:
> Hi!
>
> At my workplace, I am in charge of data storage for my research group.
> These files are placed in a *NIX file server, and users authentication
> is through my corporate AD. Files are owned by individual users; other
> users from the same group can only
36 matches
Mail list logo
