Language:
switch to room list switch to menu My folders
Go to page: First ... 41 42 43 44 [45] 46 47 48 49 ... Last
[#] Tue Jan 05 2010 05:17:35 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mo Jan 04 2010 21:29:14 EST von LoanShark @ Uncensored
simple, and secure as possible. We believe that simplicity without the

portability "goop" allows for better code quality control and easier
review. The other team then takes the clean version and makes it

A pathetic excuse. A well-designed system just doesn't have portability issues. Java for instance has managed to cleanly encapsulate all the POSIX functions that are necessary to build a portable program, with full async I/O and whatnot. If you do things the right way, you should have to do #ifdef on the same HAVE_WHATEVER symbol more than once in your entire codebase.

The reality is that deraadt and his goon squad don't play well with others, and are interested in creating artificial barriers to the adoption of their patches by the original source providers. This is a prime example.

well, creating a portable interpreter is a whole different thing than coding portable in C. I guess the typical java interpreter in fact is coded in C and contains lots of #ifdefs to encapsulate all that to its users.

even that enables you to write windows only java programms by using resources or path names just windows can offer. I've seen that. It can even be that for example you've got a mysql backed, in which in fact due to the braindead NTFS and FAT tablenames are case insensitive, and in *nix they're _not_ so most probably the mysql dump from the wintendo won't work when put back in on a *nix mysql.

Deraadt and others... yes, he could have commented why the patch the debian guy submitted was bad instead of just ignoring it. So, this thing you all still know could at least have been prevented by him.



[#] Tue Jan 05 2010 09:52:29 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

LS: I was trying to be erudite and reasonable, but yeah, I agree with you, they're a bunch of uncooperative troublemakers. :)

[#] Wed Jan 06 2010 09:46:39 EST from cellofellow @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, for all its flaws, OpenSSH is still a terrific program. Secure, versatile, and (relatively) easy to use.

[#] Wed Jan 06 2010 12:04:00 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Not sure where to post this, but it's worth pondering.

Word on the street is that Yahoo is getting ready to sell off the Zimbra business unit. The buyer is supposedly VMware.

Kudos to Yahoo for unloading the Zimbra albatross while it's still worth something. I'm not sure it's really going to be all that valuable as a going concern. Yes, their web user interface is quite slick, but I've looked at the architecture of this product in detail and the underpinnings are quite ugly.

It's interesting that VMware is the buyer, because Zimbra seems to always have been featured quite prominently in their "virtual appliance marketplace."
Perhaps that is indeed the sweet spot for delivery of this application.

I've always found it quite curious that they seem to focus quite heavily on going head-to-head with Exchange in the "enterprise" market, while other market sectors seem to be a better opportunity because Microsoft continues to neglect them. Citadel is popular, for example, in small businesses and non-profit organizations without a large IT staff due to its easy installation and low maintenance.
I think Zimbra's biggest opportunities would have been service providers and universities, but they've been quite focused on "the enterprise" instead.

Naturally, as a Zimbra competitor I'm not afraid of saying that I hope they crash and burn. I also happen to know that they do quite a bit of astroturfing so I'll add that they *deserve* to crash and burn.

[#] Wed Jan 06 2010 13:12:15 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Zimbra is, at least at the moment, different from Zombo.com, I think.

http://zombo.com/

[#] Wed Jan 06 2010 16:12:34 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Oh yeah, Zombo has always had far superior technology.

[#] Fri Jan 08 2010 08:18:44 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

...so, the "ximian Brats" are leaving novel.



[#] Fri Jan 08 2010 10:10:36 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Cite?

[#] Fri Jan 08 2010 15:05:59 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ah. Just Nat? Not Miguel? Nat is mentioning this on his blog: http://nat.org/blog/2010/01/hitting-the-road/

So he's leaving Novell and will do something else later. It's sickening that this dipshit is independently well-off enough to do that.

[#] Sat Jan 09 2010 22:12:30 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

he'll come back in 6 months with hiv and no wife.

[#] Wed Jan 27 2010 11:48:23 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Hey Linux people...

Does anyone know how the /dev/disk/by-id/* names are calculated?

I'm particularly interested in knowing whether there are any circumstances under which the ID would change, particularly if the disk is re-formatted, re-partitioned, or molested in any other way?

I have a project going right now in which a pair of Linux machines are bringing in Fibre Channel LUN's and then re-exporting them to a farm of VMware boxen via iSCSI. (Yes, I know, the VMware boxen should have Fibre Channel cards in them, but they don't, and there's no budget yet, so this is what I've got to work with.) I like what I'm seeing in /dev/disk/by-id because it appears to be agnostic to the channel path, which is important because each machine has two channels back to the storage.

[#] Wed Jan 27 2010 11:58:37 EST from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

If my memory serves me correctly, they're calculated in the order they were identified by their hardware's id built into whatever disk drive it may be. (like windows drive letters) and saved as such, so even if you disconnect disc01 (hardware id 0001) and leave it disconnected for a long time, as long as that configuration is saved then when you plug it back in it should identify it as disc01 and no other hardware id can overtake that...   but i may be wrong...  i'm not entirely 100% sure on that matter.



[#] Wed Jan 27 2010 14:49:45 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That would imply that they are indeed persistent. I'm looking around on different machines to see what they do. Here's what my desktop shows:

lrwxrwxrwx 1 root root 9 2010-01-22 10:06 scsi-SATA_ST340014AS_5MQ27N97 -> ../../sda

The above was clearly generated from the device's model and serial number.
Similarly, the server we're on now shows something similar:

lrwxrwxrwx 1 root root 9 Jan 19 11:07 scsi-SIBM_DNES18Y_CLAR18_AKG7F770 -> ../../sda
lrwxrwxrwx 1 root root 9 Jan 19 11:07 scsi-SIBM_DNES18Y_CLAR18_AKG78604 -> ../../sdb
lrwxrwxrwx 1 root root 9 Jan 19 11:07 scsi-SSEAGATE_ST336607LC_3JA6MG87 -> ../../sdc
lrwxrwxrwx 1 root root 9 Jan 19 11:07 scsi-SSEAGATE_ST336607LC_3JA6MH9X -> ../../sdd
lrwxrwxrwx 1 root root 9 Jan 19 11:07 scsi-SSEAGATE_ST336607LC_3JA6MN6V -> ../../sde

Here's what I see from within a VMware virtual machine:

lrwxrwxrwx 1 root root 9 Sep 25 09:06 ata-VMware_Virtual_IDE_CDROM_Drive_10000000000000000001 -> ../../hdc

And finally, our machine with the SAN LUN's mapped to it (interestingly, the direct-attached drives are not showing up in this list) ...

lrwxrwxrwx 1 root root 9 Jan 27 06:47 scsi-3600508b300939cb0a97f080e2c03000d -> ../../sda
lrwxrwxrwx 1 root root 9 Jan 27 06:47 scsi-3600508b300939cb0a97f180efb77000d -> ../../sdb
lrwxrwxrwx 1 root root 9 Jan 27 06:47 scsi-3600508b300939cb0a97f280e4ef3000e -> ../../sdc

It should be noted that sometimes we see these as sdd/sde/sdf instead of sda/sdb/sdc because of multi-path topology. And that means it *is* recognizing these as the same disks presented over two different paths, because it's creating three entries, not six.

Ok, so I think I'm optimistic enough now to go ahead and run with the assumption that the ID's aren't going to change. We'll see what happens after I hand these LUN's off to VMware for partitioning and file systems.

[#] Thu Jan 28 2010 12:51:06 EST from Freakdog @ Dog Pound BBS II

[Reply] [ReplyQuoted] [Headers] [Print]

Assuming that the SCSI IDs remain constant, then the disk names should remain constant, as well.



[#] Thu Jan 28 2010 15:19:37 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That goes against the idea of using /dev/disk/by-id in the first place, which is that the name stays the same even if the path changes. I am seeing the same disk ID's across four paths and two different hosts that share these volumes.

By the way, after partitioning and formatting the volumes, the ID's have not changed.

[#] Thu Jan 28 2010 15:30:35 EST from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

By the way, after partitioning and formatting the volumes, the ID's have not changed.

 


So that's good news! :)



[#] Thu Jan 28 2010 22:19:09 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

other hardware id can overtake that...   but i may be wrong... 
i'm not entirely 100% sure on that matter.

Definetly not. I shuffled drives, the point of the ID is to find the drive whereever it is physically.
It's probably something dumped in the MBR if Ihad to guess. I think I read about it when I was having all my raid problems, but I don't remember too well because I wasn't concentrating on the id's as much as finding ANY way to find the drive.

[#] Thu Jan 28 2010 22:20:16 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ok, so I think I'm optimistic enough now to go ahead and run with the

assumption that the ID's aren't going to change. We'll see what

I'm pretty sure the id is burned on to the drive. I don't remember if reparitioning killed it or not, but it's a pretty low leve id.

[#] Thu Jan 28 2010 22:22:46 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

By the way, after partitioning and formatting the volumes, the ID's

have not changed.

yeah, then check the mbr.
oh here...
Alternatively, you can use the udev by-id specification (look
in /dev/disk/by-id). The ID paths are usually pretty long
and less meaningful, but they are device specific and won't
change as a result of hardware changes. It's probably best to
use a disk label as above. However, for vfat/fat file systems
disk labels are not available so the by-id specification
should be used.\

Go to page: First ... 41 42 43 44 [45] 46 47 48 49 ... Last